Moda v pojmenování nebo nešvar?

IDE je dost chytré na to, aby poznalo, zda má napovídat třídu, interface či výjimku. Pro extends, implements a throw tedy žádná vodítka nepotřebuješ.
Zkus prefixy a suffixy v těhle případech smazat ve svém kódu – třeba přijdeš na to, že ti též nechybí.

Mabar napsal(a):

IDE je dost chytré na to, aby poznalo, zda má napovídat třídu, interface či výjimku. Pro extends, implements a throw tedy žádná vodítka nepotřebuješ.
Zkus prefixy a suffixy v těhle případech smazat ve svém kódu – třeba přijdeš na to, že ti též nechybí.

Nejde o IDE, ale o čitelnost kodu, abych hned věděl, co je co bez barviček a ikonek.

Editoval ppar (6. 1. 2021 15:39)

Ale když už to téma tady je – jaký máte argument pro používání prefixů/suffix?

Buďte prosím konkrétní. „Abych hned věděl, co je co“ tu vyvrátil @mabar. Prostě když v kódu uvidím new Foo nebo throw Foo, vím že to je třída a není abstraktní.

Také se mi zdá, že to pomáhá v orientaci na úrovni FileSystému, nebo pak v tabech editoru, které zobrazují název souboru. Oboje jsou případy, kdy kontext kódu není vidět.

Také by mě zajímaly důvody, proč je IInterface a TTrait velký přešlap. Možná ten článek mohl předcházet.

Rád bych se zeptal vás, kteří preferujete prefixy či suffixy – vadilo vám někdy, že SmartObject se nejmenuje TSmartObject nebo SmartObjectTrait?

Ty problémy s kompatibilitou nebyly na straně SmartObjectu, ale jde o chybu ve TranslateMacros, který dědí od cizí třídy a zároveň nesmyslně používá traitu Kdyby\StrictObjects\Scream, která se bije s předkem.

Nette\SmartObject nikdo z nich nepoužívá! 🤷‍♂️ To je jen dojem vzniklý tím, že Filip zkopíroval název SmartObject pro svůj projekt. Prostě normální chyba, co ale nechápu, že ji za ty roky nikdo neopravil.

baraja napsal(a):

Osobně jsem taky za zavedení co nejkratších názvů, protože:

lepší je pojmenovat obecné rozhraní Identity a pak implementovat konkrétní SimpleIdentity

Identity (class) + IIdentity (interface) = 17 znaků
SimpleIdentity (class) + Identity (interface) = 22 znaků

BTW, u prefixů „I“ a „T“ mi fakt připadá argument o co nejkratších názvech zcestný. Jakoby ten jeden znak byl alarmující.
Chápal bych takový argument v ZendFrameworku, kde ty názvy byly fakt na celý řádek (nevím jak dnes)…

User in UserStorage is possessive, not adjective. It is User's Storage, ie Storage for User.

Proč jsme přepli do angličtiny? :-)

Samozřejmě že z žádného podstatného jména nemůžeš poznat, jestli je to interface nebo třída. Jen jsem chtěl říct, že vztah mezi Translator–MyTranslator je jiný než mezi Storage–UserStorage v případě odkazovaného interface.

Rozlišovat mezi rozhraním a třídou je totiž nutné pouze v jednom případě – že používáš nějaký prefix/suffix. Protože má pak jiný název. Když žádný prefix/suffix nepoužíváš, pak ani nemáš potřebu to rozlišovat.

V aplikaci mám svoji implementaci translátoru pojmenovanou zase Translator.

namespace App;

use Nette\Localization;

final class Translator implements Localization\Translator
{}

Osobně používám prefixy I a T, ale jen ze zvyku.
Ve svých projektech mám taky implementaci překladače s jednoduchým názvem Translator (nechci nad názvama přemýšlet, takže volím co nejjednodušší), nemůžu tedy říct, že Translator je rozhraní, ale…

