Jaki jest sens OOP?

O ile wiem, pomimo niezliczonych milionów lub miliardów wydanych na edukację OOP, języki i narzędzia, OOP nie poprawiło produktywności programistów ani niezawodności oprogramowania, ani nie zmniejszyło kosztów rozwoju. Niewiele osób używa OOP w jakimkolwiek rygorystycznym sensie (niewiele osób przestrzega lub rozumie zasady, takie jak LSP); wydaje się, że podejścia, które ludzie przyjmują do modelowania dziedzin problemowych, są mało jednolite lub spójne. Zbyt często klasa ta jest używana po prostu ze względu na cukier składniowy; umieszcza funkcje dla typu rekordu w ich własnej małej przestrzeni nazw.

Napisałem dużą ilość kodu dla szerokiej gamy aplikacji. Chociaż zdarzały się miejsca, w których prawdziwe zastępcze podtypy odgrywały cenną rolę w aplikacji, były one dość wyjątkowe. Ogólnie rzecz biorąc, chociaż mówi się wiele o „ponownym użyciu”, w rzeczywistości jest tak, że jeśli fragment kodu nie robi dokładnie tego , co chcesz, nie ma opłacalnego „ponownego użycia”. Niezwykle trudno jest zaprojektować klasy tak, aby były rozszerzalne we właściwy sposób , więc koszt rozszerzenia jest zwykle tak wysoki, że „ponowne użycie” po prostu nie jest opłacalne.

Pod wieloma względami to mnie nie dziwi. Rzeczywisty świat nie jest „OO”, a idea ukryta w OO - że możemy modelować rzeczy za pomocą jakiejś taksonomii klas - wydaje mi się fundamentalnie błędna (mogę usiąść na stole, pniu drzewa, masce samochodu , czyjeś kolano - ale nie jedno z nich to krzesło). Nawet jeśli przejdziemy do bardziej abstrakcyjnych dziedzin, modelowanie OO jest często trudne, sprzeczne z intuicją i ostatecznie nieprzydatne (rozważ klasyczne przykłady okręgów / elips lub kwadratów / prostokątów).

Więc czego mi tu brakuje? Gdzie jest wartość OOP i dlaczego przez cały czas i pieniądze nie udało się ulepszyć oprogramowania?

Nie ma dowodów empirycznych, które sugerowałyby, że orientacja obiektowa jest dla ludzi bardziej naturalnym sposobem myślenia o świecie. Jest pewna praca w dziedzinie psychologii programowania, która pokazuje, że OO nie jest w jakiś sposób bardziej odpowiednie niż inne podejścia.

Reprezentacje zorientowane obiektowo nie wydają się być uniwersalnie bardziej lub mniej użyteczne.

Nie wystarczy po prostu przyjąć metody obiektowe i wymagać od programistów korzystania z takich metod, ponieważ może to mieć negatywny wpływ na produktywność deweloperów, a także jakość tworzonych systemów.

Który pochodzi z „O użyteczności reprezentacji inspektora nadzoru” z Komunikatów ACM z października 2000 r. Artykuły głównie porównują inspektora nadzoru z podejściem zorientowanym na proces. Istnieje wiele badań na temat tego, jak ludzie pracujący z metodą OO „myślą” (Int. J. of Human-Computer Studies 2001, wydanie 54 lub Human-Computer Interaction 1995, vol. 10, zawiera cały temat dotyczący studiów OO), iz tego, co przeczytałem, nie ma nic, co wskazywałoby na jakąś naturalność w podejściu OO, co czyni je bardziej odpowiednim niż bardziej tradycyjne podejście proceduralne.

Prawdziwy świat nie jest „OO”, a idea ukryta w OO - że możemy modelować rzeczy za pomocą jakiejś taksonomii klas - wydaje mi się fundamentalnie błędna

Chociaż jest to prawdą i zostało zaobserwowane przez inne osoby (weźmy Stiepanowa, wynalazcę STL), reszta to nonsens. OOP może być wadliwy iz pewnością nie jest to srebrna kulka, ale znacznie upraszcza aplikacje na dużą skalę, ponieważ jest to świetny sposób na zmniejszenie zależności. Oczywiście dotyczy to tylko „dobrego” projektu OOP. Niechlujny projekt nie da żadnej korzyści. Ale dobry, odsprzężony projekt może być bardzo dobrze modelowany przy użyciu OOP, a nie przy użyciu innych technik.

Istnieją znacznie lepsze, bardziej uniwersalne modele ( przychodzi na myśl model typu Haskell ), ale często są one również bardziej skomplikowane i / lub trudne do efektywnego wdrożenia. OOP to dobry kompromis między skrajnościami.

OOP nie polega na tworzeniu klas wielokrotnego użytku, chodzi o tworzenie klas użytkowych.

Zbyt często klasa ta jest używana po prostu ze względu na cukier składniowy; umieszcza funkcje dla typu rekordu w ich własnej małej przestrzeni nazw.

