Postřehy ohledně architektury JavaScriptu

[YF]

už jsem psal, že gettery/settery jsou metody (pokud neignorujemene properties tak těžko říct)

To jako metody s trochu jiným zápisem?

myslíte properties? asi ano, ale nepoužívám jazyky, které je mají, nepřemýšlím o nich, gettery a settery jsou metody

Z filozofického hlediska je jedno co jsou, důležitý je pouze únik stavu z objektu. Respektive, jeho potencinální zneužití.

můžete uvést příklad?

proboha radeji ne ...

[Reklama]

[Ivan Nový]

Dobře víš, o co se jedná, ale chceš rozpoutat další flame na téma C++ (Java, C#, Python...) nejsou objektové jazyky, správně je to jedině ve Smalltalku a vy všichni, co nepoužíváte Smalltalk, jste jen pojídači koláčů. Promiň, ale toho se nehodlám účastnit.

Já vím, o co se jedná, ale nevím, co myslíte vy všichni. Takže jednodušeji: Čím se liší gettery/settery od metod (vynechte pojednání o způsobu zápisu, jde mi o funkcionalitu, neboli co to má dělat).

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

[v]

Dobře víš, o co se jedná, ale chceš rozpoutat další flame na téma C++ (Java, C#, Python...) nejsou objektové jazyky, správně je to jedině ve Smalltalku a vy všichni, co nepoužíváte Smalltalk, jste jen pojídači koláčů. Promiň, ale toho se nehodlám účastnit.

Já vím, o co se jedná, ale nevím, co myslíte vy všichni. Takže jednodušeji: Čím se liší gettery/settery od metod (vynechte pojednání o způsobu zápisu, jde mi o funkcionalitu, neboli co to má dělat).

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

takže metody, které vracejí hodnoty, které jsou funkcí stavu objektu jsou špatně?

[Honza]

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

takže metody, které vracejí hodnoty, které jsou funkcí stavu objektu jsou špatně?

Nebylo by nejlepší ty objekty raději zavřít do krabice? I s tou kočkou, a neotvírat!?

[BoneFlute]

Dobře víš, o co se jedná, ale chceš rozpoutat další flame na téma C++ (Java, C#, Python...) nejsou objektové jazyky, správně je to jedině ve Smalltalku a vy všichni, co nepoužíváte Smalltalk, jste jen pojídači koláčů. Promiň, ale toho se nehodlám účastnit.

Já vím, o co se jedná, ale nevím, co myslíte vy všichni. Takže jednodušeji: Čím se liší gettery/settery od metod (vynechte pojednání o způsobu zápisu, jde mi o funkcionalitu, neboli co to má dělat).

Řekl bych, že problém může být něco takového:

Jednak gettery a settery vytváří tak plochou strukturu, že je k nerozeznání od struct. Což není tak úplně vončo. Krom doménových objektů se pak vytvářejí obludné fasády, a podobné nepohodlné věci. No, to asi nemusím vysvětlovat.

Spousta jazyků, jako je Java nemá properties, takže i když potřebujeme vlastně jen obyčejný field, ke kterému ale potřebujeme hlídat přístup, tak nás to nutí vytvářet všude gettery a settery jen z toho důvodu, co kdybychom někdy v budoucnu potřebovali upravit vnitřní chování - což je samozřejně regulérní důvod. Tedy jinak řečeno, gettery/settery jsou vynucenej syntaktickej cukr, který by nebyl potřeba, když by jazyk nebyl tak blbej.

A do třetice, programátoři se prostě naučili používat gettery a settery a tak nějak to bez dalšího přemejšlení převzali, a považují to za vrchol OOP. Mám čerstvou zkušenost z aktuální práce, kde se prostě konstruktory nedělali. Na sdílení kódu používají jen dědičnost. Všechny objekty vytváří skrze settery. A tak podobně. A důvod, proč to tak dělali je ten, že to tak dělali ti před nimi, a ti přece nejsou blbí. No, nejsou, ale zkušenost se získává, s tou se nerodíš.

[Reklama]

[BoneFlute]

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

takže metody, které vracejí hodnoty, které jsou funkcí stavu objektu jsou špatně?

To nutně ne. Ale když si ty metody (settery) nejsou schopny ani zvalidovat vstupní hodnoty - správný formát mailu například? To už by špatně být mohlo, ne?

Nebo když si nejsou schopny, ty settery, zajistit, že když objektu reprezentující fakturu nastavím typ `firma`, tak že musí mět vyplněný IČO? (Narážím na nevalidní stav objektu.)

[v]

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

takže metody, které vracejí hodnoty, které jsou funkcí stavu objektu jsou špatně?

To nutně ne. Ale když si ty metody (settery) nejsou schopny ani zvalidovat vstupní hodnoty - správný formát mailu například? To už by špatně být mohlo, ne?

Nebo když si nejsou schopny, ty settery, zajistit, že když objektu reprezentující fakturu nastavím typ `firma`, tak že musí mět vyplněný IČO? (Narážím na nevalidní stav objektu.)

no tak asi žádná metoda objektu by ho neměl uvést do nevalidního stavu, ne?

[BoneFlute]

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

takže metody, které vracejí hodnoty, které jsou funkcí stavu objektu jsou špatně?

To nutně ne. Ale když si ty metody (settery) nejsou schopny ani zvalidovat vstupní hodnoty - správný formát mailu například? To už by špatně být mohlo, ne?

Nebo když si nejsou schopny, ty settery, zajistit, že když objektu reprezentující fakturu nastavím typ `firma`, tak že musí mět vyplněný IČO? (Narážím na nevalidní stav objektu.)

no tak asi žádná metoda objektu by ho neměl uvést do nevalidního stavu, ne?

To víš ty, to vím já, dokonce i Kit to ví, ale někteří si to nemyslí: https://forum.root.cz/index.php?topic=13741.msg176803#msg176803

[balki]

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

takže metody, které vracejí hodnoty, které jsou funkcí stavu objektu jsou špatně?

To nutně ne. Ale když si ty metody (settery) nejsou schopny ani zvalidovat vstupní hodnoty - správný formát mailu například? To už by špatně být mohlo, ne?

Nebo když si nejsou schopny, ty settery, zajistit, že když objektu reprezentující fakturu nastavím typ `firma`, tak že musí mět vyplněný IČO? (Narážím na nevalidní stav objektu.)

no tak asi žádná metoda objektu by ho neměl uvést do nevalidního stavu, ne?

To víš ty, to vím já, dokonce i Kit to ví, ale někteří si to nemyslí: https://forum.root.cz/index.php?topic=13741.msg176803#msg176803

Presne tak, nemyslim si to. Objekt by mal byt validny v case, ked je potrebne, aby bol validny.

[Wavelet]

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

takže metody, které vracejí hodnoty, které jsou funkcí stavu objektu jsou špatně?

To nutně ne. Ale když si ty metody (settery) nejsou schopny ani zvalidovat vstupní hodnoty - správný formát mailu například? To už by špatně být mohlo, ne?

Nebo když si nejsou schopny, ty settery, zajistit, že když objektu reprezentující fakturu nastavím typ `firma`, tak že musí mět vyplněný IČO? (Narážím na nevalidní stav objektu.)

no tak asi žádná metoda objektu by ho neměl uvést do nevalidního stavu, ne?

Může. Např u objektu osoba můžu mít požadavek na minimální délku jména ... tohle omezení / validace doménového modelu existuje vně objektu, takže za určitého kontextu je objekt v nevalidním stavu.

[v]

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

takže metody, které vracejí hodnoty, které jsou funkcí stavu objektu jsou špatně?

To nutně ne. Ale když si ty metody (settery) nejsou schopny ani zvalidovat vstupní hodnoty - správný formát mailu například? To už by špatně být mohlo, ne?

Nebo když si nejsou schopny, ty settery, zajistit, že když objektu reprezentující fakturu nastavím typ `firma`, tak že musí mět vyplněný IČO? (Narážím na nevalidní stav objektu.)

no tak asi žádná metoda objektu by ho neměl uvést do nevalidního stavu, ne?

Může. Např u objektu osoba můžu mít požadavek na minimální délku jména ... tohle omezení / validace doménového modelu existuje vně objektu, takže za určitého kontextu je objekt v nevalidním stavu.

to je docela legrační všechny instance stringu jsou v určitém kontextu nevalidní

[BoneFlute]

Může. Např u objektu osoba můžu mít požadavek na minimální délku jména ... tohle omezení / validace doménového modelu existuje vně objektu, takže za určitého kontextu je objekt v nevalidním stavu.

Hmm, můžeš uvést jiný příklad? V případě minimální délky jména si zrovna dovedu snadno představit jak to validovat. Buď budu kontrolovat fixně, nebo si jako závislost vyžádám validátor, kterej to bude kontrolovat podle konfigurace. To mi přijde snadný.

[Ivan Nový]

Dobře víš, o co se jedná, ale chceš rozpoutat další flame na téma C++ (Java, C#, Python...) nejsou objektové jazyky, správně je to jedině ve Smalltalku a vy všichni, co nepoužíváte Smalltalk, jste jen pojídači koláčů. Promiň, ale toho se nehodlám účastnit.

Já vím, o co se jedná, ale nevím, co myslíte vy všichni. Takže jednodušeji: Čím se liší gettery/settery od metod (vynechte pojednání o způsobu zápisu, jde mi o funkcionalitu, neboli co to má dělat).

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

takže metody, které vracejí hodnoty, které jsou funkcí stavu objektu jsou špatně?

Určitě a špatně jsou proto, že vrací vnitřní stav objektu, a nevrací obecný a mnohdy jen virtuální stav systému. Objekty jsou od toho aby modelovaly systém, tedy na veřejné úrovni mají implementovat jen vlastnosti systému a ne nějaké pomocné atributy a stavy, ty mají zůstat skryty v objektu. Proto se taky objekty vytváří, že.

Například, když máte objekt faktury, tak vás na tom objektu může zajímat adresa dodavatele a odběratele, ale už by neměl být zveřejněn model, či iterátor, kterým je získáváte.

Samozřejmě když jste zvyklý na vše nadefinovat setter a getter, abyste to měl po ruce, tak ten model taky zveřejníte, protože se určitě někde bude hodit. Ale to je chyba, protože pokud ho někde použijete, v jiném objektu, tak vytvoříte závislost, kterou budete muset udržovat. Navíc tuto závislost těžko odhalíte, když se projeví jen zápisem $invoice->getModel()->getDeliveryAddress($id)

Ještě horší případ nastane, když vám někde někdo pomocí setteru setModel, nastaví jiný model než jaký očekáváte.

[balki]

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

takže metody, které vracejí hodnoty, které jsou funkcí stavu objektu jsou špatně?

To nutně ne. Ale když si ty metody (settery) nejsou schopny ani zvalidovat vstupní hodnoty - správný formát mailu například? To už by špatně být mohlo, ne?

Nebo když si nejsou schopny, ty settery, zajistit, že když objektu reprezentující fakturu nastavím typ `firma`, tak že musí mět vyplněný IČO? (Narážím na nevalidní stav objektu.)

no tak asi žádná metoda objektu by ho neměl uvést do nevalidního stavu, ne?

Může. Např u objektu osoba můžu mít požadavek na minimální délku jména ... tohle omezení / validace doménového modelu existuje vně objektu, takže za určitého kontextu je objekt v nevalidním stavu.

to je docela legrační všechny instance stringu jsou v určitém kontextu nevalidní

Jedine immutable objekty su stale validne. Tzn, po kazdej zmene, stary zahodit a vytvorit novy. Ale ved co, ramky vela, procesoru vela, mozme si to dovolit. Pripadne pristavame dalsiu jadrovku a bude vsecko fporadku.

[v]

Jedine immutable objekty su stale validne. Tzn, po kazdej zmene, stary zahodit a vytvorit novy. Ale ved co, ramky vela, procesoru vela, mozme si to dovolit. Pripadne pristavame dalsiu jadrovku a bude vsecko fporadku.

ani ty ne, tak jak to uetoyo napsal