Spíš přemýšlím nad tím, k čemu je vlastně dobré vědět, že jde o rozhraní, traitu nebo třídu.

Ale když v Nette nebude prefix I, spíš mi to pomůže v tom, že mi IDE přednostně po napsání I napoví rozhraní z mého projektu a ušetří čas. A pokud tu @Mabar zmiňoval, že IDE je chytré, nevím proč mi po implements nabízí první čtyři položky, které rozhraní nejsou.

Jak to na první pohled vidíš? Jako že si necháš vylistovat všech X set souborů?

Neexistuje argument, který tvrdí, že název souboru je spolehlivější než grep.

Koncovna .phpi pro rozhraní a .aphp pro abstraktní třídy. Jako se používalo .inc.php pro soubory, které se includují, než se přišlo na to, že kromě index.php se includují všechny.

Zkus search milý Lojzo.

Myslím, že už jsme sklouzli hodně mimo.

Obsah adresáře ‚App/Forms/ContactForm‘:

ContactFormFactory.php
ContactFormProcessor.php

‚ContactFormProcessor‘ je interface, které říká, že ten kdo ho implementuje musí umět odeslat kontaktní formulář.

Implementace ‚ContactFormFactory.php‘

<?php declare(strict_types=1);

namespace App\Forms\ContactForm;

use Nette\Application\UI\Form;
use App\Forms\FormFactory;

class ContactFormFactory
{

    public function __construct(
        private FormFactory $formFactory,
        private ContactFormProcessor $formProcessor,
    ) {}

    public function create(): Form
    {
        $form = $this->formFactory->create();

        $form->addEmail('email', 'E-mail');
        $form->addText('content', 'Obsah dotazu');

        $form->onSuccess[] = [$this, 'onSuccess'];

        $form->addSubmit('submit', 'Odeslat');

        return $form;
    }

    public function onSuccess(Form $form): void
    {
        $this->formProcessor->process($form->getValues());
    }

}

1)
Nyní můžeme vzít náš kontaktní formulář a dát si ho do jiného projektu, kde potřebujeme ten stejný kontaktní formulář. Pokud jsme tvůrce projektu, je to jednoduché. Víme, že ‚ContactFormProcessor‘ je interface a tak nám stačí nějaké naší třídě prostě ten interface implementovat a díky DI máme vystaráno. Prostě přidáme jednu metodu a ‚implements‘. (To samé platí i pro FormFactory, ale v tomto konkrétním případě, kdy je FormFactory jinde a je tedy společná pro více formulářů je jedno, jestli zkopírujeme interface a poté donutíme jinou třídu jej implementovat, nebo jestli si rovnou napíšeme konkrétní třídu. Tedy FormFactory nás nezajímá. Pokud jej nezkopírujeme z projektu taky, tak jej stejně budeme muset dopsat.)

Opačná situace ale nastane, pokud jsme po někom zdědili projekt a šéf chce nový web, kde má být kontaktní formulář, přičemž chce, aby se dodržel firemní codding standard, takže musí na novém webu být kontaktní formulář udělán stejně. Nováček přijde, zkopíruje složku s formulářem, a najednou se diví, že mu Tracy hlásí, že DI nenalezl třídu ‚ContactFormProcessor‘. Byl jsem svědkem, kdy se nad takovou věcí zasekli nováčci na několik hodin, protože nevěděli, že pod ‚ContactFormProcessor‘ je ukrytý interface a ne již hotová třída. (To, že by neměl ContactFormProcessor odkud brát data jako email odesílatele pomineme, jelikož se jedná o příklad).