Tak, uważam, że jest to również zbyt powszechne. To nie jest programowanie obiektowe. To programowanie obiektowe i programowanie zorientowane na dane. Podczas mojej 10 lat pracy z OO Languages ​​widzę ludzi głównie zajmujących się programowaniem obiektowym. OBP psuje się bardzo szybko IMHO, ponieważ zasadniczo dostajesz najgorsze z obu słów: 1) Programowanie proceduralne bez przestrzegania sprawdzonej metodologii programowania strukturalnego i 2) OOP bez przestrzegania sprawdzonej metodologii OOP.

OOP zrobione dobrze to piękna rzecz. To sprawia, że ​​bardzo trudne problemy są łatwe do rozwiązania, a niewtajemniczonym (nie próbującym brzmieć pompatycznie) może wydawać się niemal magiczne. To powiedziawszy, OOP to tylko jedno narzędzie w zestawie narzędzi metodologii programowania. To nie koniec wszystkich metodologii. Po prostu pasuje do dużych aplikacji biznesowych.

Większość programistów pracujących w językach OOP korzysta z przykładów OOP wykonanych prawidłowo w frameworkach i typach, których używają na co dzień, ale po prostu nie są tego świadomi. Oto kilka bardzo prostych przykładów: ADO.NET, Hibernate / NHibernate, Logging Frameworks, różne typy kolekcji językowych, stos ASP.NET, stos JSP itp ... To wszystko jest w dużym stopniu oparte na OOP w ich bazach kodów.

Ponowne użycie nie powinno być celem OOP - ani żadnego innego paradygmatu w tym zakresie.

Ponowne użycie jest efektem ubocznym dobrego projektu i odpowiedniego poziomu abstrakcji. Kod można wykorzystać ponownie, robiąc coś pożytecznego, ale nie robiąc tak dużo, aby uczynić go nieelastycznym. Nie ma znaczenia, czy kod jest OO, czy nie - ponownie używamy tego, co działa i nie jest trywialne do wykonania samodzielnie. To jest pragmatyzm.

Myśl o OO jako o nowym sposobie ponownego wykorzystania przez dziedziczenie jest zasadniczo wadliwa. Jak zauważyłeś, naruszenia LSP są liczne. Zamiast tego, obiekt OO jest właściwie traktowany jako metoda zarządzania złożonością domeny problemowej. Celem jest utrzymanie systemu w czasie. Podstawowym narzędziem do osiągnięcia tego jest oddzielenie interfejsu publicznego od implementacji prywatnej. Dzięki temu możemy mieć reguły takie jak „To powinno być modyfikowane tylko przy użyciu…” wymuszane przez kompilator, a nie przegląd kodu.

Korzystanie z tego, jestem pewien, że się zgodzisz, pozwala nam tworzyć i utrzymywać niezwykle złożone systemy. Jest w tym wiele wartości i nie jest to łatwe w innych paradygmatach.

Prawie religijne, ale powiedziałbym, że malujesz zbyt ponury obraz stanu współczesnego OOP. Uważam, że to rzeczywiście jest zmniejszenie kosztów, wykonane dużych projektów oprogramowania do opanowania, i tak dalej. Nie oznacza to, że rozwiązano podstawowy problem bałaganu w oprogramowaniu i nie oznacza to, że przeciętny programista jest ekspertem w zakresie OOP. Ale modularyzacja funkcji na komponenty obiektowe z pewnością zmniejszyła ilość kodu spaghetti na świecie.

Przychodzą mi na myśl dziesiątki bibliotek, które pięknie nadają się do wielokrotnego użytku i które pozwoliły zaoszczędzić czas i pieniądze, których nigdy nie da się policzyć.

Ale do tego stopnia, że ​​OOP było stratą czasu, powiedziałbym, że jest to spowodowane brakiem szkolenia programistów, połączonym ze stromą krzywą uczenia się podczas uczenia się mapowania OOP określonego języka. Niektórzy ludzie „otrzymują” OOP, a inni nigdy.

Myślę, że użycie nieprzezroczystych obiektów kontekstowych (HANDLE w Win32, FILE * sw C, żeby wymienić dwa dobrze znane przykłady - do diabła, HANDLE żyją po drugiej stronie bariery trybu jądra i tak naprawdę nie dostaje o wiele bardziej hermetyzowany niż to) znajduje się również w kodzie proceduralnym; Staram się zobaczyć, jak to jest coś szczególnego dla OOP.

HANDLEs (i reszta WinAPI) to OOP! C nie obsługuje zbyt dobrze OOP, więc nie ma specjalnej składni, ale to nie znaczy, że nie używa tych samych koncepcji. WinAPI jest w każdym znaczeniu tego słowa frameworkiem zorientowanym obiektowo.

Widzisz, to jest problem z każdą pojedynczą dyskusją obejmującą OOP lub alternatywne techniki: nikt nie jest jasny co do definicji, wszyscy mówią o czymś innym i dlatego nie można osiągnąć konsensusu. Wydaje mi się, że to strata czasu.

To paradygmat programowania. Zaprojektowany, aby ułatwić nam, zwykłym śmiertelnikom, rozbicie problemu na mniejsze, możliwe do wykonania części.

