Postřehy ohledně architektury JavaScriptu

[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ě?

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.

pokud je to špatně, tak metody můžou vracet jenom "nic", konstantu nebo náhodné číslo

[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).

Ř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íš.

Java není tak blbá, ale absence properties má nutit k více objektovému myšlení, kdy objekty mezi sebou komunikují jen a výhradně pomocí zpráv.

Getter/setter jako degenerovaná zpráva (protože je ve své podstatě servisní, souvisí s objeketem, nikoliv s tím, co objekt modeluje) je pak pronikání procedurálního přístupu do OOP.

[balki]

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

Viem si taku  vec predstavit. Zavola sa konstruktor objektu, ten sa vytvori, len ak vsetky argumenty maju spravne parametre. Ak nemaju, tak konstruktor vyhodi vynimku.
Kazda metoda toho objektu vrati novy immutable objekt, ktory je kopiou povodneho, len so zmenenymi vlastnostami, ktore ma dana metoda menit.  Ak by hrozilo, ze vznikne nevalidny objekt, metoda by vyhodila vynimku.

 

[BoneFlute]

Java není tak blbá, ale absence properties má nutit k více objektovému myšlení, kdy objekty mezi sebou komunikují jen a výhradně pomocí zpráv.

Getter/setter jako degenerovaná zpráva (protože je ve své podstatě servisní, souvisí s objeketem, nikoliv s tím, co objekt modeluje) je pak pronikání procedurálního přístupu do OOP.

Hodně častý je prostě jednoduchý objekt Person {name: String, surname: String}. Na tom toho moc nevymyslíš.

[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.

pokud je to špatně, tak metody můžou vracet jenom "nic", konstantu nebo náhodné číslo

Návratová hodnota metody by měla souviset s modelovanou realitou, nikoliv s implementací toho modelování, a to obecně gettery a settery nesplňují. Ve speciálních případech to splňovat mohou.

[Reklama]

[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ě?

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.

pokud je to špatně, tak metody můžou vracet jenom "nic", konstantu nebo náhodné číslo

Návratová hodnota metody by měla souviset s modelovanou realitou, nikoliv s implementací toho modelování, a to obecně gettery a settery nesplňují. Ve speciálních případech to splňovat mohou.

fajn, začínáte to chápat

[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

Viem si taku  vec predstavit. Zavola sa konstruktor objektu, ten sa vytvori, len ak vsetky argumenty maju spravne parametre. Ak nemaju, tak konstruktor vyhodi vynimku.
Kazda metoda toho objektu vrati novy immutable objekt, ktory je kopiou povodneho, len so zmenenymi vlastnostami, ktore ma dana metoda menit.  Ak by hrozilo, ze vznikne nevalidny objekt, metoda by vyhodila vynimku.

uetoyo ale psal o omezení, které objekt nezná, "kontextu"

[Ivan Nový]

Java není tak blbá, ale absence properties má nutit k více objektovému myšlení, kdy objekty mezi sebou komunikují jen a výhradně pomocí zpráv.

Getter/setter jako degenerovaná zpráva (protože je ve své podstatě servisní, souvisí s objeketem, nikoliv s tím, co objekt modeluje) je pak pronikání procedurálního přístupu do OOP.

Hodně častý je prostě jednoduchý objekt Person {name: String, surname: String}. Na tom toho moc nevymyslíš.

K čemu takový objekt potřebujete? To není OOP přístup, ale procedurální. Pochopil bych objekt Point(x,y) s metodami move, rotate, colorize, increase, decrease, hide. Ale jakou činnost chcete provádět se jménem? V realitě jedině print.

[balki]

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

Viem si taku  vec predstavit. Zavola sa konstruktor objektu, ten sa vytvori, len ak vsetky argumenty maju spravne parametre. Ak nemaju, tak konstruktor vyhodi vynimku.
Kazda metoda toho objektu vrati novy immutable objekt, ktory je kopiou povodneho, len so zmenenymi vlastnostami, ktore ma dana metoda menit.  Ak by hrozilo, ze vznikne nevalidny objekt, metoda by vyhodila vynimku.

uetoyo ale psal o omezení, které objekt nezná, "kontextu"

Vzdy je nieco validne v kontexte.  Niekde bol spomenuty string, ale ten je validny, ked splna parametre pre string. Ked sa stane fieldom (atributom) objektu, tak si to skontroluje objekt, ci sa mu tam necpu blbosti. Pripadne, ked sa pouzije ako argument metody.

Priklady z realneho zivota nemusim uvadzat. Baba moze byt aj pekna aj skareda, zalezi kto ju posudzuje.

[Ivan Nový]

fajn, začínáte to chápat

Když si prohlídnete objektové návrhové vzory, gettery a settery se v nich většinou nevyskytují, přesto že implementují relativně složité chování.

[balki]

fajn, začínáte to chápat

Když si prohlídnete objektové návrhové vzory, gettery a settery se v nich většinou nevyskytují, přesto že implementují relativně složité chování.

Gamma and spol - "Design Patterns: Elements of Reusable Object-Oriented Software"
Priklad na vzor observer:

 

Kód: [Vybrat]

#include <iostream>
#include <vector>
#include <time.h>
#include <sys/types.h>
#include <sys/timeb.h>
#include <string.h>

using namespace std ;

class Subject;

class Observer
{
public:
 Observer() {};
 ~Observer() {};
 virtual void Update(Subject* theChangeSubject) = 0;
};

class Subject
{
public:
 Subject() {};
 virtual ~Subject() {};
 virtual void Attach(Observer*);
 virtual void Detach(Observer*);
 virtual void Notify(); 
private:
 vector<Observer*> _observers;
};

void Subject::Attach (Observer* o)
{
 _observers.push_back(o);
}

void Subject::Detach (Observer* o)
{
 int count = _observers.size();
 int i;

 for (i = 0; i < count; i++) {
   if(_observers[i] == o)
   break;
 }
 if(i < count)
  _observers.erase(_observers.begin() + i);

}

void Subject::Notify ()
{
 int count = _observers.size();

 for (int i = 0; i < count; i++)
   (_observers[i])->Update(this);
}

class ClockTimer : public Subject
{
public:
 ClockTimer() { _strtime( tmpbuf ); };
 int GetHour();
 int GetMinute();
 int GetSecond();
 void Tick();   
private:
 char tmpbuf[128];
};

 /* Set time zone from TZ environment variable. If TZ is not set,
  * the operating system is queried to obtain the default value
  * for the variable.
 */
void ClockTimer::Tick()
{
    _tzset();

// Obtain operating system-style time.
    _strtime( tmpbuf );
    Notify();
}

int ClockTimer::GetHour()
{
 char timebuf[128];
 strncpy(timebuf, tmpbuf, 2);
 timebuf[2] = NULL;
 
 return atoi(timebuf);
}

int ClockTimer::GetMinute()
{
 char timebuf[128];
 strncpy(timebuf, tmpbuf+3, 2);
 timebuf[2] = NULL;

 return atoi(timebuf);
}

int ClockTimer::GetSecond()
{
 char timebuf[128];
 strncpy(timebuf, tmpbuf+6, 2);
 timebuf[2] = NULL;

 return atoi(timebuf);
}


class DigitalClock: public Observer
{
public:
 DigitalClock(ClockTimer *); 
 ~DigitalClock();   
  void Update(Subject *);   
  void Draw();     
private:
 ClockTimer *_subject; 
};

DigitalClock::DigitalClock (ClockTimer *s)
{
 _subject = s;
 _subject->Attach(this);
}

DigitalClock::~DigitalClock ()
{
 _subject->Detach(this);
}

void DigitalClock::Update (Subject *theChangedSubject)
{
 if(theChangedSubject == _subject)
  Draw();
}

void DigitalClock::Draw ()
{
 int hour = _subject->GetHour();
 int minute = _subject->GetMinute();
 int second = _subject->GetSecond();

 cout << "Digital time is " << hour << ":"
          << minute << ":"
          << second << endl;           
}

class AnalogClock: public Observer
{
public:
 AnalogClock(ClockTimer *); 
 ~AnalogClock();   
  void Update(Subject *); 
  void Draw();     
private:
 ClockTimer *_subject;   
};

AnalogClock::AnalogClock (ClockTimer *s)
{
 _subject = s;
 _subject->Attach(this);
}

AnalogClock::~AnalogClock ()
{
 _subject->Detach(this);
}

void AnalogClock::Update (Subject *theChangedSubject)
{
 if(theChangedSubject == _subject)
  Draw();
}

void AnalogClock::Draw ()
{
 int hour = _subject->GetHour();
 int minute = _subject->GetMinute();
 int second = _subject->GetSecond();

 cout << "Analog time is " << hour << ":"
         << minute << ":"
         << second << endl;
}

int main(void)
{
 ClockTimer timer;

 DigitalClock digitalClock(&timer;);
 AnalogClock analogClock(&timer;);
 
 timer.Tick(); 
 
 return 0;
}


Upriamujem pozornost na tento kus kodu:

Kód: [Vybrat]

class ClockTimer : public Subject
{
public:
 ClockTimer() { _strtime( tmpbuf ); };
 int GetHour();
 int GetMinute();
 int GetSecond();
 void Tick();   
private:
 char tmpbuf[128];
};

Podobne je na tom mediator. To su dva vzory, ktore si pamatam, ze su tam getre. Lebo z podstaty musia byt. Cele je to prave o zistovani vnutorneho stavu objektu, co by sa podla tunajsich diskuterov nemalo robit. Takze akekolvek obicyklovanie getrov by bolo len zistovanie vnutorneho stavu aj tak.

Mozno, ked si prezriem ine vzory, nedopadnu lepsie. Taky builder je o setroch, len v bledoruzovom.

[balki]

Inb4 vzory su cargokult, som zvedavy, kto to napise

[Mirek Prýmek]

Hodně častý je prostě jednoduchý objekt Person {name: String, surname: String}. Na tom toho moc nevymyslíš.

To je náhodou velmi dobrý příklad! Předávat ven stav objektu by bylo zlo. Správně se objekt má umět sám prezentovat. Takže by měl mít třeba metodu asHtml, asCsv apod. No ale protože v OOP děláme vše univerzálně a znovupoužitelně, tyhle metody implementovat nebudeme a místo toho uděláme obecnou metodu formattedWith(formatter). Ovšem formater taky dovnitř objektu šahat nesmí. Proto je potřeba mu předat abstraktní reprezentaci objektu - strom, kde každý uzel implementuje rozhraní IFormattable. Zároveň ale tuto abstraktní reprezentaci použijeme pro serializaci! A nejenom pro serializaci, ale COKOLI! Takže abysme zajistili, že všechny uzly budou dědit z naší třídy, která vše potřebné obsahuje, použijeme pattern Factory. Čili máme singleton AbstractObjectFormattableRepresentationFactory pomocí kterého potom uzel reprezentace vytvoříme velice snadno:

Kód: [Vybrat]

AbstractObjectFormattableRepresentationFactory.makeAsbstractFormattableRepresenstationNode(string)
- pochopitelně metoda je přetížená pro všechny typy, které by mohly připadat v úvahu a volá se **uvnitř objektu**.

Ovšem nesmíme zapomenout na eventualitu, že daná část stavu objektu není v daném formátu reprezentovatelná. K tomu slouží validátor IAbstractObjectFormattableRepresentationValidator.isFormattableAs, kterému se formát předává jako objekt (nějaké stringové konstanty a podobné prasárny v OOP nevedeme!). Příslušný objekt je pochopitelně opět singleton, čili k němu máme factory, to snad není potřeba zdůrazňovat.

No nic, abych to neprotahoval - chceme-li správně objektově implementovat výpis jména do HTML, budeme potřebovat tak dvacet až stošedesáttři tříd. Shoda na tom ale nepanuje. Někteří programátoři např. tvrdí, že IAbstractObjectFormattableRepresentationValidator je nepřístojné jméno rozhraní, protože neobsahuje písmeno Z.

[Ivan Nový]

Hodně častý je prostě jednoduchý objekt Person {name: String, surname: String}. Na tom toho moc nevymyslíš.

To je náhodou velmi dobrý příklad! Předávat ven stav objektu by bylo zlo. Správně se objekt má umět sám prezentovat. Takže by měl mít třeba metodu asHtml, asCsv apod. No ale protože v OOP děláme vše univerzálně a znovupoužitelně, tyhle metody implementovat nebudeme a místo toho uděláme obecnou metodu formattedWith(formatter). Ovšem formater taky dovnitř objektu šahat nesmí. Proto je potřeba mu předat abstraktní reprezentaci objektu - strom, kde každý uzel implementuje rozhraní IFormattable. Zároveň ale tuto abstraktní reprezentaci použijeme pro serializaci! A nejenom pro serializaci, ale COKOLI! Takže abysme zajistili, že všechny uzly budou dědit z naší třídy, která vše potřebné obsahuje, použijeme pattern Factory. Čili máme singleton AbstractObjectFormattableRepresentationFactory pomocí kterého potom uzel reprezentace vytvoříme velice snadno:

Kód: [Vybrat]

AbstractObjectFormattableRepresentationFactory.makeAsbstractFormattableRepresenstationNode(string)
- pochopitelně metoda je přetížená pro všechny typy, které by mohly připadat v úvahu a volá se **uvnitř objektu**.

Ovšem nesmíme zapomenout na eventualitu, že daná část stavu objektu není v daném formátu reprezentovatelná. K tomu slouží validátor IAbstractObjectFormattableRepresentationValidator.isFormattableAs, kterému se formát předává jako objekt (nějaké stringové konstanty a podobné prasárny v OOP nevedeme!). Příslušný objekt je pochopitelně opět singleton, čili k němu máme factory, to snad není potřeba zdůrazňovat.

No nic, abych to neprotahoval - chceme-li správně objektově implementovat výpis jména do HTML, budeme potřebovat tak dvacet až stošedesáttři tříd. Shoda na tom ale nepanuje. Někteří programátoři např. tvrdí, že IAbstractObjectFormattableRepresentationValidator je nepřístojné jméno rozhraní, protože neobsahuje písmeno Z.

Tak ono stačí místo Person, to pojmenovat PersonStruct a je to vyřešeno. Hned bude patrné, že nejde o objekt ale o strukturu implementovanou objektem. Mimochodem, chybu máte hned na začátku, formattedWith není objektově, je to ten samý případ jako settery/gettery, taky nepřímo zveřejňuje vnitřní stav. asHtml je ok, kdy objekt HtmlFormatter se do objektu injektuje. Fakticky tedy počet objektů zůstává ve vazbě 1:1 na reálnou činnost, v tomto případě daný typ formátování. Znovupoužitelnost není definována přes metody, jako v procedurálním programování, ale přes objekty, tedy v našem případě přes HtmlFormatter. V celé aplikaci pak pro implementaci html formátování vystačíte s jednou třídou, která implementuje metodu asHTML.

[podlesh]

Inb4 vzory su cargokult, som zvedavy, kto to napise

Vzory jsou to cargo z cargocultu.