2)
Pokud je firma správně hierarchicky rozdělená, tak má tým developerů a tým testerů. Tedy tester je někdo, kdo neví, jak ten člověk naprogramoval aplikaci, jen ví, co má daná třída za metody a co má dělat. Tedy že má metodu sečti a ta opravdu vrátí jako výsledek součet dvou či více hodnot. Když tedy budeme jako testeři testovat třídu ‚ContactFormFactory‘, tak když si dáme v testu ‚new ContactFormFactory‘ tak nám IDE vyhodí nabídku například: ‚ContactFormFactory(FormFactory $formFactory, ContactFormProcessor $formProcessor) App\Forms\ContactForm‘. Jak potom my jako testeři poznáme, jak se zrovna programátor vyspal a jak to udělal? Když budeme chtít mocknout ‚FormFactory‘ a ‚ContactFormProcessor‘, tak jak poznáme, jestli máme tvořit třídu, která implementuje interface, nebo máme tvořit potomka třídy? Zase musíme dané soubory najít na disku, rozkliknout a prozkoumat, co se tam děje. (Případně si nechat napovědět IDE když zkusíme napsat new a název třídy…)

Závěr
Všechno toto značně znepřehledňuje kód a tím, že to musí člověk neustále kontrolovat co to je to zhoršuje výkonnost práce. Kdyby se prostě na začátek názvu pomocí nějakého standardu přidal prefix I-,T- atd.., tak hned každý ví o co jde a nemusí nic rozklikávat a hledat a ztrácet hromady drahoceného času nad tím, že neví co na daném místě v danou chvíli je.

Trochu mi to připomíná skryté závislosti, kdy se lidi bouří, že třída musí vše načítat přes konstruktor, nebo ze setterů, protože například přímé načítání z konzole například je skrytá závislost, která má za následek nejasnost kódu a aby uživatel pochopil co dělá metoda sečti(), tak se musí kouknout do ní. Stejně tak to vidím u prefixů I-, T- atd.. Prostě pokud to přímo nenačítám někde a IDE mi to nenapoví tedy, tak musím stejně jako v případě metody sečti vlézt dovnitř třídy a prozkoumat to. Pokud je tedy v pořádku odstranit prefixy, tak by mělo být i v pořádku povolit skryté závislosti a tedy zavést do programování chaos.

Už vidím, jak se to za pár let dovede do extrému a lidi budou říkat, že jsou všechny prefixy a suffixy zbytečné, takže všechny buildery a factory si odeberou suffix, takže místo ‚ContactFormFactory‘ a ‚FormFactory‘ bude ‚ContactForm‘ a ‚Form‘ kde pak nebude nikdo vědět, jestli je to faktorka a má se nad tím teda volat $form->create() nebo jestli je to konkrétní třída a máš nad tím volat new Form(), nebo se to dovede ještě dál a z interface ‚ContactFormProcessor‘ zbyde jen ‚ContactForm‘ takže nebude člověk vědět který z ‚ContactForm‘ je továrna na formulář, nebo jestli je to samotná třída formuláře, případně jestli je to interface či třída, která zpracovává ten form, nebo to dotáhneme úplně k dokonalosti a vše co se bude týkat formulářů se bude jmenovat prostě ‚Form‘ nehledě na to co to dělá… To se pak v tom vyznat bude žůžo labůžo.

Otázka nakonec:
Proč vlastně přechází PHP k silnému typování, aby bylo na první pohled jasně zřejmé, co je to za proměnnou a co má v sobě uloženo, když si to programátoři nelogicky nahradí tím, že začnou zobecňovat názvy tříd tak, že nikdo neví, co je uloženo v dané třídě?

Proč vlastně přechází PHP k silnému typování, aby bylo na první pohled jasně zřejmé, co je to za proměnnou a co má v sobě uloženo, když si to programátoři nelogicky nahradí tím, že začnou zobecňovat názvy tříd tak, že nikdo neví, co je uloženo v dané třídě?

To je výborný point. Proč když PHP směřuje k silnému typování, není u proměnných na první pohled zřejmé, jaký mají typ? Musí se to dohledat v deklaraci. Proč se nepoužívá prefix $this->intFoo nebo $this->strFoo, kde bych hned věděl? Tedy tzv. maďarská notace.

Totéž se týká viditelnosti. Nelze rozlišit, jestli $this->foo je privátní nebo public. Tady jsou osvědčeným řešením podtržítka.