Jeśli nie uznasz tego za przydatne… Nie używaj go, nie płać za szkolenie i bądź szczęśliwy.

Z drugiej strony uważam to za przydatne, więc będę :)

W porównaniu do prostego programowania proceduralnego, pierwszą podstawową zasadą OOP jest pojęcie ukrywania i hermetyzacji informacji. Idea ta prowadzi do pojęcia klasy, która oddziela interfejs od implementacji. Są to niezwykle ważne koncepcje i podstawa do wprowadzenia ram umożliwiających myślenie o projektowaniu programu w inny i lepszy (myślę) sposób. Tak naprawdę nie można spierać się z tymi właściwościami - nie ma kompromisów i zawsze jest to czystszy sposób modulowania rzeczy.

Inne aspekty OOP, w tym dziedziczenie i polimorfizm, są również ważne, ale jak wspominali inni, są one powszechnie używane. tj .: Czasami ludzie używają dziedziczenia i / lub polimorfizmu, ponieważ mogą, a nie dlatego, że powinni. Są to potężne koncepcje i bardzo przydatne, ale muszą być używane mądrze i nie są automatycznie wygrywającymi zaletami OOP.

Względem ponownego użycia. Zgadzam się, że ponowne użycie zostało sprzedane za OOP. Jest to możliwy efekt uboczny dobrze zdefiniowanych obiektów, zazwyczaj klas prymitywnych / generycznych i jest bezpośrednim wynikiem koncepcji hermetyzacji i ukrywania informacji. Potencjalnie łatwiej jest go ponownie wykorzystać, ponieważ interfejsy dobrze zdefiniowanych klas są po prostu bardziej przejrzyste i nieco samodokumentujące.

Problem z OOP polega na tym, że został wyprzedany.

Zgodnie z pierwotnym zamysłem Alana Kaya była to świetna alternatywa dla wcześniejszej praktyki posiadania surowych danych i globalnych procedur.

Następnie niektóre typy konsultantów ds. Zarządzania zajęły się tym i sprzedawały jako mesjasz oprogramowania, a środowisko akademickie i przemysł, podobnie jak leming, zaczęły kręcić się po nim.

Teraz przypominają lemming po tym, jak inne dobre pomysły zostały wyprzedane, takie jak programowanie funkcjonalne.

Więc co bym zrobił inaczej? Mnóstwo, i napisałem o tym książkę. (Nakład wyczerpany - nie dostaję ani grosza, ale nadal możesz dostać kopie.) Amazon

Moją konstruktywną odpowiedzią jest spojrzenie na programowanie nie jako na sposób modelowania rzeczy w prawdziwym świecie, ale jako sposób kodowania wymagań.

To jest zupełnie inne i opiera się na teorii informacji (na poziomie zrozumiałym dla każdego). Mówi się, że programowanie można postrzegać jako proces definiowania języków, a umiejętność robienia tego jest niezbędna dla dobrego programowania.

Podnosi koncepcję języków specyficznych dla domeny (DSL). Wyraźnie zgadza się z DRY (nie powtarzaj tego). Daje duże uznanie dla generowania kodu. Daje to oprogramowanie o znacznie mniejszej strukturze danych niż jest to typowe dla nowoczesnych aplikacji.

Stara się ożywić ideę, że droga naprzód leży w pomysłowości i że nawet dobrze przyjęte pomysły powinny być kwestionowane.

UCHWYTY (i reszta WinAPI) to OOP!

Czy oni jednak są? Nie są dziedziczone, na pewno nie można ich zastąpić, brakuje im dobrze zdefiniowanych klas ... Myślę, że daleko im do „OOP”.

Czy kiedykolwiek stworzyłeś okno używając WinAPI? Następnie powinieneś wiedzieć, że definiujesz klasę ( RegisterClass), tworzysz jej instancję ( CreateWindow), wywołujesz metody wirtualne ( WndProc) i metody klasy bazowej ( DefWindowProc) i tak dalej. WinAPI bierze nawet nazewnictwo z SmallTalk OOP, wywołując metody „wiadomości” (komunikaty okna).

Dojścia mogą nie być dziedziczone, ale z drugiej strony jest finalw Javie. Nie brakuje im klasy, są symbolem zastępczym dla klasy: to właśnie oznacza słowo „uchwyt”. Patrząc na architektury takie jak MFC czy .NET WinForms, od razu widać, że poza składnią nic nie różni się zbytnio od WinAPI.

Tak, OOP nie rozwiązało wszystkich naszych problemów, przepraszam za to. Pracujemy jednak nad SOA, który rozwiąże wszystkie te problemy.

OOP dobrze nadaje się do programowania wewnętrznych struktur komputerowych, takich jak "widżety" GUI, gdzie na przykład SelectList i TextBox mogą być podtypami elementu, który ma typowe metody, takie jak "move" i "resize".

