Rozhraní pro přístup k privátním proměnným objektu

[Solid.Sn]

[Pavel]

[if.then]

V čem je problém public proměnných ve třídě? Vždyť to odvádí stejnou práci jako kombinace normálního getteru/setteru, ne?

EDIT: Ty define jsou fakt prasárna.
_________________
For guns and glory, go to www.ceske-hry.cz.
For work and worry, execute VC++.

[igor]

Protože ideologie. Prý je to vždy součástí vnitřního stavu objektu a ne jeho rozhraní a gettery a settery jsou tak super, že za cenu neskutečného zasviňování kódu získáš boží výhodu v tom, že pokud trochu změníš implementaci a tu proměnnou budeš muset po těch úpravách ještě nějak zpracovávat, tak to nemusíš měnit v kódu používajícím danou třídu. Samozřejmě je přece úplně jasné, že pokud potřebuješ dělat změny, tak to budou právě jen blbůstky co jdou vyřešit v těch getterech a setterech, ehm.

(ale jo, já to chápu u nějakého enterprise programování, ale slepě se toho držet i např. v soukromých herních projektech v C++ je imho fakt hovadina)

[rezna]

je to treba o validaci tech hodnot - tam s public promennou neuspejes -> pokud to neosetris na vsech mistech, kde s ni pracujes, ...

to jsou proste ty dobre programatorske navyky, ktere ale vic jako 80 % programatoru nema a proto pak do noci ladi, ladi a ladi a nevi, kde je problem

pritom staci tak malo ...

[igor]

Jasně, ale často jsou prostě případy, kdy tu validaci nepotřebuju, nemá tam smysl a ani prostě nikdy nebude mít (a už vůbec ne tak, že by mě při nějaké modifikaci gettery a settery zachránily) - hlavně se bavím o situaci, kde je nějaká proměnná dost low-level záležitostí a nemá smysl kolem toho dělat nějakou omáčku, třeba u těch her se to myslím stává často, např. různé pozice a jiné vektorové hodnoty - ostatně četl jsem už dost článků od profi vývojářů, kteří se k tomu taky staví podobně.

Bavím se teda spíše o tom C++ a uvědomuji si, že je to nečisté podle zásad, které samy o sobě jsou rozumné. Z pohledu toho, co se hlavně dělá v nějakých modernějších jazycích, kde se vše odehrává trochu víc hi-level a jde o nějaké velké udržovatelné systémy, to prasárna bude.

[Ladis]

[Tringi]

Pakliže je potřeba validace, určitě se nějaký setter hodit může, ale pak je třeba domýšlet další větev programu: proč může něco nastavit špatnou hodnotu, a co by se mělo stát když se tak stane.
Nebo použít takový datový typ, aby možnost neplatného zadání prostě vylučoval, např. bool pro příznaky, unsigned pokud nechci záporné hodnoty, enum pro výčet rozumného množství možných hodnot. Zde pak pomůže i překladač.
Ap ropo, podobné "properties" jsem si implementoval několikrát taky (viz ext::vartor), v důsledku snaha o maximálně obecnou šablonu asi ani nestojí za to, protože pokaždé chceš nebo potřebuješ něco trochu jiného, a každá varianta má své zápory.
_________________
WWW | GitHub | TW

[rezna]

@igor: az ukaze cas a profiler ze dana property je opravdu ten bottleneck v programu, ktery tak usilovne hledas, pro me za me se treba zacni modlit k Alahovi aby ti pomohl a nebo predelej property na public membera

do te doby proste ne. techto premature optimizations vidam v kodech tuny a jenom to prinasi bolest.

treba nemoznost zmenit jednoduse implementaci problemu, bez toho aniz bych zasahnul na tisici ruznych mistech ...

navic v debugu je proste zahodno testovat vsechno mozny - nas kod treba bezi s ASSERTAMA tak 5-6x pomaleji nez bez nich ...

[Pavel]

[Pavel]

[igor]

@rezna:
Já jsem právě nepsal nic o výkonu. Já jen psal, že pro některé problémy mi to přijde jako přehlednější a jasnější přístup, protože v daném případě getter/setter/property nemá absolutně žádnou výhodu a jenom dělá bordel v kódu (aspoň v C++). Jedná se fakt spíše o lowlevel záležitosti (jo, můžeme z toho udělat struktury, ale ta hranice nemusí být až tak jasná), kde chci mít pocit, že sahám přímo do míst v paměti a ne že volám nějaké metody, i když kompilátor to může nakonec udělat stejně. Je prostě jednodušší a rychlejší napsat to "OOP špinavě", protože vím, co chci přesně udělat - ty věci se fakt určitě nebudou nikdy měnit nebo jestli jo, tak určitě víc než tak, že budu moci použit to původní rozhraní - např. ty vektory nebo ze složitějších třeba nějaké "syrové" enginové objekty, které chci umět bleskově alokovat a dealokovat v paměti nějakým stack alokátorem, chci mít s nimi možnost zacházet jako s kusy paměti a je mi předem (nebo klidně nepředem, ale najednou narazím na to, že je to bottleneck) jasné, že to tak prostě musím udělat.

Právě si myslím, že pro věci popsaného typu takto jde možná překvapivě udělat přehlednější kód méně náchylný k chybám, než nějakým zamořováním gettery/settery/properties, ten kód může být krásně čitelný.
Vím o těch zmíněných OOP zásadách a jejich výhodách, ale nějak nevěřím, že to fakt je the silver bullet pro každou situaci. Jasně, že to tak nebudu dělat třeba v nějakém typickém velkém javovém projektu.
Tímto s tím končím, protože si myslím, že si vůbec neodporujeme a už k tomu nemám co říct, klidně to samozřejmě můžu vidět celé blbě.