Jsou jen dvě možnosti

• buď tyhle notace odmítnout
• nebo tyhle notace přijmout

Ale v některých případech je odmítnout jako zbytečné či dokonce rušivé a ve druhým případech je přijmout, protože „je to pak na první pohled zřejmé“, ztrácí vnitřní integritu.

@DavidGrudl $message, $form, $telephoneNumber, $zip, $name, $surname, $city…

Asi těžko bude proměnná $name obsahovat desetinné číslo.

Stejně tak proměnná $form, ta má v sobě objekt. Jak poznáme, že v sobě má objekt? Díky silnému typování.

Uvnitř funkce, které si ji nechám předat ‚public onSuccess(Form $form);‘ vím, že je $form datového typu Form a neřeším.

Pokud ji něco vrací: ‚$contactFormFactory->create();‘ tak asi mi metoda ‚create()‘ nad třídou, co se jmenuje ‚$contactFormFactory‘ nebude vracet řetězec. Jako bonus mi napoví IDE jaký návratový typ metoda má. Stejně tak dá rozum, že metoda ‚sečti($a, $b)‘ bude vracet číslo. Jestli int, nebo float mi může být jedno, protože INT se dá bez problémů zaměnit za float. Takže budu se vším pracovat jako s floatem a jsem vystaraný. tak samo metoda ‚concat($a, $b)‘ mi vrátí řetězec a ne int nebo nějaký objekt apod…

Takže ano, pokud je proměnná správně nazvaná, tak je vždy na první pohled zřejmé, co obsahuje.

Příkladem můžou být proměnné $user a $userId, přičemž očividně proměnná $user obsahuje instanci třídy User a proměnná $userId obsahuje integer znamenající uživatelovo ID.

Ale prosím vysvětli, jak poznám z názvu třídy ‚ContactFormProcessor‘, jestli se jedná o Interface, nebo Class? A to jsem schválně dal jako příklad zasazení do kontextu stejně jako jsou zasazeny do kontextu proměnné. U těch tříd/rozhraní to prostě nejde. Proto se ty prefixy/suffixy používají.

Kdysi jsem viděl, že se nazývaly rozhraní s příponou -able, protože přeci jako v reálném životě, tedy člověk umí chodit, zvířata a někteří roboti třeba, takže rozhraní Walkable. Známe to někdy i dnes, jako třeba Serializable. Většinou jsem viděl Drawable, Printable atd. Ale taky jsem viděl jak ti, co se to naučili od toho začali rychle upouštět v momentech, kdy viděli, že se to někde používá dost těžko. Například rozhraní FormFactory. Jak ho nazvat? FormFactoriable? To nedává moc smysl. Tak FormCreatable? A co to znamená? Že je ten formulář vyrobitelný, nebo že ho někdo umí vyrobit? Tady dává větší smysl ho prostě nazvat jako FormFactory a aby bylo známo, že se jedná o Interface, tak buď dát sufix -Interface nebo prefix I-, přičemž preferuji prefix, jelikož je kratší.

Editoval Polki (10. 1. 2021 14:44)

Každý identifikátor v jazyku s sebou nese nějaké metainformace. Co je to vůbec za prvek, jaký má typ v případě proměnných, viditelnost u členů tříd, další flagy jako abstract/final/&, výčet toho co implementuje/extenduje/useuje atd.

Po třiceti letech, co se věnuju programování, se dospělo k tomu, že vůbec žádná z těchto metainformací se nezrcadlí v názvu.

Ale než se k tomu dospělo, tak se o každém krůčku strhla vášnivá debata, protože spousta programátorů to považovala za krok špatným směrem, jelikož se tak z kódu vytratí důležitá informace.

Zajímavé je, že zpátky se nikdo nikdy nevracel. Pochopitelně je pravda, že člověk o střípek informace přijde. Ale vždy se ukázalo, že pozitiva převážily.

Tento krok a takhle diskuse nejsou výjimkou.

