it-swarm-eu.dev

Je OOP těžké), protože to není přirozené?

Často je slyšet, že OOP přirozeně odpovídá způsobu, jakým lidé myslí na svět. Ale s tímto tvrzením silně nesouhlasím: My (nebo alespoň já) pojmeme svět z hlediska - vztahy mezi věcmi, se kterými se setkáváme, ale zaměření OOP) je navrhování jednotlivých tříd a jejich hierarchií.

Všimněte si, že v každodenním životě existují vztahy a akce většinou mezi objekty, které by byly případy nesouvisejících tříd v OOP. Příklady takových vztahů jsou: "moje obrazovka je nahoře na stole"; "Já (člověk) sedím na židli"; „auto je na cestě“; "Píšu na klávesnici"; „kávovar vaří vodu“, „text se zobrazí v okně terminálu.“

Myslíme na termíny bivalentní (někdy trojmocné, jako například v slově „Dal jsem vám květiny“), kde sloveso je akce (vztah), která působí na dva objekty a vytváří nějaký výsledek/akci. focus je v akci a dva (nebo tři) [gramatické] objekty mají stejnou důležitost.

Kontrast, že s OOP, kde musíte nejprve najít jeden objekt (podstatné jméno) a řekněte mu, aby provedl nějakou akci na jiném objektu. Způsob myšlení se přesouvá z akcí/sloves, která působí na podstatná jména pracující na podstatných jménech - jako by bylo vše řečeno pasivním nebo reflexivním hlasem, např. „text je zobrazen terminálovým oknem“. Nebo „text se na terminálový okénko kreslí“.

Nejenže je fokus přesunutý na podstatná jména, ale i jedno z podstatných jmen (řekněme to gramatický předmět) má vyšší „důležitost“ než ostatní (gramatický objekt). Je tedy třeba se rozhodnout, zda někdo řekne terminalWindow.show (someText) nebo someText.show (terminalWindow). Ale proč zatěžovat lidi takovými triviálními rozhodnutími bez provozních důsledků, když někdo skutečně znamená show (terminalWindow, someText)? [Důsledky jsou operativně nevýznamné - v obou případech je text zobrazen na terminálovém okně - ale může být velmi závažný při navrhování hierarchií tříd a „nesprávná“ volba může vést ke spletitým a tvrdým udržovat kód.]

Proto bych tvrdil, že mainstreamový způsob dělání OOP (třídní, single-expedice) je obtížný, protože IS UNNATURAL a neodpovídá tomu, jak lidé přemýšlejí o světě Obecné metody z CLOSu jsou blíže mému způsobu myšlení, ale bohužel to není rozšířený přístup.

Jak/vzhledem k těmto problémům, jak/proč se stalo, že současný běžný způsob dělání OOP se stal tak populárním?

86
zvrba

OOP je pro některé problémy nepřirozený. Takže je procedurální. Je funkční. Myslím, že OOP má dva problémy, které to opravdu zdají těžké).

  1. Někteří lidé se chovají, jako by to byl jeden opravdový způsob programování, a všechna ostatní paradigmata jsou špatná. Každý, kdo má IMHO, by měl používat multiparadigmový jazyk a vybrat si nejlepší paradigma pro subproblem, na kterém v současné době pracují. Některé části vašeho kódu budou mít styl OO==================================================================================================

    a. OO je obecně nejlepší, když máte chování, které je silně spjato se stavem, ve kterém pracují, a přesná povaha státu je detail implementace, ale jeho existenci nelze snadno abstrahovat Příklad: Kolekce tříd.

    b. Procedurální je nejlepší, když máte spoustu chování, které nejsou pevně spojeny s žádnými konkrétními daty. Například možná pracují na primitivních typech dat. Nejjednodušší je zde považovat chování a data za samostatné entity. Příklad: Numerický kód.

    c. Funkční je nejlepší, když máte něco, co je poměrně snadné napsat deklarativně tak, že existence jakéhokoli státu je implementačním detailem, který lze snadno abstrahovat. Příklad: Mapa/Snížit paralelismus.

  2. OOP obecně ukazuje jeho užitečnost na velkých projektech, kde je nutné mít dobře zapouzdřené kousky kódu. To se příliš nestane u začátečníků.

97
dsimcha