Problem w tym, że 90% z nas pracuje w świecie biznesu, w którym pracujemy nad koncepcjami biznesowymi, takimi jak faktura, pracownik, praca, zamówienie. Te nie nadają się więc dobrze do OOP, ponieważ „obiekty” są bardziej mgliste, ulec zmianie w zależności od biznesowej re-engineering i tak dalej.

Najgorszym przypadkiem jest sytuacja, w której OO jest entuzjastycznie stosowane do baz danych, w tym do rażących "ulepszeń" OO do baz danych SQL - które są słusznie ignorowane, z wyjątkiem noobów baz danych, którzy zakładają, że muszą być właściwą drogą do robienia rzeczy, ponieważ są nowsze.

Z mojego doświadczenia w przeglądaniu kodu i projektowaniu projektów, przez które przeszedłem, wartość OOP nie jest w pełni uświadomiona, ponieważ wielu programistów nie ma w głowie odpowiedniej koncepcji zorientowanej obiektowo . Dlatego nie programują z projektem OO, bardzo często kontynuując pisanie odgórnego kodu proceduralnego, co sprawia, że ​​klasy są dość płaskie . (jeśli w ogóle możesz to nazwać „projektem”)

Przerażające jest obserwowanie, jak mało współpracownicy wiedzą, czym jest abstrakcyjna klasa lub interfejs, nie mówiąc już o prawidłowym zaprojektowaniu hierarchii dziedziczenia, która odpowiada potrzebom biznesowym.

Jednak gdy obecny jest dobry projekt obiektowy, to po prostu czysta przyjemność z czytania kodu i patrzenia, jak kod w naturalny sposób układa się w intuicyjne komponenty / klasy. Zawsze postrzegałem architekturę i projektowanie systemu jako projektowanie różnych działów i miejsc pracy personelu w firmie - wszyscy są po to, aby wykonać pewną pracę w wielkim schemacie, emitując synergię wymaganą do napędzania organizacji / systemu do przodu.

To oczywiście jest niestety dość rzadkie . Podobnie jak stosunek pięknie zaprojektowanych do horrendalnie zaprojektowanych obiektów fizycznych na świecie, to samo można powiedzieć o inżynierii oprogramowania i projektowaniu. Posiadanie dobrych narzędzi niekoniecznie oznacza dobre praktyki i rezultaty.

Może czepek, kolano lub drzewo nie jest krzesłem, ale wszystkie są do przyjęcia.

Myślę, że te rzeczy z prawdziwego świata to przedmioty

Ty robisz?

Jakie metody ma faktura? Zaczekaj. Nie może się zapłacić, nie może się wysłać, nie może porównać się z przedmiotami, które faktycznie dostarczył sprzedawca. Nie ma żadnych metod; jest całkowicie obojętny i niefunkcjonalny. Jest to typ rekordu (struktura, jeśli wolisz), a nie obiekt.

Podobnie jak inne rzeczy, o których wspominasz.

Tylko dlatego, że coś jest rzeczywiste, nie czyni z tego przedmiotu w sensie OO tego słowa. Obiekty OO są swoistym połączeniem stanu i zachowania, które mogą działać samoistnie. To nie jest coś, czego jest dużo w prawdziwym świecie.

Piszę kod OO przez ostatnie 9 lat. Trudno mi sobie wyobrazić inne podejście niż używanie wiadomości. Główna korzyść, którą widzę, jest całkowicie zgodna z tym, co powiedział CodingTheWheel: modularyzacja. OO naturalnie prowadzi mnie do konstruowania moich aplikacji z modułowych komponentów, które mają przejrzyste interfejsy i jasne obowiązki (tj. Luźno powiązany, wysoce spójny kod z wyraźnym oddzieleniem problemów).

Myślę, że punkt wyjścia się załamuje, gdy ludzie tworzą głęboko zagnieżdżone hierarchie klas. Może to prowadzić do złożoności. Jednak uwzględnienie powszechnej fincjonalności w klasie bazowej, a następnie ponowne użycie jej w innych klasach potomnych jest bardzo elegancką rzeczą, IMHO!

Po pierwsze, obserwacje są nieco niechlujne. Nie mam żadnych danych dotyczących produktywności oprogramowania i nie mam powodu, by sądzić, że nie rośnie. Co więcej, ponieważ jest wielu ludzi, którzy nadużywają OO, dobre użycie OO niekoniecznie spowodowałoby poprawę produktywności, nawet jeśli OO było najlepszą rzeczą od czasów masła orzechowego. W końcu niekompetentny chirurg mózgu prawdopodobnie będzie gorszy niż żaden, ale kompetentny może być nieoceniony.

To powiedziawszy, OO to inny sposób organizowania rzeczy, dołączanie kodu proceduralnego do danych, zamiast operowania kodem proceduralnym na danych. Powinno to być przynajmniej małą wygraną samo w sobie, ponieważ są przypadki, w których podejście OO jest bardziej naturalne. W końcu nic nie stoi na przeszkodzie, aby ktokolwiek mógł napisać proceduralne API w C ++, więc opcja dostarczania obiektów sprawia, że ​​język jest bardziej wszechstronny.