Pokud je vše dobře nazvané tak stačí kouknout a je to hned jasné. Pokud ovšem začneme věci nazývat špatně tak, že nejsou jednoznačné, tak pak se to zjistit nedá kolikrát ani hloubkovou kontrolou.

Například je asi jasné, že když v Presenteru napíšu $this->user tak dostanu instanci třídy Nette\Security\User; Když to udělám například v nějaké modelové třídě tak je jasné, že to je stejného datového typu jako třídní proměnná a pokud dodržuju zapouzdření, tak je to snad jasné na první pohled, že tam necpu nic jiného.

Navíc pokud mám vícero částí aplikace a přihlašuje se více lidí a například používám ORM, tak mám entity Customer, Merchant, Admin ... a tedy nazývám proměnné výstižně tedy $customer/$customers, $merchant/$merchants, $admin/$admins atd… Stejně tak z názvů vidíš, jestli se jedná o jednu instanci třídy, nebo jestli se jedná o pole instancí a i kdyby to pole bylo nějaký objekt, tak při správném použití můžu k tomu objektu přistupovat jako k poli, takže s tím pracuji pořád stejně a je jedno, jestli je tam pole nebo nějaký třeba iterable object. Z názvu musím vědět, jestli je jeden, jestli je jich více a jaký to je datový typ.

Proto instanci třídy ‚ContactFormFactory‘ uložím do proměnné ‚$contactFormFactory‘, čímž budu vědět, že v té proměnné je uložena instance této třídy. (Tedy si proměnnou správně nazvu)
Pokud mám v aplikaci vícero tříd ‚User‘, pak mám povinnost i správně nazvat proměnnou tak, aby z ní bylo jasně zjevné, o jakou instanci třídy se jedná. Pokud jsem v Presenteru tak tam je to jasné tam je to Security\User a vždy se to jmenuje $user. Pokud jsem jinde, musím odlišit jestli je to Nette\Security\User nebo jiný a to rozliším buď tak, že v kontextu se vyskytuje pouze jeden User a je tedy jasné který, nebo si je odlišit.

Často vídám v různých třídách dvě instance. Jednu s Nette\Security\User a druhou s modelovým například App\Model\User kde neťácký je nazvaný jednoduše $securityUser a ten modelový tedy definovaný programátorem v modelu se označuje čistě podle názvu třídy tedy $user.

A k původnímu argumentu. Pokud do proměnné $user ukládám toto: $user = $this->userRepository->getById(1); tak je asi jasné, že v proměnné ‚$user‘ není instance Talíře…

Díky tomu už nikdy nemusíš koukat na definice co co obsahuje, protože je to hned zřejmé z názvu proměnné a není třeba ani psát komentáře a kód je ‚self-explanatory‘, což se tak už mnoho let dělá snad ve všech větších firmách. A součástí toho jsou i názvy tříd. Ne jen proměnné by měly být pojmenovány tak, aby bylo jasně zřejmé, co v nich je, ale také třídy/rozhraní/traity a vlastně všechny soubory a složky by měly být pojmenovány tak, aby bylo jasně zřejmé, co v nich je.

Stejně tak jako složku ‚Presenters‘ která očividně asi znamená, že v sobě má Presentery nepojmenujeme Foo, tak bychom ani třídu ‚ContactFormFactory‘ neměli pojmenovat například ‚Factory‘ jelikož se neví o jakou Factory jde a stejně tak ‚IContactFormProcessor‘ by nikdy neměl být pojmenován ‚ContactFormProcessor‘ protože není jasné, o co jde.

Edit 1:
Psát C- prefix na začátku každé třídy ztratilo význam proto, že pokud máme:
C- třídy
I- rozhraní
T- traity

Tak každý, kdo kdy začne přemýšlet nad touto problematikou zjistí, že pokud máme pro každý typ nějaký prefix, tak máme striktně oddělené typy jednotlivých souborů, což je velké plus pro orientaci a rychlý vývoj.
Taktéž ale zjistíme, že když máme v kódu například 60% tříd, 30% rozhraní a 10% traity, tak to znamená, že na 100 souborech napíšeme 60*C-, 30*I- a 10*T-

