Jak ćwiczyć programowanie obiektowe? [Zamknięte]

Zawsze programowałem w językach proceduralnych i obecnie przechodzę do orientacji obiektowej. Głównym problemem, z którym się spotkałem, jest to, że nie widzę sposobu, aby ćwiczyć orientację obiektową w efektywny sposób. Wyjaśnię mój punkt widzenia. Kiedy nauczyłem się PHP i C, było dość łatwo ćwiczyć: wystarczyło wybrać coś i pomyśleć o algorytmie do tego.

Na przykład w PHP chodziło o to, żeby usiąść i pomyśleć: „cóż, tylko poćwiczę, pozwól mi zbudować jedną aplikację z obszarem administracyjnym, w którym ludzie mogą dodawać produkty”. Było to dość łatwe, wystarczyło pomyśleć o algorytmie, aby zarejestrować jakiegoś użytkownika, zalogować się do niego i dodać produkty. W połączeniu z funkcjami PHP był to dobry sposób na ćwiczenie.

Teraz w orientacji obiektowej mamy wiele dodatkowych rzeczy. Nie chodzi tylko o myślenie o algorytmie, ale o głębszą analizę wymagań, pisanie przypadków użycia, opracowywanie diagramów klas, właściwości i metod, konfigurowanie wstrzykiwania zależności i wiele innych rzeczy.

Najważniejsze jest to, że w sposobie uczenia się orientacji obiektowej wydaje się, że dobry projekt ma kluczowe znaczenie, podczas gdy w językach proceduralnych wystarczył jeden niejasny pomysł. Ja nie mówią, że w językach proceduralnych możemy napisać dobre oprogramowanie bez projektu, tylko że przez wzgląd na ćwiczenia to jest możliwe, natomiast w położeniu obiektu nie wydaje się możliwe, aby przejść bez dobrego projektu, nawet dla praktykujących.

To wydaje się być problemem, ponieważ jeśli za każdym razem, gdy będę ćwiczyć, muszę wymyślić mnóstwo wymagań, przypadków użycia i tak dalej, wydaje się, że nie jest to dobry sposób na lepszą orientację obiektową, ponieważ wymaga to mam cały pomysł na aplikację za każdym razem, gdy będę ćwiczyć.

Z tego powodu jaki jest dobry sposób ćwiczenia orientacji obiektowej?

Teraz w orientacji obiektowej mamy wiele dodatkowych rzeczy.

Nie, nie ...

Nie chodzi tylko o myślenie o algorytmie, ale o głębszą analizę wymagań, pisanie przypadków użycia, opracowywanie diagramów klas, właściwości i metod, konfigurowanie wstrzykiwania zależności i wiele innych rzeczy.

Żadna z tych rzeczy nie jest konieczna do ćwiczenia programowania obiektowego.

Było to dość łatwe, wystarczyło pomyśleć o algorytmie, aby zarejestrować jakiegoś użytkownika, zalogować się do niego i dodać produkty.

Całe programowanie obiektowe zamiast myśleć o algorytmach wykonujących te kroki, zastanawiasz się, jakie obiekty są potrzebne do wykonania tych kroków - jakiej funkcjonalności potrzebujesz, jaki stan jest potrzebny do tego i jaki rodzaj interfejsu chcesz udostępnić do użytkownika. Podobnie jak w przypadku programowania proceduralnego.

Jedyną różnicą jest to, że zamiast skupiać się na potrzebnych funkcjach i sposobie ich działania, skupiasz się na tym, jak funkcjonalność i stan są pogrupowane w obowiązki i jak te obowiązki oddziałują.

Jak ćwiczyć? W ten sam sposób ćwiczysz programowanie proceduralne: wybierz problem i rozwiąż go za pomocą pakietów klas. Dowiedz się, jak to jest do bani, powtórz z wyciągniętymi wnioskami.

Dobre pytanie. Oczywiście mówisz, że ćwiczenie OOP w rzeczywistości oznacza ćwiczenie wszystkich tych rzeczy (analiza wymagań, przypadki użycia, wzorce projektowe itp.), Co jest prawdą i może początkowo wydawać się zniechęcające.

Radzę rozpocząć sesje treningowe od dwóch rzeczy: rozwoju opartego na testach i zasady pojedynczej odpowiedzialności .

Następnie zacznij jak w PHP / C: wymyśl pomysł, zastanów się, czego potrzebujesz i zaimplementuj te rzeczy jedna po drugiej. Należy jednak pamiętać, że należy rozpocząć od testów (co zmusza do zdefiniowania odpowiednich interfejsów, ponieważ w przeciwnym razie cierpi na testowalność) i że TDD oznacza cykl refaktora czerwono-zielonego. Innymi słowy, masz odrobinę funkcjonalności, a kiedy już działa, refaktoryzujesz, aby uzyskać odpowiedni projekt OO, jeśli nie zrobiłeś go od samego początku (czego nie zrobisz).

