it-swarm-eu.dev

Splňuje OOP) příslib opakovaného použití kódu? Jaké alternativy jsou k dosažení opakovaného použití kódu?

Snad největším příslibem použití objektově orientovaného paradigmatu je opakované použití kódu. Někteří zpochybňují, že toho bylo dosaženo. Proč bylo dosaženo (ne)?

Definuje opětovné použití kódu jako OOP, definuje projekty, aby byly projekty produktivnější?

Nebo lépe zvládnutelné? Nebo snadněji udržovatelné? Nebo s vyšší kvalitou?

Pravděpodobně všichni souhlasíme, že opakované použití kódu je dobrá věc, ale existuje několik způsobů, jak tohoto cíle dosáhnout. Otázka se týká způsobu opakovaného použití kódu, který nabízí OOP. Bylo to dobré? Existují lepší metody, jak dosáhnout opětovného použití kód než orientace na objekt, podkategorie, polymorfismus atd.? Jaké způsoby jsou lepší? Proč?

Sdělte nám své zkušenosti s opakovaným použitím OOP nebo opětovným použitím jiných paradigmat).

56
Maniero

Opětovné použití kódu je docela dobrý nápad. Není skvělý .

Mám perspektivu čerpanou z asi 30 let softwarového inženýrství a snažím se „znovu použít“.

Začal jsem zkoumat „opakované použití kódu“ jako téma výzkumu již v 80. letech, poté co jsem zjistil, že jsem znovu použil návrh jednoho operačního systému, který jsem postavil na počátku 70. let, pro další operační systém, který jsem vytvořil na konci 70. let.

Dobrou součástí opakovaného použití kódu je schopnost někdy znovu použít existující kód poctivý k Bohu. Svět je ale plný kódu; jak můžete najít, co chcete? Zde je to, čemu říkám kletna opětovného použití :

Jsem Santa Claus (ok Open Source) a mám pytel 1 miliardy softwarových komponent. Můžete mít kteroukoli z nich.

Hodně štěstí při výběru.

Chcete-li problém s opakovaným použitím dobře vyřešit:

  • opakovatel musí nějak určit, co potřebuje (funkčně, výkon, cílový jazyk, předpoklady prostředí, ...)
  • musí existovat knihovna „opakovaně použitelných“ kódů, která byla indexována různými způsoby podle těchto potenciálních kritérií
  • musí existovat nějaký mechanismus pro výběr prvků kandidáta (u miliard prvků nemůžete na ně všechny osobně pohlédnout)
  • musí existovat způsob, jak charakterizovat, jak daleko od specifikace jsou vybraní kandidáti
  • měl by existovat nějaký běžný proces umožňující uživateli, který opakovaně používá modifikovat vybraný opakovaně použitelný kód (zde je největší přínos OOP: můžete upravit existující komponentu/objekt přepsáním jeho slotů. OOP neposkytuje žádné další pomoc).
  • to vše musí být zjevně levnější, než to jednoduše překódovat

Většinou to, co bylo v průběhu let objeveno, je to, že aby byl kód znovu použitelný, musí být pro tento účel navržen nějaký druh, nebo obsahuje příliš mnoho implicitních předpokladů. Nejúspěšnější knihovny pro opětovné použití kódu byly ve skutečnosti malé. Knihovny a rámce jsou pravděpodobně „opakovaně použitelnými“ kódy a jsou mimořádně úspěšné; Java a C # neuspějí, protože jsou to docela dobré počítačové jazyky, ale spíše proto, že mají k dispozici obrovské dobře navržené, implementované a zdokumentované knihovny. Ale lidé se nedívají na zdrojový kód v knihovny, jednoduše nazývají dobře zdokumentované API (navrženo tak, aby bylo obecně použitelné).

Co opakované použití kódu neprovedlo (ani OOP), je poskytnout příkazy o zlepšení velikosti naší schopnosti kódovat systémy.