A ten, kdo se nad tím zamyslí hlouběji zjistí, že když vypustíme prefix C-, tak ušetříme na prefixech 60% prostoru a tedy i paměti a bla bla. Přehlednost a roztřízení ale zůstane zachováno. Proč? Protože nám vznikne toto:
''- třídy
I- rozhraní
T- traity

takže třídy POŘÁD mají svůj rozlišující prefix. Akorát je prázdný. Což jsme ušetřili znaky ale vůbec nijak jsme nesnížili informační hodnotu. Protože i vůbec nic je informace.
Jendou jsem četl článek o tom, že internet váží stejně jako průměrně velká jahoda. Počítali tam s tím, že každý aktivní spoj (kladně nabitá částice, spojené drátky kterými proudí proud atd.) má nějakou váhu navíc oproti svojí surové váze. Tedy kdyby byly všechny přístroje vypnuté a vynulované, tak by podle tohoto článku internet vážil přesnou 0. To je ale zavádějící informace, jelikož i to, že je to vypnuté a jsou všude pomyslné nuly je taky informace, stejně jako prázdný prefix před názvem tříd.

Pokud ale přestaneme přemýšlet a řekneme si no tak když to udělali s třídami tak proč bychom to nemohli udělat my s interface a traitami, tak se chováme stejně jako opice v tomto výzkumu.
Prostě tím, že se odstranilo například C- jako prefix od tříd se zachovala stále stejná výpovědní hodnota. Co má prázdný prefix (nemá tam I, T ani C) je třída. Pokud ale odstraníme další díky opičímu syndromu, tak se najednou stane, že 2 různé typy souborů mají prefix stejný a tedy je již nelze od sebe odlišit. Je to to stejné jako bychom se rozhodli dávat třídám (class) prefix I-, čímž by byl prefix stejný jako u rozhraní. U tohoto si říkáte, že to je nesmysl a proč to dělat? No odstranit prefix I- od rozhraní je to stejné.

Editoval Polki (10. 1. 2021 15:32)

Jazyk Dart má jednu featuru, kterou strašně chci dostat do PHP. Možnost implementovat tzv. implicitní rozhraní.

O co jde. Když vytvořím třídu, tak tím vytvořím:

• rozhraní (název + veřejné metody bez těl)
• implementaci (těla metod + privátní věci)

Obojí sdílí jeden název.

Problém je v tom, že implicitní rozhraní nejde implementovat. Tj nejde napsat:

class MockPDO implements PDO
{
	...
}

Aby to bylo možné, to bych právě moc rád viděl v PHP. Řeší to elegantně pár věcí, jako třeba právě testování. (Btw není to tak snadné, muselo by se vyřešit co s properites a protected metodama.)

Ale zároveň to zcela pohřbívá argumenty kolem psaní prefixů/suffixů pro rozhraní.

David Grudl napsal(a):

@Polki jak zjistíš, jakého typu je $this->visibility? Podíváš se do deklarace property?

To záleží na kontextu.

1. Je to řetězec obsahující nějaký význam (například z CSS ‚visible‘, ‚hidden‘, ‚none‘) atd…
2. Je to instance třídy, která reprezentuje jednotlivé stavy viditelnosti, které mohou být například reprezentovány v databázi jako číselník. V tomto případě by však měla být visibility vypsatelná a tedy by se s ní mělo dát pracovat jako s řetězcem, přičemž o to, aby se nastavila na správný objekt by se měl starat nějaký Setter a o to aby se získala správná textová hodnota by se měl starat nějaký Getter.

Pokud by tam měl být uložený bool, který definuje jestli je to viditelné nebo ne, pojmenování by bylo například $visible, pokud by tam měla být výhradně třída, tak například $visibilityType, kde v coding standardu je, že typy jsou vždy číselník, kde každý typ je reprezentován instancí třídy. Atd..

