Podczas czytania niektórych książek o programach zauważam, że autorzy mówią, że w OOP możesz mieć pewne zamieszanie, jednocześnie rozumiejąc główną ideę OOP.Zamęt w koncepcji OOP?
I do diabła tak !. Miałem pewne zamieszanie. Czy masz to samo i co powoduje zamieszanie u programistów (nawet doświadczonych programistów) ?!
A jeśli miałeś to, jak mogłeś to pokonać?!
Dzięki
myślę, że szczególnie programistów, które wystąpiły w rozwoju z języków funkcyjnych zorientowanych, miał kłopoty ze zrozumieniem pojęć OOP. Przynajmniej było to dla mnie naprawdę mylące i wykonałem całą masę rzeczy, aby programować funkcjonalnie, używając języka OOP (Java).
Ale uważam również, że podejście OOP jest wielką zaletą dla początkujących, ponieważ to podejście jest bardzo "naturalne".
JavaScript jest świetny do tego, ponieważ jest zarówno językiem funkcjonalnym, jak i WYSOKIM językiem OOP, więc może to być najlepszy język "przejścia" – UnkwnTech
Wiem, co masz na myśli :) Dla celów edukacyjnych szkoda, że nie możesz z nią zbudować żadnej aplikacji. Uważam więc, że Delphi jest dobre dla tej transkrypcji, ponieważ pozwala rozwijać zarówno funkcjonalny, jak i obiektowy. – dajood
Dużo zamieszania podczas nauki OOP pochodzi próbuje odebrać prawo relacji między obiektami i klas obiektów, w szczególności, czy:
ObjectzawieraSome other Object (lub Object1ma się Object2)Objectjest wystąpienie ClassJeśli mogę myśleć o dobrym przykładem, który pokazuje przypadek, w którym albo może być właściwe, będę go dodać ...
+1 dla has-a vs is-a – annakata
Dziękuję za odpowiedzi.
Myślę, że podawanie przykładów działa najlepiej, ale nie zawsze, prawda?!
Słyszałem twórcę C++, kiedy powiedział, że wymaga czasu i cierpliwości, a zrozumiesz to lepiej, próbując.
Bardzo prawdziwe, ale tak długo, jak długo będziesz się zastanawiać nad swoim teoretycznym zrozumieniem za pomocą tej praktyki. To na dłuższą metę sprawi, że sprawy będą bardziej konkretne. – Mystic
Nigdy naprawdę nie miałem żadnego zamieszania, ale nauczyłem się programować wzdłuż osi czasu, które ewoluowało. więc miałem assembly, c, C++, java, C# i mnóstwo innych, co nie jest tutaj istotne. To, co musisz przyjąć, to to, że wszystko musi być wyrażone przez obiekt, a obiekt zawiera informacje opisujące siebie (właściwości) i że mogą wykonywać zadania z nimi związane (metody i.E .: Car.GetAllCars();).
W przypadku dziedziczenia i polimorfizmu oraz całej reszty zalecam praktykę. ćwicz wszystko - skoro praktyka czyni mistrza. Spróbuj opracować przykłady podane we wszystkich książkach.
Po zapoznaniu się z podstawowymi zasadami firmy oo przyjrzyj się wzorom projektowym i zasadom projektowania (np. Czytając Head First Design Patterns). Nauczy Cię, jak właściwie używać narzędzi, które daje ci oo. Chociaż nie zastąpi to praktycznego doświadczenia, może z pewnością przyspieszyć proces uczenia się.
+1 za sugerowanie tej książki :) – Mystic
Tak, początkowo doświadczyłem pewnego zamieszania. To było z powrotem w dniu, kiedy OO dopiero zaczynało stać się głównym nurtem, więc było wiele książek, które go obejmowały, ale nie wyjaśniały tego dobrze ludziom, którzy jeszcze nie wiedzieli, co to jest. W rezultacie zacząłem myśleć, że obiekt i klasa są w dużej mierze wymienne i definiują nową klasę dla każdego obiektu, który chciałem stworzyć.
W końcu "rozumiem", bawiąc się na LambdaMOO, MUD (myślę o World of Warcraft, ale bez grafiki) z obiektowym językiem programowania w grze. Jak na ironię, MOOCode nie rozróżnia klas i obiektów - obiekty dziedziczą bezpośrednio od innych obiektów. (Miała konwencję obiektów przeznaczonych do użytku jako "klasy bazowe", które mają nazywać się "Generic Foo" jako sposób odróżnienia ich od konkretnych ("instancji") Foos, ale jest to tak bliskie rozróżnieniu klas/obiektów, jak to miał.)
W ten sposób doszedłem do pełnego zrozumienia OOP! LambdaMOO dla wygranej. – Brendan
"Jak na ironię, MOOCode nie rozróżnia klas i obiektów - obiekty dziedziczą bezpośrednio od innych obiektów" - OOP nie wymaga klas. To, co opisujesz, nazywa się [oparte na prototypach] (https://en.wikipedia.org/wiki/Prototype- based_programming) OOP, a JavaScript jest przykładem popularnego języka, który używa tego podejścia. –
@ el.pescado - Ironia, o której mówiłem, polegała na tym, że zrozumiałem rozróżnienie między klasami i przedmiotami poprzez pracę z językiem, w którym nie istnieje takie rozróżnienie. Można by oczekiwać, że takie zrozumienie będzie pochodzić z nauki języka, który dokonuje silnego rozróżnienia między wtedy, a nie z języka, który traktuje je jako wymienne. Nie chciałem powiedzieć (lub sugerować), że MOOCode nie jest "prawdziwym" OOP. –
OOP stosuje "zorientowane na problem" podejście do programowania w przeciwieństwie do tradycyjnego podejścia "maszynowego" używanego w językach takich jak C i Pascal. Nauka OOP może być dość trudna, jeśli dobrze programujesz w językach proceduralnych/funkcjonalnych. To dla tych programistów rzeczy wydają się być bardziej zagmatwane. Jeśli jesteś nowy w programowaniu, prawdopodobnie uznasz rzeczy za mniej dezorientujące, ponieważ zaczynasz od świeżego umysłu.
Powiedziałem, że widziałem wielu programistów, którzy pracowali intensywnie z językami takimi jak Java i twierdzą, że są dobrymi programistami OOP, kiedy byli daleko od tego. Oczywiście używają one funkcji języka Java, takich jak interfejsy, dziedziczenie itp., I tworzą obiekty "będące instancjami klas" oraz "wysyłają wiadomość do obiektu". Większość ludzi używa dużo żargonu OOP, ponieważ są na nie narażeni. Ale kiedy sprowadza się do napisania prostej aplikacji, ich wynikowy kod ujawnia ich słabe zrozumienie.
Moja rada dla ciebie, nie daj się złapać w samym żargonie. Zadawaj pytania i ucz się rzetelnie podstawowych pojęć. Możesz mieć swoją pierwszą pół-nirwanę (tak jak ja), gdy nauczysz się polimorfizmu i korzyści, jakie przynosi to, aby zakodować ponowne użycie. Kolejna pół-nirwana, gdy zrozumiesz kompromisy między ponownym użyciem przez dziedziczenie i ponowne użycie przez kompozycję. W końcu będziesz wiedział, że dobrze zrozumiałeś OOP, jeśli jesteś w stanie dobrze zaprojektować, a raczej dobry projekt OO jest łatwo miarą tego, jak dobrze rozumiesz OOP.
Jeśli poważnie myślisz o OOP, powinieneś przeczytać dwa pierwsze rozdziały GOF book on Design Patterns. Może to być trochę trudne dla nowych programistów, ale stanowi sedno myślenia za OOP. Ta książka jest ważnym punktem odniesienia, który powinien mieć każdy poważny programista OOP. Jeśli dobrze rozumiesz koncepcje w tej książce, uważaj się za dobrego programistę OO.
Ja i inni ludzie osiągnęliśmy pół-nirwanę [poznanie zasady "Powiedz, nie pytaj"] (http://programmers.stackexchange.com/a/59209/93338). – Piovezan
Rzeczywiście, myślę, że zbyt duży nacisk kładzie się na koncepcję "klasy".
Największym krokiem naprzód w moim rozumieniu było przeczytanie o zasadzie "Powiedz, nie pytaj".
Zacząłem "odczuwać" Orientację Obiektu podczas zabawy z (i czytaniem) środowiskami typu kaczy, takimi jak Ruby, JavaScript, Python itp. ... po około 8 latach z radością tworzyłem ciężarówki klas w C++.
Statycznie napisane języki doskonale nadają się do kodu produkcyjnego, ale dużo płacisz, starając się uzyskać orientację obiektową.
Ponadto, obok powszechnie używany termin OOP, często zapomina, że najpierw przychodzi OO i OO D.
Czy mógłbyś wyjaśnić, co uważasz za mylące? – Rik
+1 do Rik. Czy możesz powiedzieć nam coś więcej? –
Jaka jest główna idea w OOP i dlaczego uważasz ją za mylącą? Dla mnie "klasy powinny być jedynymi modułami" i nie jest to mylące. –