Paráda. Tákže:
Napr. zapouzdreni je vlastnost modulovyho systemu. Ktery si lidi casto pletou s objektovym. Nebo je to treba taky totez.
Imho znepřístupňovat vlastnosti a funkcionalitu má smysl na úrovni modulů i na úrovni tříd. Jsem zvyklý při zapouzdřování myslet hlavně na to znepřístupňování na úrovni tříd, ale musí se s tím velmi opatrně. Špatně se to pak jednotkově testuje (což se dá většinou obejít), ale hlavně to často není potřeba, pokud se dodržuje SRP.
Polymorfismus je zalezitost typovyho systemu. V dynamickym jazyku me tohle netrapi, ve statickym musim mit po ruce interfacy nebo abstraktni tridy.
V dynamickém jazyku mě právě trápí, že ten interface kolegové často použít nemusí a tím se zhoršuje orientace v kódu.
OO navrh je staticky pohled na relace mezi objekty. Taky znamo jako ER diagram.
Dostal jsi mě. Ale víš co jsem myslel.
Design patterny tohohle typu jsou take znamy jako 'chybejici vlastnost jazyka'. Tj. napr. namisto factory patternu muzu pouzit proste obycejnou funkci.
Viz http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures
Asi úplně nerozumím argumentu. Místo factory patternu můžu použít i obyčejnou funkci. Můžu i nalinkovat funkčnost zkompilovanou z assembleru. Jsem programátor. Můžu cokoliv.
Dependency injection znamena 'posli mi objekt jako parametr, at si ho nemusim vytvaret sam'.
Tak hlavně by mělo platit, že ho nemůžu vytvářet sám. Protože v různých situacích chci různé implementace toho samého rozhraní. Tam kde ten objekt potřebuji, tak tam se nechci starat o to, jaká ta implementace to bude. Např. mock při jednotkovém testování. Nebo implementace pro konkrétní databázi, jako je to např v PDO v PHP.
Popravde benefit pouzivani principu SOLID jsem nikdy moc nepochopi, treba mi to nekdo vysvetli na prikladu. Stejne tak jsem nikdy neprisel na to, proc navrhovat aplikace timto komplexnim zpusobem co pouziva milion hierarchii a rozhrani. Podle me je takovych systemu poskrovnu, napr. operacni system nebo GUI.
SOLID je celá sada doporučení a težko se udělá příklad do jednoho komentáře. Ale benefity jsou např: Snadná znovupoužitelnost již naprogramovaného. Dobře testovatelné jednotkovými testy. Minimalizace stavů, kdy opravou jedné funkcionality rozbiji jinou.
Ale samozřejmě OOP může být dobrý sluha ale velmi zlý pán.
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Alespon v erlangu je objekt nejaka isolovana vypocetni jednotka (actor, agent, proces, vlakno, apod.) a ne pouze obycejny dict v prestrojeni.
Pokud je problem ze kolegove nemuzou byt svazani sveraci kazajkou jazyka, jako v pripade chybejicich rozhrani v dynamickych jazycich, pak je to organizacni problem. V dynamickym jazyce bouchne driv nez ve statickym. Co je lepsi, tezko rict. Pro me je lepsi kdyz ten bolak praskne driv nez pozdeji a zacne se resit skutecny problem - spatna organizace lidi.
Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.
O SOLID a dependency injection se hadat nebudu, nemam s tim zkusenosti. Ale prijde mi to zbytecne komplikovany.