Myslím, že klíčovou vadou je, že jakýkoli druh opakovaného použití kódu je zásadně omezený, protože kód obsahuje příliš mnoho předpokladů . Pokud kód zlepšíte, minimalizujete předpoklady, ale pak náklady na stavbu od nuly nejsou příliš velké a zisky z opakovaného použití nejsou efektivní. Pokud kód změníte na obrovské, jsou v novém kontextu téměř zbytečné. Stejně jako Gulliver jsou na pláž vázáni miliony drobných provázků a vy si prostě nemůžete dovolit je všechny snížit.

Na čem bychom měli pracovat, je opětovné použití znalostí k vytvoření kódu . Pokud to dokážeme, můžeme tyto znalosti použít k vytvoření kódu, který potřebujeme, a zpracovat současnou sadu předpokladů.

Aby to bylo možné, je stále potřeba stejných specifikací pro charakterizaci softwarových komponent (stále musíte říci, co chcete!). Pak ale použijete tyto „konstrukční“ znalosti na specifikace, aby vygenerovaly požadovaný kód.

Jako komunita zatím nejsme moc dobří. Ale lidé to dělají pořád; proč to nemůžeme automatizovat? Existuje mnoho výzkumů, což ukazuje, že se to dá provést za mnoha okolností.

Jedním z klíčových prvků potřebných k tomu jsou mechanické nástroje pro přijímání „popisů součástí“ (jedná se pouze o formální dokumenty a lze je analyzovat jako programovací jazyky) a použít programové transformace jim.

Kompilátoři to už dělají: -} A jsou opravdu dobří ve třídě problémů, se kterými se potýkají.

Modely UML s generováním kódu jsou jedním pokusem. Není to velmi dobrý pokus; skoro ve většině modelů UML se říká: „Mám data, která vypadají takto“. Je dost těžké vytvořit skutečný program, pokud je funkce vynechána.

Snažím se stavět praktické systémy pro transformaci programů, nástroj zvaný DMS . Bylo to docela dobře rozptýleno tím, že aplikace transformací programu neměly tolik abstraktních specifikací, aby se vygeneroval kód, ale spíše starší kód, který jej vyčistil. (Jedná se o stejný problém v souhrnu!). (Vytvoření takových nástrojů vyžaduje hodně času; dělám to už 15 let a mezitím musíte jíst).

DMS má ale dvě klíčové vlastnosti, které jsem popsal výše: schopnost zpracovat libovolné formální specifikace a schopnost zachytit „znalosti generování kódu“ jako transformace a aplikovat je na vyžádání. A co je pozoruhodné, v některých zvláštních případech vytváříme nějaký docela zajímavý kód ze specifikací; DMS je z velké části postaven na generování jeho implementace. To pro nás dosáhlo přinejmenším některých příslibů (znalostí) opětovného použití: extrémně významné zvýšení produktivity. Mám tým asi 7 technických lidí; psali jsme pravděpodobně 1–2 MSLOC „specifikací“ pro DMS, ale máme asi 10MSLOC vygenerovaného kódu.

Shrnutí: opakované použití znalostí generace je vítězství, nikoli opakované použití kódu .

35
Ira Baxter

Opětovné použití kódu je dosaženo v OOP, ale je to také dosaženo ve funkčním programování. Kdykoli si vezmete blok kódu a učiníte jej volitelným zbytkem kódu tak, abyste tuto funkci mohli použít) jinde je opakované použití kódu.

Tento typ opakovaného použití kódu také dělá kód lépe spravovatelným, protože změna tohoto jednoho bloku, který lze volat, změní všechna místa, která se mu říká. Řekl bych, že tento výsledek také zvýšil kvalitu a čitelnost.

Nejsem si jistý, že OOP je prostě k zajištění opakovaného použití kódu. Dívám se na OOP) jako další způsob interakce s objekty a abstrakci podrobností o struktura dat.

Z Wikipedie:

