Zalety klasycznego OOP w porównaniu z językiem Go-like

Dużo myślałem o projektowaniu języka i o tym, jakie elementy byłyby konieczne dla „idealnego” języka programowania, a studiowanie Google Go skłoniło mnie do zakwestionowania wielu powszechnie znanej wiedzy.

W szczególności Go wydaje się mieć wszystkie interesujące korzyści z programowania obiektowego bez faktycznej struktury języka zorientowanego obiektowo. Nie ma klas, tylko struktury; nie ma dziedziczenia klas / struktur - tylko osadzanie struktur. Nie ma żadnych hierarchii, żadnych klas nadrzędnych, żadnych jawnych implementacji interfejsu. Zamiast tego reguły rzutowania oparte są na luźnym systemie podobnym do pisania kaczego, tak że jeśli struct implementuje niezbędne elementy „Czytnika” lub „Żądania” lub „Kodowania”, możesz go rzutować i używać jak jeden.

Czy jest coś w OOP zaimplementowanym w C ++ oraz Javie i C #, które jest z natury bardziej wydajne, łatwiejsze w utrzymaniu, w jakiś sposób potężniejsze, z którego musisz zrezygnować, przechodząc do języka takiego jak Go? Jakie korzyści musisz poświęcić, aby zyskać prostotę, jaką reprezentuje ten nowy paradygmat?

EDYCJA
Usunięto „przestarzałe” pytanie, na które czytelnicy wydawali się nadmiernie rozłączać i rozwścieczać.

Pytanie brzmi: co ma do zaoferowania tradycyjny paradygmat obiektowy (z hierarchiami itp.), Który często występuje w implementacjach języka wspólnego, czego nie da się zrobić tak łatwo w tym prostszym modelu? Innymi słowy, czy gdybyś dzisiaj zaprojektował język, czy istnieje powód, dla którego chciałbyś uwzględnić koncepcję hierarchii klas?

Nie ma nowego paradygmatu. Orientacja obiektowa to wzorzec używany do pisania programów, który nie jest nawet jasno zdefiniowany. Różne języki zapewniają różne cechy typowe dla orientacji obiektowej (definiowanie nowych typów, enkapsulacja, hierarchie typów, polimorfizm, przekazywanie wiadomości i inne), ale mogą nie zapewniać innych. W takich przypadkach programiści muszą je naśladować, jeśli zajdzie taka potrzeba.

Wiele języków udostępniających te funkcje nie ma odpowiednika koncepcji klas - na przykład Javascript i Common Lisp. Implementacja zapewniana przez języki podobne do Java (oparte na klasach, z pojedynczym dziedziczeniem, interfejsami, wysyłką opartą na typach) jest tylko jedną z możliwości i niekoniecznie najlepszą.

Jakie korzyści musisz poświęcić, aby zyskać prostotę, jaką reprezentuje ten nowy paradygmat?

Sprawdzanie typu dla strukturalnego systemu typów jest o wiele bardziej skomplikowane niż zwykłe sprawdzenie, czy klasa podstawowa znajduje się na liście dziedziczenia. Wysyłanie wirtualne staje się nieco trudniejsze i prawdopodobnie mniej wydajne.

Czy taki system zdezaktualizował koncepcję OOP?

Nie. Tak długo, jak możesz stworzyć program w kategoriach „obiektów, które wykonują czynności”, a nie listy instrukcji, zadeklarowanego zestawu reguł lub kaskadowej serii funkcji ... implementacja nie ma znaczenia. Podobnie zmiana systemu typów nie unieważnia żadnej z powszechnych zasad OO.

Nadal możesz pracować na typie podstawowym i nie przejmować się jego rzeczywistym typem. Nadal możesz rozszerzać typy bez ich modyfikowania. Nadal możesz sprawić, że typ zrobi tylko jedną rzecz. Nadal możesz dostarczać drobnoziarniste interfejsy. Nadal możesz dostarczać abstrakcje swoim typom.

To, jak pozwala język, nie ma tak naprawdę znaczenia.

Myślę, że twój pomysł na OOP jest trochę niepoprawny:

Wymyśliłem termin „Programowanie obiektowe” i to {Java i C ++} nie jest tym, o czym myślałem.
- Alan Kay .

Wybór typowania (nominalne podtypy, strukturalne lub kaczych - lub ich kombinacja) jest w dużej mierze ortogonalny w stosunku do OOP. Dziedziczenie i klasy są całkowicie ortogonalne względem OOP. Jeśli poświęcisz trochę czasu na grę z io , zobaczysz to.

Teraz możesz zapytać, które systemy typów są „lepsze”, a jakie są sposoby ponownego użycia i kombinacji kodów. I spróbuj określić zalety i wady między wyborami dokonanymi w Simula (i później w C ++, Java i C #) a tymi dokonanymi w Go. Ale to są różne i odrębne pytania.

Ostatecznie OOP jest bardzo niejasną koncepcją i wszystkie próby jego wdrożenia mają różnorodne smaki. Ale żeby naprawdę uprościć, powiedziałbym, że podstawową ideą OOP jest komponowanie systemów podsystemów SOLID . Teraz to absolutnie zaciera linię dla innych paradygmatów, ale spekuluję, że to jest powód, dla którego języki wieloparadygmowe ostatnio zyskały na popularności i dlaczego Google podjęło własną próbę w tym przypadku dzięki Go.

OOP nie jest przestarzały.

Jak powiedziała Andrea, zaproponowano wiele koncepcji jako alternatywy dla klas (np. Typklasy Haskell). OOP ma jedną wielką zaletę: naucza się go w wielu miejscach, a kultura OOP jest w dużej mierze dzielona przez programistów.

Umożliwia to bogatszą komunikację w zespole. O fabrykach można mówić łatwiej niż o prego- nomorfizmach zygohistomorficznych . OOP strukturyzuje sposób, w jaki będziesz organizować i komunikować się o swoim programie za pomocą często używanych diagramów. To potężny atut.

Nie, nie ma tu nic nowego, a OOP nie jest przestarzałe. C ++ ma także niejawne interfejsy w postaci szablonów, ale ludzie nadal używają funkcji wirtualnych. Potrzebujesz jawnych interfejsów, aby poradzić sobie np. Z interfejsami binarnymi lub interfejsami, w których drugi kod po prostu nie jest znany w czasie kompilacji.

Można argumentować, że jest to po prostu przypadek wnioskowania w porównaniu z jawnym stwierdzeniem, co nie jest niczym więcej niż „nowym paradygmatem” i jest po prostu wygodniejsze.