IMHO je to otázka osobního vkusu a způsobů myšlení. Nemám s OO moc problém.

My (nebo alespoň já) pojímáme svět z hlediska vztahů mezi věcmi, se kterými se setkáváme, ale fokus OOP) je navrhování jednotlivých tříd a jejich hierarchií.

IMHO to tak docela není, ačkoli to může být běžné vnímání. Alan Kay, vynálezce termínu OO, vždy zdůrazňoval spíše zprávy odesílané mezi objekty, než samotné objekty. A zprávy přinejmenším pro mě znamenají vztahy.

Všimněte si, že v každodenním životě existují vztahy a akce většinou mezi objekty, které by byly případy nesouvisejících tříd v OOP.

Pokud existuje vztah mezi objekty, pak se vztahují podle definice. V OO) byste to mohli vyjádřit pomocí závislosti mezi asociacemi/agregací/používáním mezi dvěma třídami.

Myslíme na termíny bivalentní (někdy trojmocné, jako například v slově „Dal jsem vám květiny“), kde sloveso je akce (vztah), která působí na dva objekty a vytváří nějaký výsledek/akci. Důraz je kladen na akci a dva (nebo tři) [gramatické] objekty mají stejnou důležitost.

Stále však mají své dobře definované role v kontextu: předmět, předmět, akce atd. „Dal jsem vám květiny“ nebo „dal jsi mi květiny“ nejsou stejné (nemluvě o „květině mi dal“): -)

Kontrast, že s OOP, kde musíte nejprve najít jeden objekt (podstatné jméno) a řekněte mu, aby provedl nějakou akci na jiném objektu. Způsob myšlení se přesouvá z akcí/sloves, která působí na podstatná jména pracující na podstatných jménech - jako by bylo vše řečeno pasivním nebo reflexivním hlasem, např. „text je zobrazen terminálovým oknem“. Nebo „text se na terminálový okénko kreslí“.

S tím nesouhlasím. IMHO anglická věta "Bill, jdi do pekla" čte přirozeněji v programovém kódu jako bill.moveTo(hell) spíše než move(bill, hell). A první je ve skutečnosti více analogický původnímu aktivnímu hlasu.

Je tedy třeba se rozhodnout, zda někdo řekne terminalWindow.show (someText) nebo someText.show (terminalWindow)

Opět není to stejné, požádat terminál, aby ukázal nějaký text, nebo požádat text, aby ukázal terminál. IMHO je docela zřejmé, který z nich je přirozenější.

Jak/vzhledem k těmto problémům, jak/proč se stalo, že současný tradiční způsob dělání OOP se stal tak populárním?

Možná proto, že většina OO vývojářů vidí OO jinak než vy?)

48
Péter Török

Někteří programátoři považují OOD za těžké, protože tito programátoři rádi přemýšlejí o tom, jak vyřešit problém s počítačem, ne o tom, jak by měl být problém vyřešen.

... ale fokus OOP) je navrhování jednotlivých tříd a jejich hierarchií.

OOD NENÍ o tom. OOD pojednává o tom, jak se věci chovají a jak interagují.

Myslíme na termíny bivalentní (někdy trojmocné, jako například v slově „Dal jsem vám květiny“), kde sloveso je akce (vztah), která působí na dva objekty a vytváří nějaký výsledek/akci. Důraz je kladen na akci a dva (nebo tři) [gramatické] objekty mají stejnou důležitost.

Zaměření na OOD je vždy na akci, kde akce jsou chování objektů. Objekty nejsou nic bez jejich chování. Jediným objektovým omezením OOD je, že všechno musí něco udělat.

Nevidím toho doera jako důležitějšího než věc, která s tím něco udělala.

Ale proč zatěžovat lidi takovými triviálními rozhodnutími bez provozních důsledků, když někdo skutečně znamená show (terminalWindow, someText)?

Pro mě je to totéž s jiným zápisem. Stále se musíte rozhodnout, kdo je show-er a kdo je show-ee. Jakmile to víte, pak v OOD neexistuje žádné rozhodnutí. Windows ukazují text -> Window.Show (text).

Mnoho věcí tam (zejména ve staré oblasti) říká, že je OO, když tomu tak není). Například existuje obrovské množství kódu C++, které neimplementuje fík OOD.

OOD je snadné, jakmile vypuknete z myšlení, že řešíte problém s počítači. Řešíte problémy u věcí, které dělají věci.

