Je PHP nutné k uplatnění?

[perceptron]

Stačí se podívat na příklady použití Javy v dokumentaci, které jsou z velké části napsány procedurálním stylem. Hromada metod v knihovnách začíná na set... a get..., což s OOP moc nesouvisí. Programátoři pak tento styl slepě používají ve svých aplikacích a dělají další procedurální gettery a settery.

gettre a settre su v jave lame nahrada za properties (lombok anyone?), ktore c# a spol riesia lepsie, ale oop nie je o gettroch a settroch, ked je tu este inheritance a interfejsy, ktore java rozhodne pouziva.

ktory projekt / jazyk je podla vas vzorom pre oop?

lebo oop nie je o gettroch a settroch, pokial teda nie ste na urovni, ze pre kazdy private member automaticky nechate ide vygenerovat getter a setter.

/a red herring protivystrel: kolko phpckarov mapy a foldy realne v projektoch pouziva?/

[Reklama]

[Kit]

gettre a settre su v jave lame nahrada za properties (lombok anyone?), ktore c# a spol riesia lepsie, ale oop nie je o gettroch a settroch, ked je tu este inheritance a interfejsy, ktore java rozhodne pouziva.

Java mi nevadí, pouze se mi příčí její chybné používání. OOP je hlavně o přesouvání algoritmů směrem k datům, do objektů. Gettery a settery tento princip narušují. C# problém getterů a setterů neřeší, ale spíš zhoršuje.

ktory projekt / jazyk je podla vas vzorom pre oop?

Objektově se dá programovat téměř v jakémkoli jazyku. Tedy i v Javě, PHP, C#, Pythonu,... Žádný z nich programátora nenaučí psát objektově, to se musí naučit z kvalitních učebnic a od kvalitních učitelů.

lebo oop nie je o gettroch a settroch, pokial teda nie ste na urovni, ze pre kazdy private member automaticky nechate ide vygenerovat getter a setter.

Naopak. Pro privátní atributy nedělám žádné gettery ani settery. Není důvod. Prostě je nepotřebuji. Nemanipuluji s privátními atributy objektu, ale s objektem.

/a red herring protivystrel: kolko phpckarov mapy a foldy realne v projektoch pouziva?/

Obávám se, že jich zas moc nebude. Přitom vypadají velmi elegantně a jsou i efektivní.

[perceptron]

Objektově se dá programovat téměř v jakémkoli jazyku.

ja som chcel konkretne, lebo toto su take genericke (ehm) vyroky, ze az

Žádný z nich programátora nenaučí psát objektově, to se musí naučit z kvalitních učebnic a od kvalitních učitelů.

a to su ktori? (dufam, ze nedostanem odpoved, ze to su tie, ktore su napisane kvalitne)

Gettery a settery tento princip narušují.

predpokladam, ze sme sa zhodli na tom, ze bezduche generovanie getterov a setterov pre vsetky privatne premenne je blbost (ale to sa da odnaucit dobrou z kvalitnych ucebnic od kvalitnych ucitelov)

napriklad spring dost tlaci do toho, ze settery sa davaju pre zavislosti a gettery a settery sa pouzivaju pre data transfer object. napriek tomu, ze anemicky model neni nic moc, v jave vela moznosti nie je... paradoxne, springovske a JEE architektury na tom funguju, je to udrzovatelne, a predpokladam, ze nik neoponuje voci tomu, ze je to objektovo orientovane.

Obávám se, že jich zas moc nebude. Přitom vypadají velmi elegantně a jsou i efektivní.

takze sme dosli k zaveru, ze tieto konstrukcie su aj v jave aj v php, akurat v php k nim nedosli developeri a v jave ste este k nim nedosli vy :-) ale to sa samozrejme casom zmeni k lepsiemu

[Kit]

Žádný z nich programátora nenaučí psát objektově, to se musí naučit z kvalitních učebnic a od kvalitních učitelů.