Tedy pokud je nastaven dobře CodingStandard, tak je to zřejmé vždy hned:

V $this->visibility je uložena instance třídy Visibility jež vypadá nějak takto:
/**
* @property string $name Name of concrete visibility type
*/
class Visibility
{
use \Nette\SmartObject;

private string $name = '';

public function getName(): string
{
return $this->name;
 }

public function setName(string $val): void
{
$this->name = $val;
}
}
\--

Tady je to hned jasné. Například:

Visibility může nabývat několika konkrétních hodnot takže číselník → třída. Na každý druh visibility je potom jiná třída. Například UserVisibility, ProductVisibility atd…

Name je obecný název, který se může skládat ze série znaků → řetězec.

S takovou jmennou konvencí a nastaveným standardem jasně každý, kdo se podívá do kódu vidí, že $this->visibility je instance třídy Visibility a třeba $this->userVisibility je instance třídy UserVisibility, přičemž naproti tomu v proměnné $this->name je uložen řetězec, tedy string.

Pokud by však byla nějaká jména, která je nutno vyjmenovat a tedy udělat v z nich číselník, jako například názvy všech českých měst, pak by se proměnná jmenovala $this->cityName, což by byla podle standardu jasně instance třídy CityName.
V realitě samozřejmě použijeme u měst spíše než číselník, tak celý objekt kde bude u každého města název, počet obyvatel, velikost atd.., takže by třída CityName neexistovala a místo ní by byla například třída City, která by v sobě měla proměnnou $name, která by mohla zase nabývat všech možných hodnot, protože víme, že počet měst už omezuje sama tabulka. (Takový rozšířený číselník.)
Toto je jen příklad.

Tedy jak jsem psal hned na začátku. Je třeba znát kontext a hlavně standard, ve kterém pracujeme.

Ale pokud nazvu tyto dvě třídy: CFormFactory a ‚IFormFactory‘ stejně tedy prostě FormFactory tak mi žádná znalost kontextu ani CodingStandardu nepomůže zjistit, co se vlastně reálně za kterým souborem skrývá.

Editoval Polki (10. 1. 2021 16:27)

David Grudl napsal(a):

Jazyk Dart má jednu featuru, kterou strašně chci dostat do PHP. Možnost implementovat tzv. implicitní rozhraní.

O co jde. Když vytvořím třídu, tak tím vytvořím:

• rozhraní (název + veřejné metody bez těl)
• implementaci (těla metod + privátní věci)

Obojí sdílí jeden název.

Problém je v tom, že implicitní rozhraní nejde implementovat. Tj nejde napsat:

class MockPDO implements PDO
{
	...
}

Aby to bylo možné, to bych právě moc rád viděl v PHP. Řeší to elegantně pár věcí, jako třeba právě testování. (Btw není to tak snadné, muselo by se vyřešit co s properites a protected metodama.)

Ale zároveň to zcela pohřbívá argumenty kolem psaní prefixů/suffixů pro rozhraní.

To je super myšlenka. Pokud by se tohoto dosáhlo, tak by to byla paráda. Ovšem to by se pak Interface a Class staly jedním, což by mělo potom smysl sjednotit i názvosloví. Dokud se tak ale nestalo, tak nevidím důvod sjednocovat názvy pro dvě zatím různé věci.

Edit 1:
BTW příklad na implicitní interface v Dartu: https://www.codevscolor.com/…it-interface

Jak by v tomto případě DI rozlišilo, jestli má do třídy s konstruktorem:
public __construct(private Vehicle $vehicle,) {}
Předat instanci třídy Vehicle nebo instanci třídy Audi?

Případně jak by poznalo DI, že se jedná o generovanou továrničku, pokud by to nebylo interface? Stačilo by mít jako obsah jen jednu abstraktní metodu ‚create()‘?

Editoval Polki (10. 1. 2021 20:06)