Anonymní profil ekral – Programujte.com

#182 Flowy

Pokud je závěr, že properties jsou užitečně v rozhraních mezi vrstvami a c# je jazyk navržený pro práci s komponentami, tak souhlasím.

#180 Kit

Tohle jde úplně proti návrhovým principům SOLID. Konkrétní musí záviset na abstraktním, implementace musí záviset na rozhraní. Rozhraní je kontraktem mezi vrstvami aplikace.

Konečně se shodneme, jenom jsi to měl napsat přímo Flowymu. Jako měnit aplikační logiku pokaždé když se mění komunikace s okolím objektu je nejenom proti principům SOLID, ale i proti zdravému rozumu.

Jinak rozhraní je kontraktem mezi vrstvami aplikace a gettery nebo properties jsou součástí tohoto rozhraní, tím zase potvrzuješ užitečnost getterů, tak jak to popisuje i Fowler.

#174 Flowy

No jasně, v nějakém vysněném světě, kde program nekomunikuje s okolím opravdu není potřeba mít gettery :D. S tím souhlasím, ale radši se řídím podle reality a ne podle ideálu.

#172 sleepy
No kit a flowy (omlouvám se satikovi, spletl jsem si nicky) to v tady tom vlákně tvrdí že gettery jsou přímo z programátorského pekla :D. I když flowy psal, že nejsou zlé až tak, ale jenom trochu. Jako všechno se dá použít špatně, dědičnost i gettery.

Píšeš to podle mně uplně přesně, jak s tím DI, tak gettery a souhlasím s tím   

#170 sleepy

Je to na delší vysvětlování, ale nejde o tuhle konkrétní třídu, kde je to samozřejmě jednoduché. U toho příkladu jsem právě kritizoval, že si kit hned udělal base class Phone a od ní dědí podle mně uplně zbytečně. Jinak nepíšu že je špatné plývání objekty, ale třídami a dědičností!!

Jinak tahle debata sklouzla k diskusi o getterech a properties. Kdy kit tvdí, že jsou nanic a díky použití správného návrhu je nemusíš používá, zatímco já, Fowler a další zase tvrdí, že to není tak jednouché není a že pro předávání dat mezi různými vrstavami, což je příklad třeba MVVM, jsou gettery a properties užitečné.

Jinak samozřejmě že, když je to tvůj kód, tak si můžeš pomocí DI vkládat různé komponenty. Ale co když to není tvůj kód a používáš už hotové komponenty od kterých nemůžeš dědit. a kit tvrdí, že nemůžeš použít getter, nebo obecně, že objekt nemá co zpřístupňovat svoje data ani pro čtení. Ale upřímně, mně osobně by se nechtělo měnit kód a vymýšlet nový interface a dělat DI pokaždé, když použiju novou komponentu.

Jinak další příklad je, že mám MVVM v c# a díky monu mi běží nativně na Androidu, ios, osx, linuxu, WP, W, WRT, Xbox atd. A pokaždké chci zobrazit ModelView na jiné technologii a předem ani nevím jaké techologie to budou, ale zároveň mají svoje specifika (pro android je to vetsinou Activita, pro iOS UIVIewController, pro WP8 Page, pro WPF Page). Takže MVVM to řeší tak, že definuje jednouché rozhraní pro notifikaci a data jsou vystavená pomocí properties nebo v jave pomocí getterů. DI je sice fajn, ale gettery tím nenahradíš, někdy jsou prostě situace, kdy si potřebuješ vystavit data pro čtení nebo pro zápis.

Jinak tady je ukázka MVVM pro javu, ale myslím, že jen pro jejich UI controly.

http://www.zkoss.org/zkdemo/getting_started/mvvm

#167 Kit

No co? Ty názvy jsem vymyslel hodinu po půlnoci, tak se nediv. Stejně to p3can blbě implementoval. Máš nějaké vhodnější názvy pro tyto metody?

No možná jestli spíš není problém v tom, jak doslova plýtváš s třídama a podle mně nadužíváš dědičnost. Třída PhoneHome a PhoneWork se podle mně nebudou výrazně lišit, nebo dokonce je máš úplně stejné.

Nezapomeň, že opravdu budeš muset řešit u každé vlastní nadefinované třídy:

• testování rovnosti objektů (jak jinak zjistíš, jestli jsou dvě telefonní čísla stejné?),
• porovnání objektů například kvůli řazení,
• kopírování (deep vs shallow copy), případně přesouvání objektů (move v c++11), 
• serializaci,
• bindování například v MVVM,
• a mnoho dalších věcí o kterých v době návrhu třídy ani nemusíš tušit.

A opravdu jsi si jistý, že budeš chtít pokaždé měnit konstruktor kvůli DI aby jsi tam přidal novou závislost a i tak bys mohl skončit s desítkou závislostí, tak aby byl tvůj objekt použitelný i v jiných knihovnách a komponentách?

#162 Kit

Řazení ani vyhledávání nepotřebuji. Na to mám databázi

Co ? To snad nemyslíš vážně?

#155 Kit

neboli že bychom neměli používat g/s, dokud je skutečně nepotřebujeme a že přináší rizika v porušení zapouzdření. Slovo "shouldn't" znamená "neměli bychom". Neznamená to "nesmíme", ale také to neznamená, že bychom to měli porušovat kdykoli se nám zlíbí a vždy bychom si tato rizika měli uvědomit.