Objektově orientované programování má kořeny, které lze vysledovat až do šedesátých let. Jak se hardware a software staly stále složitějšími, stala se spravovatelnost často problémem. Vědci studovali způsoby, jak udržovat kvalitu softwaru, a vyvinout objektově orientované programování částečně pro řešení běžných problémů silným zdůrazněním diskrétních, opakovaně použitelných jednotek programovací logiky [pochvalná zmínka potřebovaný]. Tato technologie se zaměřuje spíše na data než na procesy, přičemž programy se skládají z soběstačných modulů („tříd“), z nichž každá instance („objekty“) obsahuje všechny informace potřebné k manipulaci s vlastní strukturou dat („členy“). To je v kontrastu s existujícím modulárním programováním, které bylo po mnoho let dominantní a které se zaměřovalo spíše na funkci modulu než na specifická data, ale stejně tak poskytovalo opakované použití kódu a soběstačné opakovaně použitelné jednotky programovací logiky, které umožňují spolupráci pomocí propojených modulů (podprogramů). Tento konvenčnější přístup, který stále přetrvává, má tendenci zvažovat data a chování samostatně.

36
Chris

Ano a Ne

Opětovné použití kódu je termín pro mnoho různých činností.

  1. Opětovné použití kódu v rámci jednoho projektu. OO je pro to dokonale vhodné, dobře navržená aplikace bude mapovat vztahy modelového světa těsně, čímž eliminuje duplicitní kód pokud je to možné a vhodné. Můžete však tvrdit, že technologie před OO by mohly dosáhnout stejné věci, což je pravda, ale OO je v mnoha ohledech výhodnější).
  2. Knihovny třetích stran Zdá se, že funguje stejně dobře s nebo bez OO.
  3. Víceúčelové opakované použití kód Největší příslib opakovaného použití kódu OO byl ten kód, jakmile je jednou napsán pro jednu aplikaci, může být později znovu použit pro jinou, kterou neměl) To bylo všechno vztek, když představa OO filtrovaná dveřmi vyšších správních úřadů), a OO zcela nedosáhla toho. Ukázalo se, že účel byl klíčovým aspektem OO design (a možná i všech procedurálních kódů, ale to je jen moje teorie)) a pokusy o opětovné použití kódu skončily katastrofami údržby. (Známý antipatternsof starý rámec, který se nikdo neodváží modifikovat a jeho přítel, obvykle odtud pocházejí poněkud odlišné rámce pro každou aplikaci.)
15
biziclop

Souhlasím s Chrisem, funkční programování je dobrý způsob, jak znovu použít kód.

Mnoho programů má kódové struktury, které se opakují. K tomu se ve světě OOP používají některé návrhové vzory, Ale toho lze dosáhnout pomocí rekurzivních funkcí a párování vzorů ve funkčních programovacích jazycích. Více o tom naleznete v první kapitole Programování reálného světa .

Myslím si, že hluboké dědictví v OOP může být v mnoha případech zavádějící. Máte třídu a mnoho úzce souvisejících metod je implementováno v různých souborech. Joe Armstrong řekl o OOP:

Problém s objektově orientovanými jazyky je v tom, že mají všechny implicitní prostředí, které s sebou nesou. Chtěli jste banán, ale co jste dostali, byla gorila, která držela banán a celou džungli.

Funkce vysokého řádu jsou také velmi užitečné, pokud jde o opětovné použití kódu, např. map a foldr je základem pro MapReduce .

Asynchronní předávání zpráv je také dobrý způsob, jak organizovat složitý software, a někteří počítačoví vědci uvádějí, že s objekty se předpokládá, že s nimi komunikují asynchronně jako v - Řekněte, neptejte se OOP). Více o tom v Objektově orientované programování: Špatná cesta? byly Joe Armstrong je citován:

