Jak uzyskałeś dobre praktyki w projektowaniu OOP? [Zamknięte]

Uświadomiłem sobie, że mam trudności z tworzeniem projektów OOP. Spędziłem wiele czasu decydując, czy ta właściwość jest poprawnie ustawiona na klasę X.

Na przykład jest to post, który ma kilka dni: /codereview/8041/how-to-improve-my-factory-design

Nie jestem przekonany do mojego kodu. Chcę więc ulepszyć moje projekty, nie zajmując więcej czasu.

Jak nauczyłeś się tworzyć dobre projekty? Jakieś książki, które możesz mi polecić?

Projektowanie systemów to jedna z rzeczy, w których można poprawić się tylko dzięki temu. Oczywiście pomaga trochę poczytać o dobrym projektowaniu - zalecana ogólna książka obiektowa to Gang of Four's Designs Designs: Elements of Wielokrotnego użytku obiektowego oprogramowania . Istnieją również inne książki na temat wzorców projektowych i zasad dla różnych typów systemów i w różnych domenach.

Najlepiej też zaangażować inne osoby. Po utworzeniu projektu przedstaw problem (y), który rozwiązujesz oraz projekt innym osobom w celu dokonania krytycznej recenzji. Słuchaj ich opinii i prowadź z nimi dialog, koncentrując się na tym, dlaczego podjąłeś decyzje. Wdrażając rozwiązanie, zdasz sobie sprawę z innych problemów ze swoim projektem. Zanotuj je i ucz się od nich. Dobrym pomysłem może być również współpraca z innymi ludźmi w celu sprawdzenia wdrożenia pod kątem projektu i wymagań oraz przeprowadzenie krytycznej dyskusji na temat powodów, dla których zrobiłeś to, co zrobiłeś.

Chociaż zwykle uważam, że najlepiej jest usiąść twarzą w twarz z innymi ludźmi, tutaj na Programistach można zadać konkretne pytania projektowe. Istnieją również strony Stack Exchange do recenzji kodu i pytań implementacyjnych .

Patrząc na pytanie, które zadałeś w widoku kodu, jesteś na etapie przesadzania. Myślę, że jest to dość powszechny problem wśród ludzi, którzy odkrywają znaczenie dobrego projektowania.

W rzeczywistości jest to naturalny i prawdopodobnie nawet niezbędny krok przy każdej umiejętności, którą podnosisz. Gdy zaczniesz się czegoś uczyć, im bardziej posiądziesz wiedzę na temat umiejętności i im bardziej ją zastosujesz, tym lepsze wyniki i wydaje się, że zmierzałeś prosto do mistrzostwa. Problem polega na tym, że Twoim nowym celem nie jest jakość wyników, ale ilość wiedzy, którą zgromadziłeś na temat swoich umiejętności.

Prawdziwe opanowanie umiejętności wymaga zrozumienia, kiedy jej użyć, a kiedy nie. Nadużywanie tej umiejętności jest prawdopodobnie jedynym sposobem na rozwinięcie takiego zrozumienia. Jasne, możesz o tym przeczytać, ale czytanie nie zastąpi doświadczenia.

Po pierwsze, czytanie o wzorach projektowych to zły początek IMHO. Lepsze jest czytanie o zasadach projektowania OO, takich jak SOLID i GRASP . Po zapoznaniu się z nimi dobrym pomysłem jest przestudiowanie typowych wzorców projektowych, ponieważ zobaczysz, w jaki sposób można zastosować te zasady do tworzenia konkretnych idiomów.

Twierdzi się, że kiedy pojawiają się wzorce w użyciu języka, język faktycznie nie ma żadnej cechy. Chociaż to stwierdzenie jest bardzo radykalne, jest w nim wiele prawdy. Dlatego proponuję, abyś spojrzał na inne języki i bawił się nimi, aby lepiej zrozumieć koncepcje, które chcesz zastosować, a także poznać nowe koncepcje. Krótka lista to Squeak, Ruby i Lisp.
Jeśli chodzi o Listę, moją osobistą rekomendacją jest Struktura i interpretacja programów komputerowych , która nauczyła mnie wiele o projektowaniu, pokazując mi, jak bez wysiłku można tworzyć solidne rozwiązania złożonych problemów, z niewiele więcej niż wyraźną abstrakcją i (de) kompozycją w sposób odgórny.

Oto, co sugeruję:

1. napisz kod (i spróbuj zrozumieć, co czyni go złym)
2. przeczytaj kod (i spróbuj zrozumieć, co czyni go dobrym)
3. wymieniać wiedzę z innymi ludźmi. przetestuj swoje pomysły.

Jak wspomnieli inni, zdobędziesz dobrą praktykę i doświadczenie. Nie ma tak wiele skrótu, jaki możesz wziąć.

Fakt, że patrzysz wstecz na swoje rzeczy i nie podoba ci się to, co napisałeś, już stawia Cię na czele w porównaniu z wieloma innymi osobami w naszym zawodzie. Podczas gdy próbujesz się poprawić, reszta z nas pracuje z ludźmi, którzy napisaliby funkcję 500-liniową z 20 parametrami, wszystkie przekazane przez odniesienie, a 15 z nich było [wejście / wyjście] i ci ludzie myślą, że to bomba ponieważ zmusili ten bałagan do pracy.

Jeśli chodzi o projektowanie oprogramowania, to nie jest czarno-białe, albo projekt jest dobry, albo zły. Bez względu na to, ile masz doświadczenia, wrócisz do starego kodu i pomyślisz: „Co ja paliłem, kiedy to pisałem?”. Kluczem jest ciągła ocena rzeczy i częste przechodzenie przez ćwiczenia myślowe, aby ocenić, co czyni dobry kod dobrym, a zły kod złym.

Wreszcie, chociaż nic nie zastępuje praktyki, zawsze dobrym pomysłem jest ciągłe czytanie blogów / książek / tej strony, ponieważ inne osoby wskażą różne perspektywy, których możesz nie wziąć pod uwagę.

Na początek polecam te książki:

• Zwinne zasady, wzorce i praktyki w języku C # - jestem 3/4 dzięki tej książce. Jedna z głównych uwag autora i zgadzam się z tym w 100%, nie zaczynaj od rozwiązania problemu, szukając wzoru do zastosowania. Utrzymuj wszystko tak proste, jak to możliwe i przekształć kod we wzór, jeśli alternatywa zaczyna się komplikować.
• Wzory projektowe Head First - nie czytałem tej książki, aw IMO wiele serii Head First jest skierowanych specjalnie dla początkujących w tej dziedzinie. Są więc na ogół prostsze, ale słyszałem / czytałem wiele dobrych odpowiedzi od innych na temat tej książki

Projekt z przodu nigdy nie jest tak dobry, jak projekt zewnętrzny. Wystarczy przetestować, kodować i refaktoryzować. Kiedy rzeczy są brzydkie i nie jesteś pewien, jak to wyczyścić, sprawdź, czy jakiś wzór projektowy pomoże. Ćwicz to przez chwilę, a wkrótce inni programiści będą pytać, jak wymyślić takie czyste projekty.