Anonymní profil ekral – Programujte.com

#58 vitamin

No je to jasný offtopic, ale když člověk čte, co tu Kit uvádí za tvrzení, tak se to nedá prostě vydržet a neopravit to. Kit prostě tvrdí, že gc v c# a asi i v jave a RIIA v c++ jsou prostě špatně a jediné kde je to "dobře" je PHP.  A vůbec neřeší otázky výkonu atd.

Ale abych citoval přesně Kita:

RAII je jen taková berlička, která by fungovala dobře, kdyby v C++ fungovaly destruktory tak jak mají.

Prostě ultra nesmysl. V c++ fungují destruktory jak mají, je tam prostě víc možnost:

• automatická správa paměti pro objekty na zásobníku, static a extern objekty.
• manuální správa paměti pro objekty na haldě,
• atuomatická správa paměti na haldě pomocí chytrých ukazatelů (reference counting) a
• je možné použít i GC, ale c++ myslí definuje jenom interface a není tam konkrétní implementace GC.

RIIA potom není jenom otázka správy paměti, ale doporučený postup pro exception-safe resource management v c++ a dalších jazycích, kdy každý resource má mít svůj handler na zásobníku a využívá se toho, že objekty na zásobníku se uvolní i v případě vyjímky a zavolá se desktruktor.

#49 Kit

Čteš vůbec co ti tady lidi píšou? Však ti p3can v tady tom vlakně o tom using jasně psal:

nvm co resis ze GC v C# funguje spatne kdyz v C# se deterministická destrukce resi pres using ( ale to uz se tu parkrat resilo :) )

#2 Flowy
 

Podle mně se u SaveChecker<K, V> zadává type parametr, zatímco u extends HashMap<K, Boolean> se zadává type argument. Boolean není platný název generického type parametru, ale přímo typ. Vzhledem k tomu že u HashMap<K, Boolean> dáváš jako konkrétní type argument natvrdo Boolean, tak si myslím, že by mohlo stačit tohle (ale netestoval jsem to, nemám tu javu, jenom c# a c++):

public class SaveChecker<K> extends HashMap<K, Boolean> {

    @Override
    public Boolean get(Object key) {
        Boolean result = super.get(key);
        if (result == null) {
            result = Boolean.TRUE;
        }
        return result;
    }
}

#43 Kit

Jinak u toho příkladu co píšeš, tak v c++11 záleží co je to za třídu.V c++11 a vyšším to můžeš to právě hodně "vytunit", můžeš si řídit kopírování, přesouvání a přiřazování a nebo tohle všechno můžeš zakázat. Klidně můžeš zakázat přiřazení, že ani nepřeložíš. mezi sebou nepůjde přiřazovat atd. A nebo můžeš při přiřazení naopak převést třeba alíka na rvalue a přesunout vše co má do Azora. Je to tam prostě složitější, ale c++ to zvládá v pohodě. Jenom je potřeba být opatrný s ukazately a raději vždy použít RIIA, což se vracím k tomu, že je to v c++ základ.

#20 Kit

Jako c++ má normálně deterministickou destrukci objektů. RIIA je způsob jak po sobě může objekt uklidit i když k vyjímce a je to prakticky základ c++ (Bjarne Stroustrup to nikdy nezapomene zmínit v žádné přednášce). C# nemá deterministickou destrukci, ale nabízí klíčové slovo using a IDisposable. 

Jinak souhlasím, že je lepší v c++ používat standardní knihovnu, mně třeba ten příklad s lambda výrazy, for_each a range based loop. Jenom tam je trochu trikové, že defaultní konstruktor istream_iteratoru vrací konec streamu.

#178 Flowy

avyse pri komunikacii s okolim moc prilezitosti na zmenu neni a ked pride zmena tak sa vecsinou musi aj tak menit cela logika cize v tomto pripade to tiez neni problem ...

Tohle jde úplně proti veškerému vývoji v návrhu aplikací za posledních 30 let. Samozřejmě, že nemusíš a ani nechceš měnit aplikační logiku z důvodu jiné komunikace s okolím. 

Ale jinak souhlasím, pokud chceš pokaždé měnit aplikační logiku aplikace, když se změní komunikace s okolím aplikace, tak opravdu memusíš gettery ani properties používat. 

#150 ekral
Uff, no už mně to taky ujelo, taky sem pochopil že ten učitel je na p3cana. Kit mně právě vždycky překvapí tím, že často má pravdu a správný pohled, ale není to vždy a potom je ta diskuse složitá. Ale na druhou stranu je to docela inspirující.

#146 Satik
#145 KIIV

p3can měl z hlediska odbornosti vše vždy správně. Kde jste byli, když kit poslal článek který prý gettery kritizuje, když tam naopak Fowler dokazuje že gettery jsou opravdu užitečné. Kde jste byly, když kit  sice vůbec nevěděl jak prakticky funguje MVVM, ale už ho kritizoval protože je od Microsoftu. Kde jste byli, když si kit pletl PM a MVP. Kde jste byli když kit tvrdil, že MVC není GUI architektonický vzor? Kde jste byli, když Satik psal nesmysly o populitsitkých properies, když důvodem properties v c# jsou právě vrstvy sw, tak jak píše fowler?

Hlavně ale, když někdo napíše výkend, tak jste hned hrozně chytří. Nedivím se, že to p3can už nevydržel., ale učit by p3can stopro měl :).