Začal jsem přemýšlet o tom, co je objektově orientované programování, a myslel jsem, že Erlang není objektově orientovaný, byl to funkční programovací jazyk. Poté můj vedoucí práce řekl: „Ale mýlíte se, Erlang je extrémně objektově orientovaný“. Řekl, že objektově orientované jazyky nejsou objektově orientované. Mohl bych si myslet, i když si nejsem úplně jistý, jestli tomu věřím nebo ne, ale Erlang může být jediný objektově orientovaný jazyk, protože 3 principy objektově orientovaného programování spočívají v tom, že je založen na předávání zpráv , že máte izolaci mezi objekty a máte polymorfismus .

Asynchronní předávání zpráv jako v systémech založených na událostech a v Erlangu je také velmi dobrý způsob, jak oddělit systémy a volná vazba je důležitá ve složitých systémech. S dostatečně odděleným systémem můžete vyvíjet systém, zatímco je spuštěn, možná na různých uzlech. Unibet k tomu předvedl skvělou prezentaci: Architecture Event Driven Architecture

Myslím si však, že většina opakovaného použití kódu se provádí pomocí knihoven a rámců.

13
Jonas

Chtěl bych poslat dlouhou odpověď, ale proč? Udi Dahan to vysvětluje mnohem lépe, než umím.

http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

Zde je začátek příspěvku:

Toto odvětví je obsazeno opětovným použitím.

Existuje přesvědčení, že kdybychom znovu použili více kódu, všechno by bylo lepší.

Někteří dokonce zacházejí tak daleko, že říkají, že celý bod objektové orientace byl znovu použit - nebylo to, zapouzdření bylo velkou věcí. Po této orientaci na komponenty se mělo stát, že se má znovu použít. Očividně to nevyšlo tak dobře ani proto, že zde nyní připínáme naše opětovně použitelné naděje na orientaci na služby.

Byly napsány celé knihy vzorů o tom, jak dosáhnout opětovného použití s ​​orientací dne. Ve snaze o dosažení tohoto cíle byly služby klasifikovány všemi způsoby, od služeb subjektu a služeb, přes procesní služby a orchestrační služby. Kompoziční služby byly nabízeny jako klíč k opakovanému použití a vytváření opakovaně použitelných služeb.

Mohl bych vás také pustit do špinavého tajemství:

Opakované použití je klam

13
Tony

Pokorný unixový kanál udělal více pro opakované použití kódu než cokoli jiného, ​​co přišlo a odešlo. Objekty se náhodou staly intuitivním způsobem strukturování kódu, když k nim došlo, a později se lidé začali zabývat něčím a vším. Obecně jsou objekty určeny pro zapouzdření a nikoli pro opakované použití kódu, opakované použití kódu vyžaduje něco víc a hierarchie dědičnosti třídy je špatnou náhradou toho, čím by mechanismus opakovaného použití kódu měl být.

6
davidk01

OOP není zvláštní; můžete vytvořit opakovaně použitelný kód s nebo bez OOP. Čisté funkce jsou zvláště opakovaně použitelné: například Java.lang.math.sqrt(double) vezme číslo dovnitř a rozdá číslo. Žádný OOP, ale rozhodně více opakovaně použitelný než většina kódu venku.

4
Joonas Pulakka

Z pohledu funkčního programování OOP je hlavně o řízení stavu.

Ve funkčním programování můžete snadno mít stovky užitečných funkcí pro seznamy: http://haskell.org/ghc/docs/6.12.1/html/library/base-4.2.0.0/Data-List.html .

Máte ve třídě Seznam stovky metod? Veřejné metody jsou považovány za rozhraní k internímu stavu, který chcete udržet malý.

Je smutné, že místo (opětného) používání mnoha malých funkcí někteří lidé duplikují funkce. Pro mě je to proto, že OOP ) nepodporuje opětovné použití kódu stejně jako funkční programování.

4
LennyProgrammers

Pro mě ano, ale ne vždy, a mohlo to být provedeno i jinými způsoby.

Většinu času vytvářením abstraktní základní třídy a vytvářením konkrétních implementací této třídy.