Wykonując ten krok refaktoryzacji, zawsze przypominaj sobie o SRP. Jeśli dodałeś drugą odpowiedzialność do swojego obiektu, nadszedł czas, aby stworzyć coś nowego.

Kiedy rozwijasz się w ten sposób, musisz mieć świadomość, że twoje ostateczne rozwiązanie będzie znacznie różnić się od tego, od czego zaczynasz. Twoja krzywa uczenia się również będzie dość stroma. Na przykład nie nauczysz się, czym jest wzorzec Fabryki, ale rozpoznasz potrzebę czegoś, co tworzy instancje twojej klasy na różne sposoby. Więc jeśli w ogóle nie słyszałeś o wzorcach projektowych zorientowanych obiektowo, dobrze jest przeczytać trochę o tych równolegle.

Jeśli dopiero zaczynasz w OOP, możesz bawić się i „ćwiczyć” offline, patrząc na dowolny system w świecie rzeczywistym i zastanawiając się, czym są obiekty i jaka jest ich relacja oraz jakie metody / interfejsy mogą obsługiwać i jak reprezentowałbyś je w hierarchii klas i jako zbiór instancji obiektów oraz jakie byłyby relacje własności obiektu i tak dalej (uwaga: w ogóle nie wspominam słowa „algorytmy” powyżej). Narysuj wiele diagramów (poznaj trochę UML lub podobny), zanim zaczniesz myśleć o kodowaniu.

Pomoże ci to rozwinąć o wiele lepsze wyczucie relacji IS-A i HAS-A , co jest prawdopodobnie najważniejszą klasyfikacją w każdym projekcie OOP (a mimo to nadal wydaje się być czymś, z czym zmaga się wielu doświadczonych programistów języka OOP ). Jeśli opanujesz IS-A / HAS-A, jest również IS-IMPLEMENTED-IN-WARMS-OF (który widziałem również opisany jako IS-KIND-OF-A: ^)

Poważnie, podczas następnej podróży do supermarketu wyobraź sobie, że ktoś dał ci zadanie napisania symulacji OOP tego miejsca ...

To, co pamiętam z moich czasów C (daleko w przeszłości), zwykliśmy oddzielać funkcje i procedury do różnych plików na podstawie ich odpowiedzialności. Nie twierdzę, że jest idealny, ani nic, ale był to dobry punkt wyjścia, kiedy zacząłem programować w językach obiektowych. Być może możesz zacząć od konwersji plików na obiekty.

Jeśli chodzi o OOP, tak naprawdę chodzi o praktykę i dążenie do poprawy. Rzadko każdy dostaje to od podstaw. Tak więc iteracje odbywają się w całym cyklu życia projektu.

Dodajmy trochę terminologii, analizy obiektowej i projektowania obiektowego , jak zrobił to Peter Coad w latach 90.

Razem tworzą one dyscyplinę inżynierii oprogramowania OOAD, która może (właściwie zrobić) wspierać programistę w punkcie pisania i testowania kodu. Programowanie obiektowe może wtedy mieć odpowiedni poziom szczegółowości, umiejętne wykorzystanie funkcji języka programowania w celu spełnienia celów funkcjonalnych i wymagań projektowych określonych na poziomie projektu.

Czasami jest to projekt jednoosobowy, a następnie musisz nosić wszystkie czapki (ale niekoniecznie wszystkie w tym samym czasie). Jestem wielkim fanem programowania opartego na testach dla moich osobistych projektów (patrz zalecenie Franka), ale nie dotyczy to tylko programowania obiektowego.

W projekcie zespołowym dobry podział obowiązków jest kluczem do pomyślnego wdrożenia. Umiejętne stosowanie zorientowanych obiektowo wzorców projektowych pomaga zespołowi zrozumieć, ograniczając widoczne interfejsy potrzebne do analizy, przesyłania danych i logiki biznesowej w celu udostępniania użytecznej struktury.

„cóż, tylko poćwiczę, pozwól mi zbudować jedną aplikację z obszarem administracyjnym, w którym ludzie mogą dodawać produkty”. Było to dość łatwe, wystarczyło pomyśleć o algorytmie, aby zarejestrować jakiegoś użytkownika, zalogować się do niego i dodać produkty.

Dlaczego nie zrobić tego samego tylko tym razem z obiektami użytkownika i obiektami produktu? Również jeśli używasz języka, który obsługuje zarówno procedury, jak i OO, możesz spróbować zaimplementować obiekty oparte na standardowej bibliotece procedur, takie jak obiekt pliku.