Ponadto jest coś, co OO robi bardzo dobrze: umożliwia staremu kodowi automatyczne wywoływanie nowego kodu, bez żadnych zmian. Jeśli mam kod, który zarządza rzeczami proceduralnie i dodaję coś nowego, podobnego, ale nie identycznego do wcześniejszego, muszę zmienić kod proceduralny. W systemie OO dziedziczę funkcjonalność, zmieniam to, co mi się podoba, a nowy kod jest automatycznie używany ze względu na polimorfizm. Zwiększa to lokalność zmian i to jest Dobra Rzecz.

Wadą jest to, że dobry obiekt OO nie jest darmowy: jego prawidłowe nauczenie się wymaga czasu i wysiłku. Ponieważ jest to popularne hasło, jest wiele osób i produktów, które robią to źle, tylko po to, by to robić. Nie jest łatwiej zaprojektować dobry interfejs klasy niż dobry proceduralny interfejs API i istnieje wiele łatwych do popełnienia błędów (takich jak głębokie hierarchie klas).

Pomyśl o tym jako o innym rodzaju narzędzia, niekoniecznie ogólnie lepszym. Na przykład młotek oprócz śrubokręta. Być może w końcu wyjdziemy z praktyki inżynierii oprogramowania, wiedząc, jakiego klucza użyć, aby wbić śrubę.

@Sean

Jednak uwzględnienie powszechnej fincjonalności w klasie bazowej, a następnie ponowne użycie jej w innych klasach potomnych jest bardzo elegancką rzeczą, IMHO!

Ale programiści „proceduralni” i tak robią to od dziesięcioleci. Składnia i terminologia mogą się różnić, ale efekt jest identyczny. OOP to coś więcej niż „ponowne użycie zwykłej funkcjonalności w klasie bazowej” i mógłbym nawet posunąć się do stwierdzenia, że ​​trudno to w ogóle opisać jako OOP; wywoływanie tej samej funkcji z różnych bitów kodu jest techniką tak starą, jak sama podprocedura.

@Konrad

OOP może być wadliwy iz pewnością nie jest to srebrna kulka, ale sprawia, że ​​aplikacje na dużą skalę są znacznie prostsze, ponieważ jest to świetny sposób na zmniejszenie zależności

To jest dogmat. Nie widzę, co sprawia, że ​​OOP jest znacznie lepsze pod tym względem niż stare programowanie proceduralne. Ilekroć wykonuję wywołanie procedury, izoluję się od specyfiki implementacji.

Dla mnie sama składnia OOP ma dużą wartość. Używanie obiektów, które próbują reprezentować rzeczywiste rzeczy lub struktury danych, jest często znacznie bardziej przydatne niż próba użycia kilku różnych płaskich (lub „pływających”) funkcji do zrobienia tego samego z tymi samymi danymi. Istnieje pewien naturalny „przepływ” do rzeczy z dobrym OOP, który po prostu ma większy sens w czytaniu, pisaniu i utrzymywaniu przez dłuższy czas.

Nie ma znaczenia, że ​​faktura nie jest tak naprawdę „obiektem” z funkcjami, które sama może wykonywać - instancja obiektu może istnieć tylko po to, aby wykonywać funkcje na danych bez konieczności wiedzieć, jaki typ danych faktycznie się tam znajduje. Funkcję „faktura.toJson ()” można z powodzeniem wywołać bez znajomości rodzaju danych „faktura” - wynikiem będzie Json, niezależnie od tego, czy pochodzi z bazy danych, XML, CSV, czy nawet innego obiektu JSON . Dzięki funkcjom proceduralnym musisz nagle dowiedzieć się więcej o swoich danych i otrzymać takie funkcje jak „xmlToJson ()”, „csvToJson ()”, „dbToJson ()” itd. W końcu staje się to kompletnym bałaganem i OGROMNY ból głowy, jeśli kiedykolwiek zmienisz podstawowy typ danych.

Celem OOP jest ukrycie rzeczywistej implementacji poprzez jej abstrakcję. Aby osiągnąć ten cel, musisz stworzyć interfejs publiczny. Aby ułatwić sobie pracę podczas tworzenia tego publicznego interfejsu i zachować SUCHOŚĆ, musisz używać pojęć, takich jak klasy abstrakcyjne, dziedziczenie, polimorfizm i wzorce projektowe.

Tak więc dla mnie prawdziwym nadrzędnym celem OOP jest ułatwienie przyszłej obsługi i zmian kodu. Ale nawet poza tym, może naprawdę znacznie uprościć rzeczy, jeśli zostanie wykonany poprawnie w sposób, w jaki kod proceduralny nigdy nie byłby w stanie. Nie ma znaczenia, czy nie pasuje do „prawdziwego świata” - programowanie za pomocą kodu i tak nie wchodzi w interakcję z rzeczywistymi obiektami. OOP to tylko narzędzie, które sprawia, że ​​moja praca jest łatwiejsza i szybsza - pójdę na to każdego dnia.

@CodingTheWheel