10
Matt Ellen

Možná nejsem schopen pochopit, ale:

Četl jsem první knihu o OOP (začátkem 90. let, tenký manuál Borlanda k Pascalovi), byl jsem prostě ohromen jeho jednoduchostí a potenciálem (Předtím jsem používal Cobol, Fortran, Assembly Assembly a další prehistorické věci.)

Pro mě je to docela jasné: pes je zvíře, zvíře musí jíst, můj pes je pes, takže musí jíst ...

Na druhé straně samotné programování je ze své podstaty nepřirozené (tj. Umělé). Lidská řeč je umělá (neobviňuj mě, všichni jsme se naučili naše jazyky od ostatních, nikdo nezná osobu, která vynalezla angličtinu). Podle některých vědců je lidská mysl tvořena jazykem, který se naučil jako první.

Přiznávám, že některé konstrukty v moderních OO jazycích jsou trochu trapné, ale je to vývoj.

7
Nerevar

Jedna věc, která mi znesnadňovala, byla myšlenka, že OOP se týkalo modelování světa. Myslel jsem si, že pokud se mi to nepodaří, mohlo by něco přijít a kousnout mě do zadku (a věc je buď pravdivá, nebo ne.) Byl jsem si velmi dobře vědom problémů, které předstírají, že vše je objektem nebo entitou, což mě velmi předběžné a nedůvěřovalo programování v OOP.

Pak jsem si přečetl SICP a dospěl jsem k novému porozumění, že to opravdu bylo o typech dat a řízení přístupu k nim. Všechny problémy, které jsem rozplynul, protože byly založeny na falešném předpokladu, že v OOP vy modelujete svět).

Stále se divím nesmírným obtížím, které mi tento falešný předpoklad dal (a jak jsem se k tomu nechal slyšet).

6
Pinochle

My (nebo alespoň já) pojímáme svět z hlediska vztahů mezi věcmi, se kterými se setkáváme, ale fokus OOP) je navrhování jednotlivých tříd a jejich hierarchií.

Začínáte od (IMO) falešného předpokladu. Vztahy mezi objekty jsou patrně důležitější než samotné objekty. Jsou to vztahy, které dávají objektově orientovanou strukturu programu. Dědičnost, vztah mezi třídami, je samozřejmě důležitá, protože třída objektu určuje, co daný objekt může dělat. Ale to jsou vztahy mezi jednotlivými objekty, které určují, co objekt ve skutečnosti dělá v mezích definovaných třídou, a tedy jak se program chová.

Objektově orientované paradigma může být zpočátku obtížné ne proto, že je obtížné vymyslet nové kategorie objektů, ale proto, že je obtížné představit si graf objektů a porozumět tomu, jaké vztahy mezi nimi by měly být, zejména když nemáte způsob, jak tyto vztahy popsat. Proto jsou designové vzory tak užitečné. Designové vzory jsou téměř úplně o vztazích mezi objekty. Vzory nám dávají jak stavební bloky, které můžeme použít k navrhování vztahů mezi objekty na vyšší úrovni, tak jazyk, který můžeme použít k popisu těchto vztahů.

Totéž platí pro kreativní pole, která fungují ve fyzickém světě. Kdokoli mohl hodit dohromady spoustu místností a nazvat to budovou. Místnosti mohou být dokonce plně vybaveny všemi nejnovějšími doplňky, ale to neznamená, že bude budova fungovat. Úkolem architekta je optimalizovat vztahy mezi těmito místnostmi s ohledem na požadavky lidí, kteří tyto pokoje používají, a prostředí budovy. Napravit tyto vztahy je to, co dělá stavbu z funkčního i estetického hlediska.

Pokud máte potíže si zvyknout na OOP, doporučuji vám, abyste se zamysleli nad tím, jak vaše objekty zapadají do sebe a jak jsou uspořádány jejich povinnosti. Pokud jste to ještě nečetli, přečtěte si o vzorcích - pravděpodobně si uvědomíte, že jste už vzory, o kterých jste četli, viděli, ale jejich jména vám umožní vidět nejen stromy, ale také stojany, kopyty, houštiny, lesy, háje, dřevotřísky a případně lesy.

4
Caleb

