Chcę wiedzieć, dlaczego Python nie jest w pełni obiektowy. Na przykład nie obsługuje prywatnych, publicznych, chronionych modyfikatorów poziomu dostępu.Dlaczego Python nie jest w pełni obiektowy?
Jakie są zalety i wady tego? W tych wyrażeniach Python jest odpowiedni dla jakich aplikacji (Desktop, Scientific, Web lub inne)?
Python nie obsługuje silnego enkapsulacji, co jest tylko jedną z wielu funkcji związanych z terminem "zorientowany obiektowo".
Odpowiedź jest po prostu filozoficzna. Guido nie lubi ukrywać rzeczy, a wielu w społeczności Pythona zgadza się z nim.
+1, prawidłowa odpowiedź. Chociaż powiedziałbym: Python nie * wymusza (ukrywanie informacji/enkapsulacja) *. obj._field jest "prywatny" w tym idiomatycznym kodzie Pythona nie będzie dostępu do niego, chyba że jest to konieczne (funkcja dir(), odbicie, serializacja, konieczność hackowania wokół ograniczeń dotychczasowego kodu, których nie można zmienić). A Python jest bardziej OO niż np. Java lub C++ lub C#, ponieważ nie ma żadnych elementów pierwotnych. – delnan
@delnan: Masz rację; Python nie wymusza ukrywania/enkapsulacji. Nie obsługuje * ukrywania/enkapsulacji w większym stopniu niż C. W rzeczywistości, bez refleksji, C obsługuje ukrywanie lepiej niż Python! :-) –
Po prostu FYI: prymitywy C# są w rzeczywistości wyprowadzane z System.ValueType, który wywodzi się z System.Object. W rzeczywistości C# jest jedynym naprawdę znanym językiem OO, ponieważ wszystko jest przedmiotem. – Xenoprimate
Myślę, że Python ma być hybrydą. Możesz pisać w stylach obiektowych lub funkcyjnych.
Cechami charakterystycznymi orientacji obiektowej są: abstrakcja, enkapsulacja, dziedziczenie i polimorfizm. Które z nich brakuje w Pythonie?
Orientacja obiektowa jest kontinuum. Można powiedzieć, że Smalltalk jest najczystszym z czystych, a wszystkie inne zajmują różne miejsca na skali.
Nikt nie może powiedzieć, czym jest wartość 100% czystości. Możliwe jest pisanie bardzo dobrego kodu obiektowego w językach, które nie są Smalltalk, w tym Python.
Python jest przydatny we wszystkich obszarach: naukowych (NumPy), sieci (Django) i pulpicie.
Wierzę, że Python jest bardziej praktycznym, pragmatycznym językiem.
Pojęcia, które oferują wartość dla programisty, są wprowadzane bez zbytniego uwzględniania koncepcji teologicznych, takich jak "właściwy projekt OO" i podobne. To język dla ludzi, którzy mają prawdziwą pracę.
Myślę, że Python nadaje się do wszystkich rodzajów środowisk, choć Desktop jest nieco trudny ze względu na brak jednego środowiska. W przypadku wszystkich aplikacji przydatne jest korzystanie z ram, takich jak NumPy dla potrzeb obliczeniowych, Twisted lub Django dla rzeczy internetowych i WxWidgets lub innych na pulpicie.
W rzeczywistości istnieje całe mnóstwo oprogramowania dla GNOME, napisane w Pythonie, sam napisałem 11k linii, kod jest po prostu niesamowicie czytelny i łatwy w utrzymaniu, rozwój jest również bardzo szybki i istnieją powiązania dla prawie wszystkiego. Ale muszę przyznać, że GTK jest czasami bardzo kłopotliwy. –
PyQT jest drogą do zrobienia! PySlide by nokia jest jeszcze lepszy. QT jest teraz również przystosowany do biznesu dzięki LGPL Dzięki Nokia! –
Łącznie z polami w interfejsie obiektów jest _wszystko ale pragmatyczny, sprawia, że refaktoryzacja staje się koszmarem. – Borsunho
Guido powiedział kiedyś, że "wszyscy tutaj zgadzamy się na dorosłych". Oto dłuższe wytłumaczenie dawno temu: http://mail.python.org/pipermail/tutor/2003-October/025932.html
Istnieje umowa, która podkreśla prywatne elementy i nie należy z nich korzystać. Chyba, że wiesz, co robisz i naprawdę chcesz.
Link wspomina również w inny sposób, aby umieścić go w przypadku Perl:
„moduł Perl woleliby że pozostał na swoim salonie
bo nie zostali zaproszeni, nie ponieważ ma strzelbę. "
+1 za cytat, podoba mi się to. – Davy8
Uwielbiam cytaty. Uważam, że posiadanie prywatnych zmiennych instancji jest czymś więcej niż tylko zachowaniem programistów od * wejścia do twojego salonu *. W wielu typowych przypadkach (szczególnie w metodach ustawiania), chcesz, aby obiekt zmieniał lub formatował niektóre dane przed ich wewnętrznym przechowywaniem przez obiekt, niezależnie od przyczyny. W takim przypadku nie można oczekiwać, że inny programista będzie wiedział, jak ta zmienna powinna być przechowywana lub dostępna. Cała ta logika może być ukryta w metodach gettera i ustawiacza. Pozostawienie wystawionych na działanie promieni słonecznych jest nieprzyjemne/mylące/wprowadzające w błąd. To tylko mój jedyny argument na rzecz prywatności. –
Modyfikatory dostępu (publiczne, prywatne, chronione itp.) Nie są wymagane dla class-based programming. Są tylko funkcją, taką jak multiple inheritance.
Czym dokładnie jest zorientowanie na obiekt?Alan Kay powiedział: "Właściwie wymyśliłem termin" obiektowo zorientowany "i mogę powiedzieć, że nie miałem na myśli C++.". Prawdą jest, że prawdopodobnie nie miał też w głowie Pythona, ale warto zauważyć, że Smalltalk chroni również klasy przez konwencję, bez mandatu.
Język jest określany jako Full Objective Oriented, jeśli nie ma żadnych pierwotnych typów danych. Każdy typ danych, które musimy zbudować.
Czy to zadanie domowe? – extraneon
Python nadaje się do prawie wszystkiego, co nie polega na chrupnięciu twardych liczb, ale nawet wtedy można zapisać te części w C. Enkapsulacja nie jest użyteczna w dynamicznie pisanym języku. Pomaga tylko kompilatorowi, nawet w Javie można (i czasami trzeba) obejść go poprzez odbicie. Hermetyzacja, IMHO, nie dodaje żadnych zabezpieczeń, daje tylko poczucie, że istnieje więcej zabezpieczeń. –
@extraneon: Nie, po prostu wiem. @Wetzel: Zgadzam się z tobą na temat 'Encapsulation nie jest użyteczne w dynamicznie pisanym języku'. –