Čada: Objektové programování

[Mr. Pointless]

Thinking in C++ 2nd Edition by Bruce Eckel

Free Electronic Book
Volume 1 & Volume 2

http://mindview.net/Books/TICPP/ThinkingInCPP2e.html

[Reklama]

[SB]

Tak ono už jenom zapouzdření znamená mimořádný nárůst izolace částí modelu. Dá se využít někde mimo objektový model?

Třeba tak nějak úplně všude? Nesetkal jsem se s jazykem, ve kterém by se nedaly detaily schovat za nějaké rozhraní.

Rozhraní má i objekt. Rozhraní čeho máte na mysli? Jak je realizována zvenku nepřístupná doména? Knihovnou? Nějak jinak?

[SB]

Jestli chcete donekonečna obhajovat hledání metod podle názvu za běhu, tak s Váma končím, tato myšlenka je zcela pomýlená. Na odůvodněné případy stačí reflexe.

,,Reflexi" hybridních jazyků jsme už probrali. Takže jsme už probrali asi všechno, nemusíme dál pokračovat.

[Kit]

Pozor, mezi ZÁKLADNÍ vlastnosti určitě patří i to zapouzdření, je to nutným požadavkem pro zajištění konzistence stavů a zabránění objektovým orgiím.

Kéž by vývojáři takové zapouzdření dělali. Místo toho tam nacpou hromady getterů a setterů...

[l]

Kéž by vývojáři takové zapouzdření dělali. Místo toho tam nacpou hromady getterů a setterů...

Getter a Setter je zapouzdření. G/S jsou normální metody jako každé jiné a můžeš si tam napsat cokoliv jako do každé jiné metody. Není pravda že Setter je povinně this->m_variable=new_value Pokud si to takhle myslíš, žiješ v hlubokém omylu. Je pravda, že spousta programátorů v tomto hlubokém omylu žije.

[Reklama]

[Kit]

Kéž by vývojáři takové zapouzdření dělali. Místo toho tam nacpou hromady getterů a setterů...

Getter a Setter je zapouzdření. G/S jsou normální metody jako každé jiné a můžeš si tam napsat cokoliv jako do každé jiné metody. Není pravda že Setter je povinně this->m_variable=new_value Pokud si to takhle myslíš, žiješ v hlubokém omylu. Je pravda, že spousta programátorů v tomto hlubokém omylu žije.

Právěže v tom omylu nežiji a pokud sis všiml, tak mám proti těmto nešvarům dost vyhraněný postoj. Osobně zapouzdřuji bez getterů a setterů. Nepotřebuji je, protože práci s objektem implementuji uvnitř objektu a případné závislosti injektuji.

[hawran diskuse]

Kdo používá (g/s)etry je zrádce rasy a bude exkomunikován.

[l]

Postoj můžeš mít jaký chceš, G/S jsou zapouzdření.

Pro změnu objektu buď zavoláš nějakou metodu a je jedno jestli je si ji pojmenuješ SetX nebo MoveHorizontal, nebo přestoupíš na víru immutable a při jakékoliv změně vytvoříš objekt nový a nové vlastnosti nastavíš v konstruktoru. Jiné možnosti moc nejsou.

[Ondra Satai Nekola]

Tak, tak. G/S jsou zapouzdreni. Leckdy to neni dobry navrh, ale nikde neni psano, ze zapouzdreni + polymorfismus samo o sobe k dobremu navrhu staci...

[JSH]

Tak ono už jenom zapouzdření znamená mimořádný nárůst izolace částí modelu. Dá se využít někde mimo objektový model?

Třeba tak nějak úplně všude? Nesetkal jsem se s jazykem, ve kterém by se nedaly detaily schovat za nějaké rozhraní.

Rozhraní má i objekt. Rozhraní čeho máte na mysli? Jak je realizována zvenku nepřístupná doména? Knihovnou? Nějak jinak?

Sorry, nechápu dotaz. Ten původní jsem pochopil jako "Dá se zapouzdření využít někde mimo objektový model?" Vzhledem k tomu, že zapouzdření není nic jiného než skrytí nepodstatných detailů, tak se využívá v čistých i nečistých, objektových i neobjektových jazycích.
A na mysli mám rozhraní čehokoliv.

[rootacek]

Jsem rád, že tady jsou lidi s tímto názorem.Nejlepší je, že spoléhajíci na OOP, ale bez procedurálu či paradigmat by to neexistovalo...
Ja bych řekl, že oop, je líné programování.A o dost jednodušší a v podstatě z programátora se stává ovce, která vlastně programovat neumí umí jen

Kód [Vybrat] Rozbalit

$this->result(); např možná .