Ano, OOP samotný je velmi nepřirozený - skutečný svět není zcela vyroben z hierarchických taxonomií. Některé jeho malé části jsou vyrobeny z těchto věcí a tyto části jsou jediné věci, které by mohly být adekvátně vyjádřeno v termínech OO. Všechno ostatní se přirozeně nezapadá do tak triviálního a omezeného způsobu myšlení. Podívejte se na přírodní vědy, podívejte se, kolik různých matematických jazyků bylo vynalezeno za účelem vyjádření v nejjednodušším nebo alespoň srozumitelném tak složitost skutečného světa. A téměř žádný z nich nemůže být snadno přeložen do jazyka objektů a zpráv.

4
SK-logic

UPRAVENO

Nejprve bych chtěl říci, že jsem nikdy nenašel OOP tvrdý nebo těžší než jiné programovací paradigmata.) Programování je ze své podstaty obtížné, protože se snaží řešit problémy ze skutečného světa a skutečný svět je Na druhé straně, když jsem četl tuto otázku, zeptal jsem se: Je OOP "přirozenější" než jiná paradigma? A proto účinnější?

Jednou jsem našel článek (přál bych si, abych ho našel znovu, abych ho mohl poslat jako referenci) o srovnávací studii mezi imperativním programováním (IP) a objektově orientovaným programováním (OOP). V zásadě změřili produktivitu profesionálních programátorů pomocí IP a OOP v různých projektech) a výsledkem bylo, že neviděli velké rozdíly. produktivitu mezi oběma skupinami a to, co se skutečně počítá, jsou zkušenosti.

Na druhé straně zastánci objektové orientace tvrdí, že zatímco během raného vývoje systému OOP může trvat i déle, než je nezbytně nutné), z dlouhodobého hlediska je kód snadnější udržovat a rozšířit kvůli těsné integraci mezi daty a operacemi.

Pracoval jsem hlavně s OOP jazyky (C++, Java)), ale často mám pocit, že bych mohl být stejně produktivní pomocí Pascalu nebo Ady, i když jsem je nikdy nezkoušel pro velké projekty.

Kontrast, že s OOP), kde musíte nejprve najít jeden objekt (podstatné jméno), a řekněte mu, aby provedl nějakou akci na jiném objektu.

[řez]

Proto bych tvrdil, že mainstreamový způsob dělání OOP (třídní, single-expedice) je obtížný, protože IS UNNATURAL a neodpovídá tomu, jak lidé přemýšlejí o světě Obecné metody z CLOSu jsou blíže mému způsobu myšlení, ale bohužel to není rozšířený přístup.

Když jsem tento poslední odstavec pozorně četl, konečně jsem pochopil hlavní bod vaší otázky a musel jsem svou odpověď přepsat od nuly. :-)

Vím o jiných OO návrzích, kde více objektů dostává zprávu místo pouze jednoho, tj. Několik objektů hraje při přijetí zprávy symetrickou roli. ANO, zdá se to obecnější a možná přirozenější ( méně restriktivní) OOP přístup ke mně.

Na druhou stranu lze „vícenásobné odeslání“ snadno simulovat pomocí „jediného odeslání“ a „jediné odeslání“ se snadněji implementuje. Možná je to jeden z důvodů, proč se „hromadné odesílání“ nestalo mainstreamem.

3
Giorgio

OOP není těžké. To, co je obtížné používat dobře, je mělké pochopení toho, pro co je dobré, kde programátoři slyší náhodné maxima a opakují je sami sobě pod dechem, aby obdrželi požehnání božského gangu čtyř, blahoslaveného Martina Fowlera, nebo kdokoli jiný, co četli.

3
Marcin

To je jen část toho, co je s OOP špatně.

Funkce se v podstatě stávají občany druhé třídy, a to je špatné.

Moderní jazyky (Ruby/python) tento problém netrpí a poskytují funkce jako prvotřídní objekty a umožňují vám vytvářet programy bez vytváření hierarchie tříd.

3
hasen

Přestaňte hledat výhradně paradigma OOP) a zkuste použít nějaký JavaScript.