Také mnoho rámců využívá dědičnost k zajištění opakovaného použití kódu (Delphi, Java, .Net jsou jen některé, které na jaře okamžitě napadnou).

To neznamená, že spousta užitečných knihoven a úryvků kódu nemohla tuto práci vykonat také, ale je tu něco příjemného o dobře navržené hierarchii objektů.

3
Chris Buckett

Podle mých zkušeností jsem měl větší úspěch využívající „opakovaně použitelný“ kód prostřednictvím obecných programovacích zařízení (jako jsou šablony C++), než jsem používal zásady OOP principy, jako jsou hierarchie dědičnosti).

3
Charles Salvia

OOP je příliš otevřený pro efektivní opětovné použití.

Existuje příliš mnoho způsobů, jak je znovu použít. Každá veřejná třída se ptá: „vytvořte mi novou instanci!“ , každá veřejná metoda říká: „zavolej mi!“ , každá chráněná metoda poskytuje: „přepis mě!“ - a všechny tyto způsoby opětovného použití jsou různé , Mají různé parametry, objevují se v různých souvislostech, všichni mají svá různá pravidla, jak ji volat/rozšířit/potlačit.

[~ # ~] api [~ # ~] je lepší, je to přísná podmnožina OOP (nebo ne -oop), ale ve skutečném životě jsou API nadměrně funkční a navždy rostoucí, stále existuje příliš mnoho připojovacích bodů. Dobré API může život usnadnit, je to nejlepší způsob, jak poskytnout rozhraní pro OOP.


Datadlow paradigma poskytuje přísné rozhraní pro komponenty, mají porty následujících typů:

  • spotřebitelé (vstupy) a
  • producenti (výstupy).

V závislosti na doméně existují některé typy paketů, takže k nim mohou být připojeni zákazníci a výrobci, kteří mají stejné (nebo kompatibilní) porty. Nejkrásnější část toho, že to může udělat vizuálně, protože neexistují žádné parametry ani jiné vylepšení připojení, skutečně spojuje pouze spotřebitele a výrobce.

Byl jsem trochu nejasný, můžete se podívat na "dataflow" tag na StackOverflow , nebo Wikipedia "datafow programování" nebo Wikipedia "flow-based programming" " .

(Také jsem napsal systém datových toků v C++. Takže OOP a DF nejsou nepřátelé, DF) je způsob organizace vyšší úrovně.)

2
ern0

V CommonLisp existuje mnoho způsobů, jak dosáhnout opětovného použití:

  • dynamické psaní, ve výchozím nastavení bude váš kód obecný

  • imperativní abstrakce, tj. podprogramy

  • orientace na objekt, s vícenásobnou dědičností a vícenásobné odeslání

  • syntax-abstrakce, schopnost definovat nové syntaktické konstrukty nebo zkrátit kód kotlové desky

  • funkční abstrakce, uzávěry a funkce vyššího řádu

Pokud se pokusíte porovnat prostředí CommonLisp s jinými jazyky, uvidíte, že hlavní funkcí, která usnadňuje opakované použití kódu, je přítomnost obojí objektově orientovaných a funkčních abstrakcí. Jsou komplementárnější než alternativní: bez jedné z nich jste nuceni doplnit chybějící funkce neohrabaně. Podívejte se například na třídy funktorů používané jako uzávěry a párování vzorů, aby bylo možné odeslat nerozšiřitelnou metodu.

2
Andrea

OOP vám dává více způsoby, jak znovu použít kód. To je vše.

1
Steven A. Lowe

Ve skutečnosti neexistuje nic takového jako „opakované použití“, jak to lidé popisují. Opětovné použití je náhodné vlastnost všeho. Je těžké to naplánovat. Co většina lidí myslí, když mluví o „opětovném použití“, je „použití“. Je to mnohem méně atraktivní a vzrušující termín. Když používáte knihovnu, běžně ji používáte k tomu, pro co bylo určeno. ne opakované použití, pokud s tím neděláte něco opravdu šíleného.