Ale do tego stopnia, że ​​OOP było stratą czasu, powiedziałbym, że jest to spowodowane brakiem szkolenia programistów, połączonym ze stromą krzywą uczenia się podczas uczenia się mapowania OOP określonego języka. Niektórzy ludzie „otrzymują” OOP, a inni nigdy.

Nie wiem, czy to naprawdę zaskakujące. Myślę, że technicznie rozsądne podejście (LSP jest rzeczą oczywistą) utrudnia stosowanie , ale jeśli nie stosujemy takich podejść, i tak sprawia, że ​​kod i tak staje się kruchy i nierozciągliwy (ponieważ nie możemy dłużej o tym myśleć ). Myślę, że sprzeczne z intuicją wyniki, do których prowadzi nas OOP, sprawiają, że nie jest zaskakujące, że ludzie go nie odbierają.

Co ważniejsze, skoro oprogramowanie jest już zasadniczo zbyt trudne do rzetelnego i dokładnego pisania dla zwykłych ludzi, czy naprawdę powinniśmy wychwalać technikę, która jest konsekwentnie słabo nauczana i wydaje się trudna do nauczenia? Jeśli korzyści byłyby wyraźne, warto byłoby wytrwać pomimo trudności, ale nie wydaje się, aby tak było.

@Jeff

W porównaniu do prostego programowania proceduralnego, pierwszą podstawową zasadą OOP jest pojęcie ukrywania i hermetyzacji informacji. Idea ta prowadzi do pojęcia klasy, która oddziela interfejs od implementacji.

Która implementacja jest bardziej ukryta: iostreamy w C ++ czy FILE * w C?

Myślę, że użycie nieprzezroczystych obiektów kontekstowych (HANDLE w Win32, FILE * sw C, żeby wymienić dwa dobrze znane przykłady - do diabła, HANDLE żyją po drugiej stronie bariery trybu jądra i tak naprawdę nie dostaje o wiele bardziej hermetyzowany niż to) znajduje się również w kodzie proceduralnym; Staram się zobaczyć, jak to jest coś szczególnego dla OOP.

Przypuszczam, że może to być częścią tego, dlaczego staram się dostrzec korzyści: części, które są oczywiście dobre, nie są specyficzne dla OOP, podczas gdy części, które są specyficzne dla OOP, nie są oczywiście dobre! (nie oznacza to, że są one koniecznie złe, ale raczej to, że nie widziałem dowodów na to, że mają szerokie zastosowanie i są konsekwentnie korzystne).

Na jedynym blogu deweloperów, który czytałem, autorstwa tego gościa z Joel-On-Software-Founder-of-SO, przeczytałem dawno temu, że OO nie prowadzi do wzrostu produktywności. Automatyczne zarządzanie pamięcią tak. Chłodny. Kto może zaprzeczyć danym?

Nadal uważam, że OO jest dla non-OO tym, czym programowanie z funkcjami jest programowaniem wszystkiego w linii.

(I powinienem wiedzieć, jak zacząłem od GWBasic.) Kiedy refaktoryzujesz kod w celu użycia funkcji, variable2654staje variable3się metodą, w której się znajdujesz. Lub, jeszcze lepiej, ma nazwę, którą możesz zrozumieć, a jeśli funkcja jest krótka , to się nazywa value i to wystarczy do pełnego zrozumienia.

Gdy kod bez funkcji staje się kodem z metodami, możesz usunąć mile kodu.

Kiedy byłaby kod, aby być prawdziwie OO, b, c, q, i Zstać this, this, thisi this. A ponieważ nie wierzę w używanie thissłowa kluczowego, możesz usunąć mile kodu. Właściwie możesz to zrobić, nawet jeśli używasz this.

Nie sądzę, by OO było naturalną metaforą.

Nie uważam też, że język jest naturalną metaforą, ani też nie sądzę, że „zapachy” Fowlera są lepsze niż powiedzenie „ten kod nie smakuje”. To powiedziawszy, myślę, że OO nie dotyczy naturalnych metafor, a ludzie, którzy uważają, że przedmioty po prostu wyskakują na ciebie, w zasadzie nie rozumieją. Definiujesz wszechświat obiektów, a lepsze wszechświaty obiektów dają w rezultacie kod, który jest krótszy, łatwiejszy do zrozumienia, działa lepiej lub wszystkie te elementy (i niektóre kryteria, o których zapominam). Myślę, że ludziom, którzy używają naturalnych obiektów klientów / domeny jako obiektów programistycznych, brakuje możliwości przedefiniowania wszechświata.

Na przykład, gdy dokonujesz rezerwacji w systemie lotniczym, to, co nazywasz rezerwacją, może w ogóle nie odpowiadać rezerwacji prawnej / biznesowej.

Niektóre z podstawowych pojęć to naprawdę fajne narzędzia