No jo, ale to že bysme je neměli používat zbytečně, přece nezmená, že bysme je neměli používat vůbec.

Už se opakuju, ale ještě jednou doplňuju jak to pokračuje. Jako uznat svou chybu, není ostuda.

I have a lot of sympathy with this motivation, but I fear that just telling people to avoid getters is a rather blunt tool. There are too many times when objects do need to collaborate by exchanging data, which leads to genuine needs for getters.

A nakonec ještě jednou závěr:

Allocation of behavior between objects is the essence of object-oriented design, so like any design, there isn't a hard and fast rule - rather a judging of trade-offs. Putting the behavior in the same class as the data, what Craig Larman calls "Information Expert", is the first choice to consider. But it isn't the only route. Layering often trumps this, many of the Gang of Four patterns separate data from behavior for particular needs. A good rule of thumb is that things that change together should be together. Data and the behavior that uses it often change together, but often you see other groupings that matter more.

Jinýma slovama, gettery mají v kódu své dané místo, Properties jsou v c# proto, protože je to od začátku navržený jazyk, který předpokládá, že moderní SW se skládá z různých více či méně závislých resp. nezávislých komponent a není to jen jeden dlouhý blok programu. Příkladem toho je MVVM.  Ale tahle debata je desítky let stará. Já ti tu jenom vysvětluji motivaci tvůrců c#, která je paradoxně podpořená tím co píše fowler v článku, který jsi sám poslal.

Pokud máš tvořit složitejší systém, který používá víc různých komponent od různých autorů, často v různých jazycích a různých platformách, tak si myslím, že je užitečné aby si objekty předávaly data. Properties tam potom mají své uplatnění s spousta programátorů jsou rádi, že je c# tímto způsobem navržený. Pokud píšeš sám monolitický SW bez jakýchkoliv externích komponent sám, tak chápu, že smysl properties nebo getterů nikde nevidíš.

PM, MVC a MVP jsou všechno GUI architektury. Já řeším že MVVM je příklad, kde mají využití i gettery.

Však ten článek do Fowlera co posíláš potvrzuje, že jsou gettery i užitečné:

There are too many times when objects do need to collaborate by exchanging data, which leads to genuine needs for getters.

#131 Kit

MVVM je jedna z implementací PM v c# která používá public properties. Nepleť si PM s MVP! Další implementaci je třeba knockout pro javascript a typescript. Myslím ale že pojem MVVM se začal používat pro většinu mplementací PM.

Speciálně pro tebe jsem našel implementaci PM pro Javu Zx Framework, kde nečekaně zase používají public gettery a settery:

http://www.zkoss.org/zkdemo/getting_started/mvvm

Podívej se v tom tutoriálu hlavně na ViewModel.

Pak ještě napiš konkrétně co používáš ty, jako jaký zazyk, případně platformu pro to MVC.

Jo a ještě jedno doplnění k výhodam Presentation modelu proti MVC. Ale kdo ví, co vlastně myslíš pojmem MVC. Napiš prosím konkrétní technologie které používáš (jazyk, framework, atd.). Pojem MVC je moc obecný a většinou tím lidi popisují úplně rozdílné věci. 

Takže ještě jedna citace od Fowlera:

The Presentation Model works well also for another presentation logic problem - presentation state. The basic MVC notion assumes that all the state of the view can be derived from the state of the model. In this case how do we figure out which station is selected in the list box? The Presentation Model solves this for us by giving us a place to put this kind of state. A similar problem occurs if we have save buttons that are only enabled if data has changed - again that's state about our interaction with the model, not the model itself.

prezentovat důkazy nějakého obecně platného tvrzení o MVVM.

tohle mělo být:

prezentovat jako důkazy nějakého obecně platného tvrzení o MVVM.

#127 Kit

Pomůžu si citací od Fowlera, popisuje to dost srozumitelně, nevím co k tomu dál už napsat, každému vyhovuje něco jiného, ale neměl by jsi svoji subjektivní oblibu MVC a neoblibu properties a MVVM prezentovat důkazy nějakého obecně platného tvrzení o MVVM.

The Presentation Model coordinates with the domain layer and provides an interface to the view that minimizes decision making in the view. The view either stores all its state in the Presentation Model or synchonizes its state with Presentation Modelfrequently... It's useful for allowing you to test without the UI, support for some form of multiple view and a separation of concerns which may make it easier to develop the user interface. ... Presentation Model allows you to write logic that is completely independent of the views used for display. You also do not need to rely on the view to store state. The downside is that you need a synchronization mechanism between the presentation model and the view. This synchronization can be very simple, but it is required. 

#125 Kit

Tak ty něco neznáš a ani jsi to nepoužil, ale už víš, že to Microsoft udělal blbě :D. A už vůbec ti nevadí, že třeba MvvmCross není vůbec od Microsoftu, ale je to taky MVVM a taky používá properties.

Takže říkáš, že MVC ti řeší nečekaně jenom polovinu toho co MVVM, a co ta druhá polovina? Podle mně se ale asi bavíš o webovém MVC,  MVVM je ale přitom určený hlavně pro nativní klientské aplikace.