V tomto smyslu se opětovné použití ve skutečném světě týká přeorientování věcí. Mohu zde znovu použít tato sedadla a změnit jejich uspořádání tak, aby vytvořily ... postel! Ne velmi pohodlná postel, ale můžu to udělat. To není jejich primární použití. Znovu je používám mimo jejich původní doménu použitelnosti. [...] Zítra odletím zpět do Velké Británie. ne znovu použiju letadlo. Použiju to pouze k účelu, pro který byl určen, není na tom nic fantastického ani vzrušujícího.

- Kevlin Henney

1
fredoverflow

Horizontální opakované použití: aspekty, vlastnosti, štěpy

Klasický OO někdy chybí opakované použití kódu, zejména když zblázníme všechny dědictví kvůli nedostatku lepšího způsobu sdílení skutečné funkčnosti mezi třídami. Pro tento problém byly vytvořeny horizontální mechanismy opakovaného použití, jako je jako AOP, znaky a štěpy.

Aspektově orientované programování

AOP považuji za chybějící polooranžovou OOP. AOP není tak známá, ale dostala se do produkčního kódu.

Zkusím to vysvětlit jednoduchými slovy: představte si, že můžete vložit a filtrovat funkčnost se speciální strukturou nazvanou aspekt, tyto aspekty mají „metody“, které definují, co a jak bude ovlivněno reflexe , ale v době kompilace se tento proces nazývá tkaní .

Příkladem by mohl být aspekt, který říká „pro všechny metody určitých tříd, které začínají getem, program zapíše do souboru protokolu data, která byla získána, a čas, kdy byla získána“.

Podívejte se na tyto dva rozhovory, pokud chcete lépe porozumět AOP:

Vlastnosti a Grafts

Vlastnosti jsou další konstrukty pro definování opakovaně použitelného kódu, které doplňují OOP, jsou podobné mixins , ale čistší.

Spíše než jejich vysvětlení existuje skvělý PHP RFC, který vysvětluje oba . Znaky přicházejí na PHP btw, jsou již zavázala se ke kufru.

Celkem

OOP je podle mého názoru klíčový v modularitě, a jak jej dnes běžně známe , OOP je stále neúplný .

1
dukeofgaming

Budu riskovat zesměšňování a přiznám se, používám pouze OOP velmi nedávno. Nepřichází ke mně automaticky. Většina mých zkušeností zahrnuje relační databáze, takže myslím tabulky a spojení. Existují tvrzení, že je lepší se to učit od začátku, což se vyhýbá nutnosti znovu propojit vaše myšlení, pokud jde o programování. Nemám ten luxus a odmítám zrušit svou kariéru nad nějakou teorií slonovinové věže. všechno ostatní, přijdu na to.

Nejprve jsem si myslel, že celý koncept nedává smysl. Zdálo se to zbytečné a příliš mnoho problémů. Vím, tohle je šílená řeč. Je zřejmé, že to vyžaduje určitou úroveň porozumění, než budete moci ocenit výhody všeho nebo jej odmítnout pro lepší metody.

Opětovné použití kódu vyžaduje ochotu neopakovat kód, porozumět tomu, jak toho dosáhnout, předem naplánovat. Pokud byste se vyhnuli opakovanému použití kódu, když jste se rozhodli, že máte případ, kdy to prostě nestojí za to? A žádný jazyk není tak striktně OO), že vyvolá chybu, když si myslí, že byste měli zdědit kód z jiné třídy. V nejlepším případě poskytují prostředí příznivé pro jeho implementaci.

Myslím, že největší výhodou OOP je všeobecné přijetí způsobu, jak by měl být kód organizován. Všechno ostatní je omámené. Tým programátorů se nemusí úplně shodnout na tom, jak by měly být strukturovány všechny třídy, ale měli by být schopni najít kód.