Myślę, że większość ludzi przesadza z tą całością „kiedy masz młotek, wszystkie są gwoździami”. Myślę, że druga strona monety / lustra jest równie prawdziwa: kiedy masz gadżet taki jak polimorfizm / dziedziczenie, zaczynasz znajdować zastosowania, w których pasuje jak rękawiczka / skarpeta / soczewka kontaktowa. Narzędzia OO są bardzo potężne. Myślę, że dziedziczenie pojedyncze jest absolutnie konieczne, aby ludzie nie dali się ponieść emocjom, a moje oprogramowanie do dziedziczenia wielokrotnego nie wytrzymuje tego.

Jaki jest sens OOP?

Myślę, że to świetny sposób na obsługę absolutnie ogromnej bazy kodu. Wydaje mi się, że pozwala to organizować i reorganizować kod, a także daje język, w którym można to robić (poza językiem programowania, w którym pracujesz), a także modularyzuje kod w całkiem naturalny i łatwy do zrozumienia sposób.

OOP jest skazane na niezrozumienie przez większość programistów

Dzieje się tak, ponieważ jest to proces, który otwiera oczy, podobnie jak życie: dzięki doświadczeniu coraz lepiej rozumiesz OO i zaczynasz unikać pewnych wzorców i zatrudniać innych, gdy stajesz się mądrzejszy. Jednym z najlepszych przykładów jest to, że przestajesz używać dziedziczenia dla klas, których nie kontrolujesz, i zamiast tego wolisz wzorzec Fasada .

Odnośnie twojego mini-eseju / pytania

Chciałem wspomnieć, że masz rację. Wielokrotne użycie to w większości mrzonka. Oto cytat Andersa Hejilsberga na ten temat (genialny) stąd :

Jeśli poprosisz początkujących programistów o napisanie kontrolki kalendarza, często pomyślą sobie: „Och, napiszę najlepszą kontrolkę kalendarza na świecie! Będzie polimorficzna w odniesieniu do rodzaju kalendarza. Będzie miała wyświetlacze, i mungers, i to, tamto i inne. " Muszą wysłać aplikację kalendarza za dwa miesiące. Umieścili całą tę infrastrukturę pod kontrolą, a następnie spędzili dwa dni, pisząc na niej kiepską aplikację kalendarza. Pomyślą: „W następnej wersji aplikacji zrobię o wiele więcej”.

Kiedy zaczną myśleć o tym, jak faktycznie zamierzają wdrożyć wszystkie te inne konkretyzacje swojego abstrakcyjnego projektu, okazuje się, że ich projekt jest całkowicie błędny. A teraz zamalowali się w kącie i muszą wszystko wyrzucić. Widziałem to w kółko. Mocno wierzę w bycie minimalistycznym. Chyba że faktycznie masz zamiar rozwiązać ogólny problem, nie próbuj tworzyć ram do rozwiązania konkretnego problemu, ponieważ nie wiesz, jak ten framework powinien wyglądać.

Czy kiedykolwiek utworzyłeś okno za pomocą WinAPI?

Więcej razy, niż chciałbym pamiętać.

Następnie powinieneś wiedzieć, że definiujesz klasę (RegisterClass), tworzysz jej instancję (CreateWindow), wywołujesz metody wirtualne (WndProc) i metody klasy bazowej (DefWindowProc) i tak dalej. WinAPI bierze nawet nazewnictwo z SmallTalk OOP, wywołując metody „wiadomości” (komunikaty okna).

Wtedy będziesz również wiedział, że nie wysyła własnej wiadomości, co jest wielką pustką. Ma też kiepską podklasę.

Dojścia mogą nie być dziedziczone, ale w Javie jest wersja ostateczna. Nie brakuje im klasy, są symbolem zastępczym dla klasy: to właśnie oznacza słowo „uchwyt”. Patrząc na architektury takie jak MFC lub .NET WinForms, od razu widać, że poza składnią nic nie różni się zbytnio od WinAPI.

Nie są dziedziczone ani w interfejsie, ani w implementacji, są w minimalnym stopniu zastępowalne i nie różnią się zasadniczo od tego, co koderzy proceduralni robili od zawsze.

Czy to naprawdę to? Najlepsze elementy OOP to po prostu ... tradycyjny kod proceduralny? To wielka sprawa?

Zgadzam się całkowicie z odpowiedzią InSciTek Jeffa , dodam tylko następujące udoskonalenia:

• Ukrywanie i hermetyzacja informacji: krytyczne dla każdego możliwego do utrzymania kodu. Można to zrobić, zachowując ostrożność w każdym języku programowania, nie wymaga funkcji OO, ale zrobienie tego spowoduje, że twój kod będzie nieco podobny do OO.
• Dziedziczenie: istnieje jedna ważna domena aplikacji, dla której wszystkie te OO są-swego rodzaju i zawierają-a- relacje są idealnie dopasowane: Graficzne interfejsy użytkownika. Jeśli spróbujesz zbudować GUI bez obsługi języka OO, i tak skończysz budowanie funkcji podobnych do OO, a bez obsługi języka jest to trudniejsze i bardziej podatne na błędy. Na przykład Glade (ostatnio) i X11 Xt (historycznie).