a to su ktori? (dufam, ze nedostanem odpoved, ze to su tie, ktore su napisane kvalitne)

Oblíbil jsem si Roberta C. Martina, Martina Fowlera a Bruce Eckela. Samozřejmě jejich učebnice i videa.

napriklad spring dost tlaci do toho, ze settery sa davaju pre zavislosti a gettery a settery sa pouzivaju pre data transfer object. napriek tomu, ze anemicky model neni nic moc, v jave vela moznosti nie je... paradoxne, springovske a JEE architektury na tom funguju, je to udrzovatelne, a predpokladam, ze nik neoponuje voci tomu, ze je to objektovo orientovane.

Pokud je např Spring napsán anemicky, tak se na to můžeme napojit objektově. Píšeme další vrstvu a můžeme ji psát jiným stylem, než jak vývojáři psali Spring. Není tedy nutné jim to vyčítat, ale také není nutné psát jejich stylem. Je jen nutné dodržet rozhraní. Podobně prezentační vrstvu nedělám objektově, ale deklarativně. Proč? Protože se to tak píše lépe a šablony jsou přenositelné mezi programovacími jazyky.

[perceptron]

suhlasim, eckel teda bol jeden cas hviezda Javy, ale asi by ste zistili, ze by ste miestami nad nim prskali, detto pri fowlerovi netreba byt fowlerovskejsi nez fowler [1], mohlo by dojst k zaujimavym pozorovaniam :-) triezvost je dobre ovladat.

inak ja by som fakt chcel vidiet ten tutorialny projekt, lebo zacinam mat pocit, ze su tu nejake vysnivane koncepty bez odrazu v realite

konkretne: ako konkretne by sa na spring dalo napojit objektovo? co by ta este-viac-objektovo-orientovana robila? to ste v reali nieco take robili? ved spring v jave principialne pokryva takmer vsetko, co by z hladiska konkretnej neanemickej architektury taka vacsia aplikacia mohla pokryvat.

viete to elaborovat?

[1] http://martinfowler.com/bliki/GetterEradicator.html

[Reklama]

[Kit]

suhlasim, eckel teda bol jeden cas hviezda Javy, ale asi by ste zistili, ze by ste miestami nad nim prskali, detto pri fowlerovi netreba byt fowlerovskejsi nez fowler [1], mohlo by dojst k zaujimavym pozorovaniam :-) triezvost je dobre ovladat.

[1] http://martinfowler.com/bliki/GetterEradicator.html

Ten odkazovaný článek znám a ztotožňuji se s jeho obsahem. Zcela správně tam tvrdí, že pokud se objektu ptám 2×, měl bych se přinejmenším zamyslet nad tím, zda by nešlo se ho zeptat jen jednou přesunutím části funkcionality dovnitř objektu.

Vím, že to nejde udělat vždy. Pokud to nejde, pokládám si další otázku, jestli ten objekt má být skutečně jen jeden. Často vývojář slepí dohromady několik atributů do jedné třídy. Po jejich rozseknutí do samostatných tříd najednou vidím, že rozvolněním vazeb vznikají kvalitativně jiné možnosti, jak s nimi pracovat.

inak ja by som fakt chcel vidiet ten tutorialny projekt, lebo zacinam mat pocit, ze su tu nejake vysnivane koncepty bez odrazu v realite

Mám ho napsaný v PHP, ale ještě s ním nejsem zcela spokojen. Až přijde čas, vydám ho.

konkretne: ako konkretne by sa na spring dalo napojit objektovo? co by ta este-viac-objektovo-orientovana robila? to ste v reali nieco take robili? ved spring v jave principialne pokryva takmer vsetko, co by z hladiska konkretnej neanemickej architektury taka vacsia aplikacia mohla pokryvat.

Spring neznám, vycházel jsem z tvrzení

napriklad spring dost tlaci do toho, ze settery sa davaju pre zavislosti a gettery a settery sa pouzivaju pre data transfer object. napriek tomu, ze anemicky model neni nic moc, v jave vela moznosti nie je...