Přibližte mi, co je na Smalltalku procedurálního, to mě hodně zajímá...
Jaká paradigmata máte na mysli?
OOP je v první řadě systém organizace modelu a jeho výpočtu, který má zjednodušit vedení velkých projektů. To samo o sobě neznamená, že by vývojář nemusel přemýšlet. Důkazem je mi právě ona praxe, kdy drtivá většina vývojářů není schopna vytvořit objektový model dané domény. Takže ono to pro úplné blbce asi nebude, spíš se potkávám s těmi nasranými, že jim to nejde.

Myslel jsem to v obecné rovině. Ne ve Smalltalku. Neříkám, pro blbce, ale asi logicky, je něco jiného programovat v nižším jazyce, než ve vyšším.Kde mám většinu nízkoúrovňových věcí hotovou. A hezky si dělám ten svůj estetický přehledný kód se syntaktickým cukrem.

[SB]

Tak ono už jenom zapouzdření znamená mimořádný nárůst izolace částí modelu. Dá se využít někde mimo objektový model?

Třeba tak nějak úplně všude? Nesetkal jsem se s jazykem, ve kterém by se nedaly detaily schovat za nějaké rozhraní.

Rozhraní má i objekt. Rozhraní čeho máte na mysli? Jak je realizována zvenku nepřístupná doména? Knihovnou? Nějak jinak?

Sorry, nechápu dotaz. Ten původní jsem pochopil jako "Dá se zapouzdření využít někde mimo objektový model?" Vzhledem k tomu, že zapouzdření není nic jiného než skrytí nepodstatných detailů, tak se využívá v čistých i nečistých, objektových i neobjektových jazycích.
A na mysli mám rozhraní čehokoliv.

Já zase nechápu odpověď. Rozhraní je jen předpis funkcionality systému, který popisuje, kterou funkcionalitu systém určitě implementuje, ale neznamená, že neimplementuje nic dalšího, takže nijak neomezuje využití jeho dalších funkcionalit, např. přes další rozhraní či např. objektově posláním zprávy (u hybridních jazyků třeba před ,,posláním" (čti voláním) přetřídovat (čti přetypovat)). Takže rozhraní mechanismem zapouzdření není.
Uveďte jiný příklad implementace zapouzdření.

[SB]

Jsem rád, že tady jsou lidi s tímto názorem.Nejlepší je, že spoléhajíci na OOP, ale bez procedurálu či paradigmat by to neexistovalo...
Ja bych řekl, že oop, je líné programování.A o dost jednodušší a v podstatě z programátora se stává ovce, která vlastně programovat neumí umí jen

Kód [Vybrat] Rozbalit

$this->result(); např možná .

Přibližte mi, co je na Smalltalku procedurálního, to mě hodně zajímá...
Jaká paradigmata máte na mysli?
OOP je v první řadě systém organizace modelu a jeho výpočtu, který má zjednodušit vedení velkých projektů. To samo o sobě neznamená, že by vývojář nemusel přemýšlet. Důkazem je mi právě ona praxe, kdy drtivá většina vývojářů není schopna vytvořit objektový model dané domény. Takže ono to pro úplné blbce asi nebude, spíš se potkávám s těmi nasranými, že jim to nejde.

Myslel jsem to v obecné rovině. Ne ve Smalltalku. Neříkám, pro blbce, ale asi logicky, je něco jiného programovat v nižším jazyce, než ve vyšším.Kde mám většinu nízkoúrovňových věcí hotovou. A hezky si dělám ten svůj estetický přehledný kód se syntaktickým cukrem.

Smalltalk jsem uvedl schválně jako jazyk, který se docela dobře obešel bez imperativního paradigmatu.
Vysokoúrovňové programování je o tom, že máte 3 prde_le práce se sestavením modelu a nemáte čas se srát (a pokaždé znovu) s hovadinami, jak projít seznam ap.

[yorik]

kniha OOP, pre uplnych zaciatocnikov:
OOP - Naučte se myslet a programovat objektově, Rudolf Pecinovský

http://knihy.cpress.cz/oop.html

[JSH]

Já zase nechápu odpověď. Rozhraní je jen předpis funkcionality systému, který popisuje, kterou funkcionalitu systém určitě implementuje, ale neznamená, že neimplementuje nic dalšího, takže nijak neomezuje využití jeho dalších funkcionalit, např. přes další rozhraní či např. objektově posláním zprávy (u hybridních jazyků třeba před ,,posláním" (čti voláním) přetřídovat (čti přetypovat)). Takže rozhraní mechanismem zapouzdření není.
Uveďte jiný příklad implementace zapouzdření.

Rozhraní taky není mechanismus zapouzdření. Rozhraní je popis toho, co je přes zapouzdření vidět.

Příklad zapouzdření by bylo třeba několik exportovaných funkcí a data schovaná za nějaký abstraktní handle (void ptr, int). Tady to zapouzdření nedělají objekty, ale moduly.