Korzystanie z funkcji obiektowych (szczególnie głęboko zagnieżdżonych hierarchii abstrakcyjnych), gdy nie ma sensu, jest bezcelowe. Ale w przypadku niektórych domen aplikacji jest naprawdę sens.

Uważam, że najbardziej korzystną cechą OOP jest ukrywanie / zarządzanie danymi. Jednak istnieje wiele przykładów niewłaściwego wykorzystania OOP i myślę, że w tym miejscu pojawia się zamieszanie.

To, że możesz zrobić z czegoś przedmiot, nie oznacza, że ​​powinieneś. Jeśli jednak uczyni to twój kod bardziej zorganizowanym / łatwiejszym do odczytania, zdecydowanie powinieneś.

Świetnym praktycznym przykładem, w którym OOP jest bardzo pomocne, jest klasa „produkt” i obiekty, których używam na naszej stronie internetowej. Ponieważ każda strona jest produktem, a każdy produkt ma odniesienia do innych produktów, może to być bardzo mylące, jeśli chodzi o produkt, do którego odnoszą się dane. Czy ta zmienna „strURL” jest linkiem do bieżącej strony, strony głównej lub strony statystyk? Jasne, że można by tworzyć różnego rodzaju zmienne odwołujące się do tych samych informacji, ale proCurrentPage-> strURL jest dużo łatwiejsze do zrozumienia (dla programisty).

Ponadto dołączanie funkcji do tych stron jest znacznie czystsze. Mogę zrobić proCurrentPage-> CleanCache (); Następnie proDisplayItem-> RenderPromo (); Gdybym tylko wywołał te funkcje i założył, że dostępne są aktualne dane, kto wie, jakie zło by się wydarzyło. Ponadto, gdybym musiał przekazać poprawne zmienne do tych funkcji, wróciłbym do problemu posiadania różnych rodzajów zmiennych dla różnych produktów.

Zamiast tego, używając obiektów, wszystkie moje dane i funkcje produktów są ładne, czyste i łatwe do zrozumienia.

Jednak. Duży problem z OOP polega na tym, że ktoś uważa, że ​​WSZYSTKO powinno być OOP. Stwarza to wiele problemów. Mam 88 tabel w mojej bazie danych. Mam tylko około 6 zajęć, a może powinienem mieć około 10. Zdecydowanie nie potrzebuję 88 zajęć. W większości przypadków bezpośredni dostęp do tych tabel jest całkowicie zrozumiały w okolicznościach, w których go używam, a OOP faktycznie utrudniłoby / uciążliwe dotarcie do podstawowej funkcjonalności tego, co się dzieje.

Uważam, że hybrydowy model obiektów, gdzie użyteczne i proceduralne, gdzie praktyczne, jest najskuteczniejszą metodą kodowania. Szkoda, że ​​mamy te wszystkie wojny religijne, w których ludzie opowiadają się za użyciem jednej metody kosztem innych. Oboje są dobrzy i oboje mają swoje miejsce. W większości przypadków obie metody mają zastosowanie w każdym większym projekcie (w niektórych mniejszych projektach wystarczy jeden obiekt lub kilka procedur).

Nie zależy mi na ponownym wykorzystaniu tak bardzo, jak na czytelności. To drugie oznacza, że ​​kod jest łatwiejszy do zmiany. Już samo to jest warte złota w rzemiośle tworzenia oprogramowania.

A OO to cholernie skuteczny sposób na uczynienie programów czytelnymi. Używaj ponownie lub nie używaj.

„Prawdziwy świat nie jest„ OO ”,„

Naprawdę? Mój świat jest pełen przedmiotów. Używam teraz. Myślę, że posiadanie programowych „obiektów” modelujących rzeczywiste obiekty może nie być takie złe.

Projekty OO dla rzeczy koncepcyjnych (takich jak Windows, nie okna świata rzeczywistego, ale panele wyświetlania na monitorze komputera) często pozostawiają wiele do życzenia. Ale w przypadku rzeczy ze świata rzeczywistego, takich jak faktury, zamówienia wysyłkowe, roszczenia ubezpieczeniowe i inne rzeczy, myślę, że te rzeczy ze świata rzeczywistego są obiektami. Mam stos na biurku, więc muszą być prawdziwe.

Celem OOP jest zapewnienie programiście innych środków do opisania i zakomunikowania rozwiązania problemu w kodzie maszynom i ludziom. Najważniejszą częścią tego jest komunikacja z ludźmi. OOP pozwala programiście zadeklarować, co mają na myśli w kodzie za pomocą reguł, które są egzekwowane w języku OO.

W przeciwieństwie do wielu argumentów na ten temat, koncepcje OOP i OO są wszechobecne w całym kodzie, w tym w kodzie w językach innych niż OOP, takich jak C. Wielu zaawansowanych programistów spoza OO będzie przybliżać cechy obiektów nawet w językach innych niż OO.

Posiadanie OO wbudowanego w język daje programiście jedynie inne środki wyrazu.

Największą częścią pisania kodu nie jest komunikacja z maszyną, ta część jest łatwa, największa część to komunikacja z ludzkimi programistami.