#141 Kit

Však je to prosté. OOP má svá pravidla, která stanovují chování mezi objekty, ale z každého pravidla mohou existovat výjimky. Základním pravidlem je umístit chování objektu dovnitř objektu. Pokud však máme více vrstev, můžeme toto pravidlo částečně porušit a tam, kde to potřebujeme, můžeme oddělit chování (metody) od dat, ale se souvisejícími daty (relací) bychom měli pracovat současně.

No konečně se shodneme. Poslal jsi odkaz na článek od Fowlera, který gettery právě z toho důvodu obhajuje, Sám máš v příkladu getter. Explicitně tam píše:

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

A to přímo odpovídá co píše Anders Hejlsberg.

We just think the time is right for a language that makes it easier to create components. Developers are building software components these days. They're not building monolithic applications or monolithic class libraries. Everyone is building components that inherit from some base component provided by some hosting environment. These components override some methods and properties, and they handle some events, and put the components back in. It's key to have those concepts be first class.

Takže tadáááá :D, všechno do sebe zapadadá. Protože SW v dnešní době už není monolitický blok, ale napak je rozdělený do vrstev a komunikujících komponent, tak přesně tak jak píše Fowler, je dobré mít přímo podporu properties v jazyce.

#139 Kit
Ten fowler tam úplně jasně píše, že gettery mají svoje uplatnění. Není to možné ani pochopit jinak, píše to tam dost explicitně.

Ale abych se ujistil, jakým způsobem interpretuješ psaný text, jaký je podle tebe význam těchto vět?

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.

#136 Kit
p3can ti to vysvětlil úplně luxusně. Já jenom dodám, že pokud teda odkazuješ na Fowlera, tak asi budeš překvapeny, že sám zahrnuje MVC do GUI architektur, pak se podívej jak a proč MVC vzniklo a nakonec se zamysli nad tím co znamená to View v MVC.

Co se týká getterů, tak opravdu se Kit dostal vlastní citací. Doporučuju ten článek přečíst kitovi a (taky Fowymu) ještě jednou, protože není o tom, že jsou gettery se nemají používat, ale uvádí kdy jsou vhodné a kdy ne. A ještě jednou, to co považuješ za vytržené z kontextu je prakticky hlavní myšlenka článku.

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.

což je zobecněn toho co jsem už citoval:

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

Jako já chápu vaši motivaci, ale situace není tak černobílá a properties mají svůj význam, jen je nutné je správně používat. S tím, že čistě puristický OOP návrh nemusí být ten nejlepší pro všechny případy. Sám si myslím, že properies s jasně danými pravidly v c#, jsou lepší variantou díky jasně daným pravidlům než gettery a settery bez pravidel například v jave.

#123 Kit
MVVM není vynález Microsoftu, ale první implementace Presentation Modelu navrženého Fowlerem. Ale jo, napiš Fowlerovi, že jsi to šecko promyslel a že si jako osobně myslíš, že je to blbec a že ty mu dokážeš že MVC je lepší.

Prostě View nemá přístup k modelu a ViewModel není závislé na View. Výsledkem je že napíšeš VM a Model jednou a pak  doděláš View pro iOS, Andorid, W8.1, WP8.1, Xbox, ale taky i částečně pro OSX a Linux. A to všechno plně nativně! Jinak MVVM je i pro javascript a html (například knockout), není to jenom Microsoft Technologie.

Vztah VM a Modelu opravvdu MVVM moc neřeší, to už je na tobě, jak si to zorganizuješ.

Ale ještě jednou, jestli se ti to nezdá, tak to nepoužívej :D.

#119 Kit

Ale to si nerozumíme. ViewModel vůbec neví jak bude vypadat konkrétní view, s každým view omunikuje spolu pomocí stejného interface, které má jediný event. Určitě je tam co vylepšovat, ale to už je na jinou debatu. Vysvětluju to jenom jako ukázku využití properties.

#117 Kit

Ale to rozhraní musíš definovat předem. Ale ViewModel prostě předem neví jak bude vypadat View. Takže to tak nejde a s DI to prostě nevyřešíš.

#115 Kit