Momentálně mám vypracované schéma, kde moje UI objekty fungují pod rozhraním řízeným událostmi. To znamená, že budu mít to, co vypadá jako typická veřejná metoda, která při vystřelení vyústí v interně definovanou akci. Když je ale spuštěna, skutečně se stane, že spustím událost na samotném objektu a předdefinovaný obslužný program uvnitř objektu odpoví. Tuto událost a objekt události, ke kterému můžete připojit vlastnosti, které jsou předány jinému posluchači, může slyšet cokoli, co se stará o poslech. Můžete poslouchat přímo na objekt nebo můžete poslouchat obecně pro tento typ události (události jsou také spouštěny na obecném objektu, který mohou poslouchat všechny objekty vytvořené v továrně). Například nyní mám rozbalovací seznam, ve kterém si z rozevíracího seznamu vyberete novou položku. ComboBox ví, co dělat, aby nastavil svou vlastní zobrazovanou hodnotu a v případě potřeby aktualizoval server, ale mohu mít také tolik dalších rozbalovacích polí, kolik chci poslouchat, abych vyměnil jejich vybrané seznamy, které jsou vázány na aktuální hodnotu první pole se seznamem.

Pokud chcete, (a byl jsem překvapen, když jsem zjistil, že obvykle nechci - je to problém čitelnosti, když nevidíte, odkud událost pochází), můžete mít úplné oddělení objektů a navázat kontext prostřednictvím předaného objektu události. Bez ohledu na to se stále vyhýbáte jednorázovému odeslání tím, že můžete zaregistrovat více respondentů.

Ale nedělám to s OOP osamoceně a JS není ani 'správně' OOP) některými definicemi, které mi připadají veselé. vyšší úroveň vývoje aplikací podle mého názoru, má moc ohýbat paradigma na cokoli, co funguje pro vaši situaci, a můžeme emulovat třídy v pohodě, pokud nám to záleží. Ale v tomto případě jsem smíchání aspektů funkčních kolem) s OOP.

A co je důležitější, co se cítím docela mocně. Nemyslím na to, že jeden objekt působí na jiný. V zásadě rozhoduji o tom, o co se objekty zajímají, poskytuji jim nástroje, které potřebují k vyřešení věcí, a prostě je hodím do směšovače a nechám je na sebe reagovat.

Myslím, že to, co říkám, je toto: nejde o prohlášení o změně typu problému. Je to mix a zápas. Problém je v jazycích a výstřelcích, které chtějí, abyste věřili, že je to jedna věc uber alles. Jak může junior Java dev, například, opravdu ocenit OOP, když si myslí, že to ve výchozím nastavení vždy dělá správně)?

3
Erik Reppen

Myslím, že některé z problémů přicházejí, když se lidé snaží použít OOP k reprezentaci reality. Každý ví) že auto má čtyři kola a motor. Každý ví že auta mohou Start(), Move() a SoundHorn().

Když jsem si uvědomil, že bych se to měl neustále pokoušet, přestalo mi v hlavě světlo. Objekt není věc, se kterou sdílí jméno. Objekt je (tj. By měl být) dostatečně podrobný oddíl dat relevantní pro rozsah problému. ought má přesně to, co řešení problému potřebuje, nic víc a nic méně. Pokud má objekt zodpovědnost za určité chování za následek, že více řádků kódu než stejné chování je úkolem nějaké mlhavé třetí strany (někteří by to mohli nazvat „poltergeist“), získá poltergeist své žetony.

2
Tom W

Způsob, jakým mi to bylo vysvětleno, byl s toustovačem a autem. Oba mají pružiny, takže byste měli objekt „pružiny“ a byly by různé velikosti, síly a cokoli jiného, ​​ale oba by to byly „pružiny“ a poté by metaforu rozšířili na auto, kdybyste měli spoustu kol (Kola, samozřejmě, plus volant, atd.) A to dávalo velký smysl.

Pak si můžete myslet na program jako na seznam objektů a je mnohem jednodušší vizualizovat pak „Je to seznam věcí, které dělají věci, takže to není jako ten seznam pokynů, které jste viděli dříve“

Myslím, že skutečný problém s OOP je to, jak je to vysvětleno lidem.) Často (v mých uni třídách) to vidím vysvětleno slovy „jde o spoustu tříd, které dělají malé věci, a ty může z toho vytvořit objekty “a to vše mate spoustu lidí, protože k vysvětlení těchto konceptů používá v podstatě abstraktní pojmy, spíše než konkrétní myšlenky, které lidé pochopili, když jim bylo pět let, když si hráli s legem.

