Przeszedłem przez większość studiów programistycznych. Nie jest to stopień informatyki, więc wiele teorii odrzucono na rzecz praktycznego budowania portfolio i tego, co uważam za naukę JIT, co jest najwyraźniej ważniejsze w branży gier. Pierwszym tematem było „Wprowadzenie do programowania obiektowego”.
To zdanie nie przeszkadzało mi, dopóki nie dowiedziałem się o różnych paradygmatach programowania (otrzymuję tę listę z https://en.wikipedia.org/wiki/Comparison_of_programming_paradigms ):
- Tryb rozkazujący
- Funkcjonalny
- Proceduralny
- Zbudowany
- Sterowane zdarzeniami
- Obiektowy
- Deklaracyjny
- Na podstawie automatów
Rozumiem, że nie jest to wyczerpująca lista i że nie wszystkie z tych pojęć są sobie równe, a większość z nich nie jest nawet wyłączna, ale nie rozumiem, dlaczego większość z nich ma tylko jedno słowo - imperatyw; funkcjonalny; deklaratywny - ale kiedy mówimy o programowaniu za pomocą obiektów, musimy wyjaśnić, że jesteśmy zorientowani wokół tych obiektów. Czy nie możemy po prostu używać przedmiotów? Czy nie możemy po prostu mieć przedmiotów? Dlaczego muszą nas zorientować , jako naszą gwiazdę przewodnią?
Patrząc tutaj ( https://en.wikipedia.org/wiki/Object-oriented_programming ), nigdzie nie używa się terminu „zorientowany” jako własnego terminu. Wyjaśniany jest tylko „obiekt”.
Widzę też, z praktycznych powodów, dlaczego używa się sterowanych zdarzeniami, ponieważ programowanie zdarzeń jest już rzeczą, którą robisz, gdy prowadzisz konferencję, a programowanie za pomocą automatów brzmi, jakbyś tworzył robotyczną linię produkcyjną, więc pomaga mieć tam dodatkowe słowa wyjaśniające.
Co sprawia, że programowanie obiektowe jako fraza nie wystarcza do opisania tego, co robimy, gdy używamy obiektów w naszym programowaniu?
Oczywiście z mojego tonu nie przepadam za słowem „zorientowanym”. Przypomina mi się mój czas jako reportera sądowego, słuchanie adwokata za adwokatem używającego wyrażenia „w stosunku do” jako swoistego tykania. To nic nie znaczyło; to był tylko termin, którym używali do wypełnienia powietrza, podczas gdy próbowali wymyślić, co powiedzieć dalej. Jednak nie staram się popierać zmiany języka, tylko pytam, dlaczego tak jest. Jeśli ktoś wie, dlaczego stał się znany w ten sposób z czysto historycznych, szczątkowych powodów, to jest to odpowiedź. To będzie amunicja, jeśli kiedykolwiek zdecyduję się marnować czas na propagowanie zmiany języka.
Z drugiej strony, jeśli rzeczywiście istnieje użyteczny powód, dla którego język lub fragment kodu musi wskazywać na obiekty, z wyłączeniem wszystkich innych kierunków, zamiast tylko umieszczania ich w pasku narzędzi , jako narzędzi , naprawdę byłbym zainteresowany dowiedzieć się o tym. Lubię uczyć się przydatnych rzeczy.
źródło
Odpowiedzi:
Wierzę czytasz sposób zbyt dużo do prostych konstrukcji gramatycznych. Spójrz na swoją listę paradygmatów, posortowaną inaczej z powodów, dla których wkrótce:
Co te słowa mają ze sobą wspólnego? Wszystkie są przymiotnikami, ponieważ mają na celu modyfikację słowa „programowanie”. Ponadto, z wyjątkiem „imperatywnego”, nie wszystkie są „naturalnymi” przymiotnikami, lecz rzeczownikami „przymiotnikowymi” - rzeczownikami, które faktycznie opisują rdzeń paradygmatu: funkcję, strukturę, automaty i przedmiot.
Istnieją dwa różne sposoby przymiotnika rzeczowników: poprzez przyrostek podobny do -al lub -ed lub poprzez utworzenie złożonego słowa za pomocą łącznika. Teraz, jak zauważył Doc Brown, sufiksy, których można użyć do przymiotnika „obiektu”, mają inne znaczenie. Który pozostawia kompozycję.
I twierdzę, że to czysty przypadek lub smak, że Alan Kay zdecydował się użyć „zorientowany” w swoim złożonym przymiotniku „zorientowany obiektowo”. Równie dobrze mógł być „oparty na obiektach” lub „oparty na obiektach”, a ty też możesz w nich czytać zbyt wiele. Czy „napędzany” nie brzmi jak niezdrowa obsesja?
źródło
Szczerze mówiąc, jest to pozostałość po historii. Programowanie funkcjonalne to tak naprawdę programowanie zorientowane na funkcje, programowanie deklaratywne to tak naprawdę programowanie zorientowane na deklarację ... w końcu czyż nie używamy tylko funkcji? Czy nie możemy po prostu mieć funkcji?
„Obiektowo” lepiej zsuwa się z języka i jest historycznie zakorzeniony.
„Orientacja” przychodzi, ponieważ nie mówimy o programowaniu, ale o projektowaniu. To, że używamy obiektów, funkcji lub zdarzeń, nie oznacza, że nasza metodologia projektowania odbywa się poprzez modelowanie wszystkich trzech. Określając orientację metodologii projektowania, pomaga komunikować programistom, w jaki sposób powinni interpretować i rozszerzać ten projekt - w jaki sposób skupienie modelowania zabarwia implementację.
źródło
Wywołanie go, które pomaga wyjaśnić, że przedmioty są bardzo ważną częścią paradygmatu.
Programowanie zorientowane obiektowo ma swoje korzenie w Simula , która była zasadniczo ALGOL, plus kilka nowych funkcji programowania obiektowego. I zgodnie z tą historią, nawet dziś w wielu językach (nawet w „czystych językach OO”) jest całkowicie możliwe kodowanie czegoś, co jest w zasadzie tylko programem proceduralnym z niektórymi obiektami. Ale bardziej doświadczeni programiści uważają to za zły styl.
W rzeczywistości robienie czegoś „zorientowanego obiektowo” różni się bardzo od „sposobu proceduralnego”. Najważniejszą koncepcją jest wykorzystanie dziedziczenia i polimorfizmu. Kiedy naprawdę rozumiesz i internalizujesz sposób działania klas i metod wirtualnych, jest to otwierające oczy doświadczenie, które zmienia sposób pisania kodu w wielu przypadkach, prawdziwa zmiana paradygmatu. (Zakładając oczywiście, że najpierw zacząłeś pisać kod proceduralny. W dzisiejszych czasach wielu studentów wybiera język Java lub C # jako pierwszy język, a IMO naprawdę nie rozumieją korzyści płynących z używania OO.)
Nazywamy to programowaniem obiektowym, ponieważ program napisany w stylu OO zawiera nie tylko obiekty; struktura całego programu jest oparta na nich i na sposobie ich działania.
źródło