No MVVM je technologie Microsoftu. Výhoda je, že odděluje View od Modelu. Každé View má většinou jedna ku jedné svůj ViewModel. A View je nezávislé na modelu, který může být jeden pro všechny VM. Konkrétní View má k dispozici prostě jen přesně ty data, které potřebuje a nemůže se ani dostat k ničemu jinému. VM potom nevím vůbec nic o view, prostě ho to nezajímá. Celé je to založené na properties a notifikacích o změnách properties a podle mně je to ukázkový příklad toho, kde jsou gettery a settery užitečné.

#113 Kit

Jo to by šlo, otázka jestli to pak neřešit AOP pomocí atributů neobjektově. Ale z hlediska OOP je to injektování dobré řešení. Otázka ale je co s ViewModelem, který nemá referenci na view, prostě vůbec neví že nějaké view existuje a už vůbec nemá ani ponětí o tom jak by to View mohlo vypadat. Jediné co umí, tak poslat view přez prostředníka název property, kterou má aktualizovat a View má názvy propertiew, které má zobrazovat. Jak by jsi to přepsal bez getteru a setteru? Jenom připomínám že v tomto případě property  jsou opravdu jen "hloupá" data, které se mají zobrazit, prakticky je to model pro View. Příkazy se předvává ViewModelu pomocí commandů. Například příkaz ZmenJmeno by vzal Property Jmeno, které předtím změnilo view a zavolal privatni Metodu ZmenJmeno(Jmeno), která by už dělal to co jsi popsal (validace, logovaní, uložení atd.).

#109 Kit
Jo a co je špatného na getteru?

Clovek adam = new Clovek("Adam");
var jmeno = adam.GetJmeno();

nebo

Clovek adam = new Clovek("Adam");
var jmeno = adam.Jmeno;

Třeba chci objekt adam serializovat a nechci aby byla trida Clovek zavislá na žádné serializační technologii nebo knihovně?

#109 Kit

Jo šak sem ti psal, že se to dá vyřešit parametrickým konstruktorem. Ale co tohle?

Clovek adam = new Clovek("Adam");
adam.ZmenJmeno("Eva");

#107 Kit
Mám v objektu dva atributy. Pokud změním jeden a nezměním druhý, objekt se stane nekonzistentním. Například změním IP adresu, ale nepřidělím číslo portu. Pokud se pokusím navázat spojení pomocí tohoto poloobjektu, tak selže.

Používání properties způsobuje, že objekt je po určitou část své existence nekonzistentní. Například  

Clovek adam = new Clovek(); adam.Jmeno = "Adam";

Mezi těmito dvěma řádky je objekt adam nekonzistentní - nemá jméno. To může mít vážné důsledky.

S tím souhlasím, ale za to nemůžou properties, ale špatný návrh. V prvním příkladu IP adresy a portu stačí mít třeba jako typ property kompozitní typ IP a port v jednom. V druhém případě kdy nechceš mít člověka bez jména, tak můžeš třeba povolit jen parametrický konstruktor s jménem.

Ale na tomto příkladu:

Clovek adam = new Clovek(); 
adam.Jmeno = "Adam";

nic nezmění, když použiješ obyčejnou metodu, pořád to bude stejně špatně. Já prostě tvrdím, že properties jsou v těch tvých přikladech uplně nevinně :D

Clovek adam = new Clovek(); 
adam.SetJmeno("Adam");

#105 Kit

Otázkou ovšem zůstává: K čemu je to dobré? Tak leda k narušení konzistence objektu, protože pokud změním jeden atribut a nezměním jiný, který s ním souvisí, objekt se stane nekonzistentním.

Setter má mít vliv pouze na jeden související field. Pokud toho dělá víc, tak to už není setter. Ale to pořád nevysvětluje jaký je takový rozdíl mezi tím, jestli napíšu int GetVariable() nebo int Variable { get; } ? Špatně to můžu navrhnout jak v prvním, tak ve druhém případě. Ale u property jde o to, že reflexe může odlišit property, field a metodu.

Mám tam ještě chybu, měl to být:

interface IDemo
{
        int Variable { get; }
}

sealed class  Demo : IDemo
{
        public int Variable { get; private set; }
}

#101 Flowy

#98 ekral
#86 Kit
ti to dokazal na priklade ... upravit interface znamena znicit kompatibilitu so starsim kodom (ci uz vlastnym alebo cudzim)

jako ty myslíš to, že ukázal, že když máš špatně navržený interface, tak je ten interface nanic a nedá se s ním pracovat? Nechápu jaký je podle vás rozdíl mezi tím, jestli překrýváš (override) int GetVariable(); nebo int Variable { get; }. Podle mně to vyjde nastejno, u prvního vydedukuješ to, že je to getter z názvu metody a u druhého to víš přímo podle typu (a související jmenné konvence). Pokud jsou ale obecně gettery a settery zlo, tak je samozřejmě nemusíš používat ani v jave a v c# nemusíš používat property.