2
Trezoid

Je to přirozený způsob, jak myslet na svět prostřednictvím kategorizace. To je víceméně to, o čem OO je. OOP je obtížné, protože programování je obtížné).

2

Ne. Existuje několik způsobů, jak vyřešit sondu pomocí programování: funkční, procedurální, logická, O.O.P., další.

Ve skutečném světě lidé někdy používají funkční paradigma a někdy i procedurální paradigma atd. A někdy jsme se smíchali. A nakonec je reprezentujeme jako konkrétní styl nebo paradigma programování.

V LISP se také používá paradigma „všechno je seznam nebo položka“. Ráda bych zmínil něco jiného než funkční programování. PHP to používá v asociativních polích).

O.O.P. a „Všechno je seznam nebo položka“, paradigmata jsou považována za 2 z programovacích stylů MORE NATURAL, jak si pamatuji v některých třídách umělé inteligence.

Zní mi to divně, „O.O.P. není přirozené“, možná způsob, jakým se učíte, nebo způsob, jakým jste se o O.O.P učili. se mýlí, ale ne O.O.P. sám.

1
umlcat

Myslím, že jazyky OOP a OOP jazyky mají také problémy).

Pokud tomu rozumíte správně, OOP je o černých rámečcích (objektech), na kterých jsou tlačítka, která lze tlačit (metody). Třídy jsou právě tam, aby pomohly tyto černé rámečky uspořádat.

Jeden problém je, když programátor umístí tlačítka na nesprávný objekt. Terminál nemůže zobrazit text sám o sobě, text se nemůže zobrazit na terminálu. Komponenta správce oken operačního systému, která to dokáže. Okno a text terminálu je pouze pasivní entita. Ale pokud si myslíme, že tímto způsobem si uvědomíme, že většina entit je pasivních věcí, měli bychom jen velmi málo objektů, které skutečně něco dělají (nebo jednoduše jeden: počítač). Když použijete C a uspořádáte jej do modulů, tyto moduly představují jen několik objektů.

Dalším bodem je, že počítač pouze provádí pokyny postupně. Předpokládejme, že máte objekt VCR a Television, jak byste hráli video? Pravděpodobně píšete něco takového:

connect(television, vcr);
vcr.turnOn();
television.turnOn();
insert(vcr, yourFavoriteCasette);
vcr.play();
while (vcr.isPlaying()) {} // Wait while the VCR is playing the casette.
vcr.eject();
vcr.turnOff();
television.turnOff();

To by bylo jednoduché, ale na to byste potřebovali alespoň 3 procesory (nebo procesy): jeden hraje roli vás, druhý je videorekordér, třetí je televizor. Normálně však máte pouze jedno jádro (alespoň ne dost pro všechny vaše objekty). Na vysoké škole mnoho mých spolužáků nechápalo, proč GUI zamrzne, když tlačítko provede nákladnou operaci.

Takže si myslím, že objektově orientovaný design může popisovat svět docela dobře, ale není to nejlepší abstrakce pro počítač.

1
Calmarius

Abychom zvládli složitost, musíme seskupit funkčnost do modulů, což je obecně obtížný problém. Je to jako staré přísloví o kapitalismu, OOP je nejhorší systém pro organizaci softwaru tam, kromě všeho, co jsme vyzkoušeli).

Důvod, proč seskupujeme interakce uvnitř substantiv, i když je často nejasné, o kterém z těchto dvou substantiv je seskupeno, je to, že množství substantiv se stane cvičením do zvládnutelných tříd třídy, zatímco seskupování podle sloves má sklon buď produkovat velmi malé skupiny jako jednorázové nebo velmi velké skupiny pro funkci jako show. Při seskupování podle substantiv se také mnohem jednodušší vymýšlejí koncepty opětovného použití, jako je dědičnost.

Také otázka rozhodování, zda dát show s oknem nebo textem, je v praxi téměř vždy jasnější než teoreticky. Například téměř všechny skupiny nástrojů grafického uživatelského rozhraní add s kontejnerem, ale show s widgetem. Pokud se pokusíte napsat kód jiným způsobem, důvod se zjeví poměrně rychle, i když o něm abstraktně uvažují, že se tyto dvě metody vzájemně zaměňují.

1
Karl Bielefeldt