Viděl jsem dost procedurálního kódu, abych věděl, že to může být kdekoli a někdy je to všude.

1
JeffO

Čtení výše uvedených příspěvků, několik poznámek:

  • Mnoho lidí si myslí, že opakované použití kódu v OOP znamená dědičnost. Nesouhlasím. Rozhraní a smlouvy jsou jádrem opakovaného použití kódu v OOP systémech. OOP je pokus o šedé pole při vytváření technologie komponenty.
  • Rozdíl mezi doménovými a obecnými „kostry“, které jsou předmětem opakovaného použití, se mi zdá příliš abstraktní. Podle mého názoru na věc, součást (stručná, minimální a opakovaně použitelná smlouva o rozhraní a implementace za ní) může být provedena, pouze pokud je problém, který řeší, dobře pochopen. Komponenta specifická pro doménu, která umožňuje odborníkům mimo doménu vykonávat svou práci s menšími znalostmi o doméně, je (znovu) užitečnou součástí. Uživatelé musí porozumět rozhraní, méně komplikovanosti problémové domény.
  • Úrovně opakovaného použití často zapomenuté: Opakované použití nápadu, Opakované použití specifikace, Opětovné použití architektury/designu, Opakované použití rozhraní, Opakované použití testovacího případu. Opakované použití kódu není vždy příznivé. Ale je to velký spořič času, který se často drží konkrétní architektury a vypořádá se s novým podobným produktem.
  • The OOP Návrhové vzory (Gamma et al.) V mých očích se zabýval spíše technikami taktické implementace, než aby byly smysluplné v kontextu opakovaného použití kódu ve větším měřítku. Pomáhají psát aplikaci s OOP prvky, přesto bych je neviděl jako řešení otázky „opakované použití kódu“ mimo jednu aplikaci).
  • Možná to není fér: 20 let zkušeností s C/C++/C # a 6 měsíců funkčního programování (F #). Jedním z hlavních prvků umožňujících opakované použití je: Lidé musí snadno najít „rozhraní“, prostudovat ho, porozumět mu a poté jej použít. Čisté funkční programování mi neusnadňuje vidět strukturu, kandidáty na opětovné použití nebo kde to všechno začíná a kde to všechno končí. Tak chválený „syntaktický cukr“ je v mých očích často solí, což mi brání snadno vidět, co se děje. Tedy bych se méně pravděpodobně pokusil znovu použít funkční (co to je - svazek funkcí?), Který může mít skryté vedlejší účinky, které nevidím (líné hodnocení, monády, ...). Nechápejte mě špatně, funkční programování má velmi cool stránky, ale všechny silné stránky, které vidím, vidím s velkou mírou pochybností. Jsem velmi zvědavý, co přináší postfunkční budoucnost, a doufám, že ji uvidím, než odejdu do důchodu;)
  • Specifikace, design, implementace jsou spřaženy, ale ne snadno procházitelné pohledy na „stejnou věc“. Mnohem životně důležitější pro zvýšení budoucí produktivity než nové programové paradigma je pro odstranění mezery, pro zvýšení (automatické zdůvodnění, sledovatelnost) vzájemné výhody mezi těmito názory. Nejnaléhavěji potřebujeme formalizované specifikační jazyky, standardizované testovací zápisy (např. Ttcn3) a programovací jazyky podporující ověřování rozhraní a kontraktů podle specifikací bez odhadu.
0
BitTickler

Problém je jemnější:

  1. OOP je skvělá metoda pro strukturování kódu s proměnlivým stavem. Zapouzdřením státu do objektů se imperativní stavový kód stává srozumitelnějším, protože například pokud je část státu vyjádřena jako soukromá pole třídy, víte, že alespoň tento konkrétní stav státu může (A tuto výhodu můžete snadno rozbít zneužitím dědičnosti, btw.) To je nyní dost, ale waaay lepší než ani to nemám.
  2. kód s proměnným stavem je ze své podstaty obtížné znovu použít. Cesta tvrdší než kód pomocí neměnných datových struktur.