Jenom pro ujasnění, v c# můžeš normálně overridovat zvlášť getter a setter:

interface IDemo
{
        int Variable { get; }
}

class  Demo : IDemo
{
        public int Variable { get; private set; }
}

#99 Kit
No má to jasné jmenné konvence Prostě tam kde bys napsal GetVariable() nebo SetVariable(), tak použiješ property a má to i vlastní jmenné konvence. Určitě to jde zneužít, ale špatně se dá napsat i metoda GetVariable(). Podle mně to inteligetní vývojář zvládne a hlavně když používáš komponenty třetích stran tak je to opravdu přehlednější.

Ale jako tohle je už fakt offtopic. Oba jazyky c# i java jsou dost podobné a ty rozdíly nejsou nijak zásadní. Jenom v poslední době byl c# víc inovativní a java víc konzervativní a teprve ve verzi 8 zavedla třeba lambda experessions. Dobré je, že si každý může vybrat co mu víc vyhovuje a že neexistuje jenom jeden jazyk, ale že se ty jazyky vzájemně ovlivňují, nejdřív c# opisoval od javy, teď zase naopak java opisuje od c# a do budoucna to může být zase úplně jinak.

#97 Flowy
Však proto jsem citoval co přesně píše o důvodech proč jsou v c# properties a eventy přímo autor jazyka Anderse Hejlsberga (a taky autor delphi a turbo pascalu):

"there's been a lot of debate in the industry about whether languages should support properties or events. Sure, we can express these concepts by methods .... It's just harder, and there's more housekeeping, and you end up having to do all this work in order to truly express your ideas. "

C# je prostě jazkyk navržený pro efektivní práci a ne pro jazykovou "čistotu".

Proč podle tebe brání properties dalšímu rozšiřování. Nebo co vlastně myslís tímto:

jednoduchost dalsieho rozsirenia

?

Abych ale neodbíhal od tématu, tak můj pocit ze c# a .net je, že je to velmi progresivní a rychle se vyvíjející platforma. Java mi na druhou stranu příjde hodně konzervativní a elitářská. Javista se bude skoro do krve hádat, že properties jsou zlo, protože to není možná úplně čisté z hlediska OOP. Zatímco v .NETu jsou prostě programátoři rádi, že mají přehlednější kód. :NET mi prostě přijde jako vhodnější jazyk pro realisty a Java pro idealisty. Ale samozřejmě je to velké zjednodušení a zobecnění a osobní názor.

Hmm, jaký je rozdíl mezi akcí a daty? Obojí je zaslání zprávy objektu.

Jo to je, ale jak to souvisí s tím že properties zpřehledňují nebo můžou zpřehledňovat práci s kódem. Jinak OOP je jenom jedno z paradigmat moderních jazyků. Úspěch jazyka se nepočítá podle toho jak moc dodržuje OOP nebo cokoliv jiného, ale jak je efektivní.

Osobně ti c# nenutím, pokud neumíš properties a nechápeš nebo nechceš chápat rozdíl mezi akcí a daty tak jak je to popsané na MSDN, tak to určitě neni jazyk pro tebe. Čistě subjektivně se mi prostě libí a je super že existuje i opensource implementace (Mono).

P#84 Kit
Na property se mi nelíbí zbytečná duplicita. Je jen na zvážení programátora, jestli použije property nebo metodu. Do značné míry jsou zaměnitelné, ale každé řešení má jiné rozhraní

No to neni pravda, v c# má to svoje jasná pravidla a i jmenné konvence.

Tady je dopouručení kdy používat properties a kdy ne. Ve stručnosti metody reprezentují akce a properties data:

http://msdn.microsoft.com/en-us/library/vstudio/ms229054(v=vs.100).aspx

In general, methods represent actions and properties represent data. Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects. When it does not violate the following guidelines, consider using a property, rather than a method, because less experienced developers find properties easier to use.

A tady je vysvětlení od Anderse Hejlsberga proč tam dali do c# properties a eventy:

http://www.windowsdevcenter.com/pub/a/oreilly/windows/news/hejlsberg_0800.html

But going back to these key component concepts, there's been a lot of debate in the industry about whether languages should support properties or events. Sure, we can express these concepts by methods. We can have naming patterns like a "get" block or a "set" block that emulate the behavior of a property. We can have interfaces and adapters that implement an interface and forward to an object. It's all possible to do, just as it's possible to do object-oriented programming in C. It's just harder, and there's more housekeeping, and you end up having to do all this work in order to truly express your ideas. We just think the time is right for a language that makes it easier to create components. Developers are building software components these days. They're not building monolithic applications or monolithic class libraries. Everyone is building components that inherit from some base component provided by some hosting environment. These components override some methods and properties, and they handle some events, and put the components back in. It's key to have those concepts be first class.