Jak/vzhledem k těmto problémům, jak/proč se stalo, že současný běžný způsob dělání OOP se stal tak populárním?

OOP se stal populárním, protože nabízí nástroje k uspořádání vašeho programu na vyšší úrovni abstrakce než populární procedurální jazyky, které mu předcházely. Bylo také relativně snadné vytvořit jazyk, který měl procedurální strukturu uvnitř metod a objektově orientovanou strukturu, která je obklopovala. To umožnilo programátorům, kteří již věděli, jak programovat procedurálně, postupně vyzvedávat OO principy jeden po druhém). To také vedlo ke spoustě OO jmenných programů, které byly procedurální programy zabalené do třídy nebo dva.

Chcete-li vyloučit OO, vytvořte jazyk, který usnadňuje postupný přechod od toho, co většina programátorů dnes ví (většinou procedurální, s trochou OO), k vašemu preferovanému paradigmatu. Ujistěte se, že poskytuje pohodlná rozhraní API pro provádění běžných úkolů a dobře je propagujte. Lidé brzy vytvoří programy ve vašem jazyce pouze pro X-name. Pak můžete očekávat, že to bude trvat roky a roky, než se lidé dostanou dobře na X.

1
Sean McMillan

Podívejte se na DCI (data, kontext a interakce) vynalezené vynálezcem vzoru MVC.

Cílem DCI je (citováno z Wikipedie):

  • Dej chování systému prvotřídnímu stavu, nad objekty (podstatná jména).
  • Čistě oddělit kód pro rychle se měnící chování systému (co systém dělá) od kódu pro pomalu se měnící znalosti domény (co je systém), namísto kombinování obou v rozhraní jedné třídy.
  • Podporovat objektový styl myšlení, který je blízký mentálním modelům lidí, spíše než třídní styl myšlení.

Zde je dobrý článek autorů a tady je malý příklad implementace (.NET) , pokud chcete vidět nějaký kód. Je to mnohem jednodušší, než by to mohlo znít, a je to velmi přirozené.

0
Sire

Člověk často slyší, že OOP přirozeně odpovídá způsobu, jakým si lidé myslí o světě. Ale s tímto tvrzením silně nesouhlasím (...)

Protože je evangelizován v knihách a jinde po celá desetiletí, s tím také nesouhlasím. Přesto si myslím, že Nygaard a Dahl byli takoví, kteří to říkali, a myslím, že se soustředili na to, jak snadnější bylo myslet na navrhování simulací ve srovnání s časovými alternativami.

(...), ale fokus OOP) je navrhování jednotlivých tříd a jejich hierarchií.

Toto tvrzení vstupuje do rozumného teritoria vzhledem k tomu, jak populární mylné představy o OOP jsou a jak citlivé OO je definice). V terénu mám více než deset let jak průmyslová práce, tak akademický výzkum prognostických jazyků, a mohu vám říci, že jsem strávil mnoho let unlearningem „mainstreamového OO“, protože jsem si začal všímat, jak se liší (a méně) od toho, na co se zaměřili starší tvůrci. aktuální ošetření předmětu bych se zmínil o nedávném úsilí W. Cooka:

"Návrh na zjednodušené, moderní definice" objektů "a" objektově orientovaných " http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html

Jak/vzhledem k těmto problémům, jak/proč se stalo, že současný tradiční způsob dělání OOP se stal tak populárním?

Možná stejný důvod QWERTY klávesnice se stal populárním nebo stejný důvod, proč se stal operační systém DOS populární. Věci prostě projdou populárními vozy, navzdory jejich vlastnostem, a stanou se populárními samy. A někdy, podobné, ale horší verze něčeho jsou považovány za skutečnou věc.

A co, pokud něco, lze udělat pro to, aby to bylo odstraněno?

Napište program pomocí nadřazeného přístupu. Napište stejný program pomocí přístupu OO). Ukážte, že první má lepší vlastnosti než ten druhý v každém aspektu, který je významný (jak vlastnosti samotného systému, tak technické vlastnosti). je relevantní a navrhovaný přístup udržuje vysokou kvalitu vlastností, pokud je aplikován na jiné druhy programů. Buďte důslední ve své analýze a v případě potřeby používejte přesné a přijaté definice.

Nakonec se s námi podělte o svá zjištění.

0
Thiago Silva