No, stale mi prijde, ze vam to sice chyby najde, ale za cenu vetsiho psani, takze nula od nuly pojde. Rad bych videl priklad. Dejme tomu, ze to mame implementovane proceduralne pres tabulku. Jakym druhum chyb zabrani implementovat to pres rozhrani?
No, to já hlavně nevím jak by to fungovalo přes tabulku...
Interface mi zajistí, že objekt, který přišel má metodu getIvoicer() a getRule(). Díky tomu mohu v kódu napsat něco jako:
inst.getInvoicer().process(inst.getRule)
Já už jsem z céčka vypadl, ale v Pythonu bych musel po vstupu kontrolovat, zda ty metody ten objekt má. Klasické duck typing. Navíc, když vytvořím implementaci nějaké struktury, nesoucí tuto logiku, tak mě to nezkontroluje, že jsem zapoměl na jednu metodu dokavad to nepoužiju. V praxi samozřejmě to bude tak, že problémy vzniknou až v okamžiku refactoringu.
Tedy shrnuto, rozhraní zajištuje:
Že funkci/metodě předávám správný objekt. Třeba, že mi tam něco neuteklo.
Že objekt implementuje všechny povinné metody.
Me se libi Paul Grahamova filozofie, ze nejprve se ten program vytvori na hrubo...
To je sice hezký, ale má to dva háčky: Jednak je to metodika, kterou se budou muset lidé naučit. Já třeba podobný přístup v pythonu opustil, protože mě iritovalo, jak to furt nefunguje - tedy je to přesný opak XP. A druhý háček je v tom, že jak sám říkáte, nemáme implementaci do jazyka.
A tady se bavíme o tom, zda jsme zastánci OOP, ne co je nejlepší. Nejlepší je Ferda, to už víme.
Nevim. Snazit se definovat vsechno tak, aby byly nezavisle veci maximalne explicitne oddelene mi prijde jako diminishing returns.
No, moje zkušenost je taková, že když si práci zjednoduším, a dělám noname objekty s veřejnými atributy, tak pak honím chyby po všech čertech. Takže já prohlašuji, že je to ještě daleko před tou hranicí.
nemyslim, ze to je neco, co prinesl OOP pristup
Podle wikipedie, je zapouzdření jedním ze základních kamenů OOP. Céčko, Paskal, nedejbože Basic zapouzdření před příchodem Smalltaku, Objective C, nebo C++ neumožňovali. Takže já si myslím, že to OOP přístup přinesl.
Co kdyz ta funkce pracuje s vic nez jednim objektem? Pak ji priradit konkretnimu z nich je umela bariera.
Ano. Je. Proč bych takovou kravinu dělal?
Existuji jiste i funkce, ktere zadny novy typ nepotrebuji (a odpada tak duvod mit je v tride).
Samozřejmě. No a? To není nic proti OOP. Prostě mám izolované funkce, které nějakým způsobem pracují s objekty. Pokud si to jazyk vynucuje je přiřadit nějaké třídě (Java), tak si na to vytvořím třídu. Nejdřív budu prskat, jako vy, že je to zbytečnost, ale pak zjistím, že vlastě ještě potřebuju, aby tu funkci používali jen a pouze tyto a tyto třídy, a tak spřísním oprávnění a umístím to do modulu. Nakonec zjistím, že to stejně někam umístit musím, ve vzduchu to bejt nemůže.
Fajn, v čem je problém?
Po pravdě řečeno, když bych měl projekt, ve kterém by se tato situace stávala často, pravděpodobně bych změnil styl, nebo jazyk. A nedělal to dle OOP. V mé praxi je to ale přesně naopak. Většinou těchto izolovaných funkcí je minimum. A to prosím nedělám GUI.
Co kdyz si date funkci dvou typu do tridy toho prvniho, a pozdeji ji budete chtit rozsirit v tom druhem (ale kod muze zustat stejny)?
Nevím zda vám rozumím. Není to ten samej problém co víše?
235 Odpovědí
74314 Zhlédnutí