Takže OOP sám o sobě není špatný z pov vytváření opakovaně použitelného kód, ale druhy kódů, které se zapisují pomocí OOP jsou ze své podstaty obtížné znovu použít.

Rovněž funkční programování může vést k více opakovaně použitelnému kódu . Dostat právo na abstrakce k psaní rozumného funkčního kódu při dodržení termínu však nemusí být proveditelné. A „napůl doprava“ abstrakce bude snazší vyjádřit styl OOP). A nebude mít tendenci vést k snadnějšímu opakovanému použití kódu - vyšší úroveň abstrakcí znamená, že porozumění kódu bude vyžadovat vyšší počáteční investice z omezené kognitivní kapacity programátorů.

Jako praktický příklad: Herní kód zahrnuje spoustu proměnlivého stavu, protože to je přirozený způsob, jak přemýšlet o kódování hry, pokud se nejedná o velmi logickou/algoritmickou hru, takže to samozřejmě skončí strukturováním pomocí OO. A samozřejmě je těžké znovu použít. Ale stejný kód, který obsahuje stejné znalosti, bylo by těžší opakované použití bez OOP. A přepsání funkčního stylu může vyžadovat zcela změnit způsob, jakým přemýšlíte o tom kódu, znalosti za ním. Jo, výsledné znalosti za kód by byl mnohem jasnější po OO na FP přepsat možná ... ale náklady by mohly být obrovský a může to být druh nákladů, které by také museli platit lidé, kteří chtějí znovu použít neuvěřitelně inteligentní a dobře abstrahovaný kód, s nímž skončíte , tak paradoxně by lidé nakonec kód znovu nepoužívali, i když je to technicky znovu použitelnější.

... což vede k poslední jemnosti: opakované použití kódu je o rozhraní People | Code, nikoli pouze o kódu. OOP dělá slušnou práci s obsluhou tohoto rozhraní, protože dobře mapuje, kolik lidí si myslí o mnoha druzích kódu napsaných v dnešní době. FP může být pro kód lepší) opakované použití, ale ne pro snadné opětovné použití kódu, který lidé dnes potřebují psát. Toto se změní jako druh kódu, který musíme zapsat.

P.S. A pokud někdo chce říci, že „OO není o proměnlivém stavu, můžete také mít OO s neměnným stavem“ ... ... tomu říkám „FP používající třídy jako jmenné prostory“. Je skvělé, když funguje to pro vás a vyhýbá se některým nedostatkům v některých jazykových modulových systémech a může vést k opakovaně použitelnějšímu kódu. Ale to není OO;))

0
NeuronQ

OOP Poskytuje sadu užitečných nástrojů, které umožňují psát kód, který lze použít na více místech, než byste mohli mít bez těchto nástrojů. Pokud napíšete funkci PrintIt, která vezme jakýkoli starý objekt a zavolá na ni funkci .toString(), budete tento kód znovu použit, jakmile jej zavoláte s více než jedním typem objektu. S těmito nástroji každý řádek kódu dělá více.

Funkční programování je nyní mezi bederními velmi horké. Poskytuje vám celou samostatnou sadu nástrojů, aby každý řádek kódu udělal více. Pravděpodobně to není lepší nebo funguje, ale poskytuje další nástroj v sadě nástrojů.

(Byl to šílený nápad pro celou další úroveň objektově orientovaného opětovného použití: Myšlenka byla, že bychom mohli definovat jednu třídu Customer a použít ji v každé aplikaci, kterou jsme napsali. Pak by aplikace byly jen trochu lepidlo sem a tam. To nefungovalo. Ale to neznamená, že OO selhalo, nebo dokonce že opakované použití selhalo. Základní typy opakovaného použití kódu v aplikacích umožnily psát aplikace, které udělaly více, a psát je rychleji.)

0
Sean McMillan