Na takové rozhraní se přece dá objektově navázat, ne?

[perceptron]

omg epic combo

Mám ho napsaný v PHP, ale ještě s ním nejsem zcela spokojen. Až přijde čas, vydám ho.

takze vas nevydany projekt ma byt prikladom dobreho navrhu OO projektov...lolwut?

Na takové rozhraní se přece dá objektově navázat, ne?

ano, na rozhranie sa da objektovo naviazat

ja stale ale nechapem, preco by ste chceli na nieco, co je z definicie objektovo orientovane napisane nalepovat vrstvu, ktora ma byt objektovo orientovanejsia...

najma ked tam je presne sustava klasickych veci, interfejsy, dedicnost, settre, dependency injection + best practices

fail z vasej strany vyplyva z toho, ze malo tusite, o com rozpravate a bez prikladov si mozete akurat malovat skvele OO krabice na tabulu.

[Kit]

Mám ho napsaný v PHP, ale ještě s ním nejsem zcela spokojen. Až přijde čas, vydám ho.

takze vas nevydany projekt ma byt prikladom dobreho navrhu OO projektov...lolwut?

Projekt je vydán, ale není open source. Je na tom něco nepochopitelného?

[perceptron]

takze vas neviditelny projekt ma byt prikladom dobreho navrhu OO projektov...lolwut?

[Kit]

takze vas neviditelny projekt ma byt prikladom dobreho navrhu OO projektov...lolwut?

Bacha, aby sis neublížil. Jak vypadá tvůj viditelný příklad dobrého návrhu OO projektů? Máš k němu dokumentaci v češtině, cestine nebo angličtině?

[Kit]

takze vas neviditelny projekt ma byt prikladom dobreho navrhu OO projektov...lolwut?

Bacha, aby sis neublížil. Jak vypadá tvůj viditelný příklad dobrého návrhu OO projektů? Máš k němu dokumentaci v češtině, cestine nebo angličtině?

Sorry, až teď jsem zjistil, že píšeš slovensky (bez diakritiky, tedy mizerně). Takže ve slovenčině nebo slovencine?

[Kolemjdoucí]

Pro začátek by bohatě stačilo napsat definici OOP, jak si kdo představuje Hned by se ukázalo že část účastníků diskuze má už s tímto potíže, namátkou:

procedurální gettery a settery.

Getter/setter je samozřejmě nic než standardní OOP metoda a je na odpovědnosti programátora co tam napíše.

[Kit]

Getter/setter je samozřejmě nic než standardní OOP metoda a je na odpovědnosti programátora co tam napíše.

Že je getter/setter metoda, to je jasné. Méně však je jasné, že takové metody zbytečně rozšiřují rozhraní objektu o přístupy k atributům, které by měly zůstat skryty. Porušují tedy zapouzdření objektu.

[Kolemjdoucí]

Že je getter/setter metoda, to je jasné. Méně však je jasné, že takové metody zbytečně rozšiřují rozhraní objektu o přístupy k atributům, které by měly zůstat skryty. Porušují tedy zapouzdření objektu.

To je velké nepochopení. Getter/setter != povinnost umožnit přímý přístup k členské proměnné. Je na libovůli a odpovědnosti programátora co tam napíše, je to normální metoda.
Že tam někdo píše hlouposti ještě neznamená že je to hloupost samo o sobě.

[Kit]

To je velké nepochopení. Getter/setter != povinnost umožnit přímý přístup k členské proměnné. Je na libovůli a odpovědnosti programátora co tam napíše, je to normální metoda.
Že tam někdo píše hlouposti ještě neznamená že je to hloupost samo o sobě.

Fajn, až uvidím getter/setter podle těchto pravidel, budu nadšen.

Ještě mi poraď, jak mám nazývat ty mizerné jednořádkové gettery/settery, které jen suplují viditelnost public, ale jinak nejsou schopny ověřit ani validitu parametru?