Autor Wątek: Wzorzec projektowy  (Przeczytany 16928 razy)

Offline koirat

  • Użytkownik

# Czerwiec 27, 2012, 23:01:11
No i co z tego? Albo wypracuje swój styl, albo wcześniej czy później spotka się z dominującym stylem "pchaj klasy wszędzie".
No tyle że jak pracodawca go dopadnie to dostanie wilczy bilet, jeśli wogóle dostanie jakąś pracę ze swoimi metodami.

Swoją naukę pisania czystego kodu jeszcze odbierze. Czy to na studiach, czy z książek, czy tu z forum. Ale pisania na szybko nikt jakoś nie uczy, co jest dużym problemem.
Akurat na moich studiach odnosiłem wrażenie iż bardziej interesuje ich raczej szybkość pisania niż jakość źródła.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Czerwiec 27, 2012, 23:13:17
Cytuj
No tyle że jak pracodawca go dopadnie to dostanie wilczy bilet, jeśli wogóle dostanie jakąś pracę ze swoimi metodami.
Zanim wpadnie na pracodawcę, to go najprawdopodobniej na studiach "ustawią". A umiejętność napisania czegoś na szybko i brudno, powiem z doświadczenia, jest często bardzo przydatna. Zwłaszcza jeżeli pracujesz w R&D, to z tym "R" będzie ciężko jeżeli nie jesteś w stanie napisać czegoś na szybko.

Cytuj
Akurat na moich studiach odnosiłem wrażenie iż bardziej interesuje ich raczej szybkość pisania niż jakość źródła.
Zależy od przedmiotu, ale u mnie to na czytelność uwaga była zwracana od początku. A potem jak już weszły przedmioty OOPowe itp, to była reszta.

Offline gmpro

  • Użytkownik

# Czerwiec 27, 2012, 23:50:38
Cytuj
A umiejętność napisania czegoś na szybko i brudno, powiem z doświadczenia, jest często bardzo przydatna.
Chcesz powiedzieć, że programista przyuczony do tworzenia klas (nie mówię tu o natręctwie) nie potrafi zrobić czegoś na szybko? Ja w takich wypadkach lubię używać strukturalnego modelu :)

Jestem osobiście ciekaw opinii Xiona w tym temacie..

Offline Xion

  • Redaktor
    • xion.log

  • +1
# Czerwiec 28, 2012, 11:04:42
Cytuj
Jestem osobiście ciekaw opinii Xiona w tym temacie.
Mówisz, masz ;-)

Zasadniczo widzę że w tym wątku przewijają się dwa tematy. Jeden to tytułowe wzorce projektowe i zasadność ich użycia, a drugi to przydatność i znaczenie umiejętności pisania quick & dirty. Odniosę się do ich obu, pozwalając sobie rozbić moje dywagacje na dwa posty.



Gdy mówimy o wzorcach projektowych, przypomina mi się od razu bardzo interesująca prezentacja na ich temat którą miałem okazję wysłuchać parę miesięcy temu na PyWawie. Pokazany był tam podział wzorców na trzy grupy (nazwy mogłem pokręcić, ale liczy się idea):
  • wbudowane, będące częścią języka którego używamy
  • jawne - takie które można zamknąć w pojedynczą konstrukcję (funkcję, klasę, makro, w/e) i odwoływać się do niej przez nazwę w momencie użycia
  • niejawne - takie które wymagają zorganizowania kodu w określony sposób za każdym razem, gdy chcemy użyć danego wzorca
Biorąc na tapetę ulubiony wzorzec projektowy wszystkich polemistów OOP-u (hi Reg & Dab ;]), czyli singleton, możemy zaobserwować że:
  • w Javie jest to wzorzec niejawny, bo każde jego użycie wymaga dodania odpowiednich składników do klasy, np. metody getInstance i statycznego pola (że o trickach typu klasa wewnętrzna dla pełnego thread-safety nie wspomnę)
  • w C++ jest to wzorecz jawny, bo możliwe jest zaimplementowanie szablonu Singleton po którym możemy po prostu odziedziczyć klasę i mieć ów singleton (Szablon ten jest bodaj opisany w Perełkach #1)
  • w Pythonie jest to mechanizm wbudowany, bo każdy moduł to obiekt singletonowy
Ale wyciągając przykład z innej beczki, klasa to wzorzec wbudowany w C++, Javę i w zasadzie każdy statyczny język OO, podczas gdy we wspomnianym JavaScripcie jest on jawny, co pokazują różnego rodzaju frameworki implementujące klasyczną obiektowość w JS.

Krótko mówiąc, pojęcie wzorca jest bardzo względne a jednocześnie całkowicie wszechobecne. Wszyscy używamy wzorców przez cały czas, często o tym nie wiedząc.

Oczywiście dyskusja o wzorcach w 99% przypadków dotyczy tych niejawnych w językach OO, i najczęściej w kontekście tego czy warto używać ich czy nie. Odpowiem wybitnie zdroworozsądkowo: warto tam, gdzie ma to sens :) Najlepszym rodzajem wzorca jest ten, którego używamy nieświadomie bo jego wykorzystanie wydaje się po prostu oczywiste nawet jeśli nie mamy o tym pojęcia. Wiedza o formalnej stronie wzorców przydaje się wtedy o tyle, o ile możemy ją wykorzystać do wspomagania tej właśnie "naturalnej" intuicji, ewentualnie do komunikacji z innymi programistami. (Chociaż w to trochę wątpię; stwierdzenie "Użyłem Dekoratora" raczej nie powie mi zbyt dużo dopóki nie zobacze kodu, a już na pewno nie pozwoli na zdalne zdebugowanie ewentualnych problemów.).

Jeśli chodzi o programowanie gier, to tutaj sytuacja może być odrobinę inna w tym sensie, że w gamedevie popularne jest popełnianie większych lub mniejszych zbrodni na kodzie w imię (źle lub dobrze pojętej) wydajności :) Powiedziałbym, że owa reguła zdrowego rozsądku ma tu jeszcze większe znaczenie niż gdzie indziej, bo ze względu na natywny stopień skomplikowania zagadnienia (real time, współbieżność, matematyka, bliski kontakt ze sprzętem) każdy dodatkowy stopień komplikacji jest niepożądanym zjawiskiem.

<reklama>Przypadkowo, ostatnio blognąłem na temat pewnej użytecznej reguły projektowo-kodowej która może być dobrą odpowiedzią na dylematy z tego wątku: The Principle of Two Hacks</reklama>

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Czerwiec 28, 2012, 11:39:30
Cytuj
•w C++ jest to wzorecz jawny, bo możliwe jest zaimplementowanie szablonu Singleton po którym możemy po prostu odziedziczyć klasę i mieć ów singleton (Szablon ten jest bodaj opisany w Perełkach #1)
•w Pythonie jest to mechanizm wbudowany, bo każdy moduł to obiekt singletonowy
W C++ każdy namespace (albo nawet plik) to obiekt singletonowy i też masz mechanizm wbudowany. :)

Offline Xion

  • Redaktor
    • xion.log

  • +2
# Czerwiec 28, 2012, 11:49:59
Odnośnie znaczenia umiejętności pisania "na szybko", to prawie w całej rozciągłości zgadzam się ze stanowiskie Krzyśka: jest to bardzo przydatne. Nie jestem natomiast przekonany, że (1) jest to rzeczywiście skill który da się jakoś jednoznacznie wyodrębnić od innych (2) da się tego skilla nauczać (3) warto go nauczać. W jaki sposób punkt (3) jest niesprzeczny z tym, że uważam ową umiejętność za wartościową? Ano właśnie...

Z moich obserwacji wynika że jedną z cech charakterystycznych doświadczonych programistów jest to, że dużo rzeczy robią podobnie jak początkujący. Jedną z nich jest właśnie to, jak bardzo "na szybko" jest pisany przez nich kod. Robocza teoria genezy tego zjawiska jest mniej więcej taka:
  • Początkujący uczy się programowania pisząc jakieś proste aplikacje czy skrypty, chcąc jak najszybciej zobaczyć czy jego wspaniałe dzieł(k)o działa, więc zupełnie nie przejmuje się jakością kodu czy jego utrzymywalnością. Więcej, te pojęcia są dla niego zupełnie obce co oczywiście ma głęboki sens.
  • Po pewnym czasie nabiera większego doświadczenia i zdarza mu się wrócić do projektu po paru tygodniach czy miesiącach, ale ponieważ wciąż uczy się nowych rzeczy w zawrotnym tempie, jego reakcja jest przewidywalna: OmgWtfKtoToNapisal!... Wyciąga z tego lekcję na przyszłość, że czytelność i organizacja kodu są Bardzo Ważne (tm), i jeśli nie będzie ściśle trzymał się Najlepszych Praktyk i Wzorców Projektowych to nigdy nic większego nie skończy, a nawet jak skończy to nie będzie mógł tego później zmienić/rozbudować, a nawet jak zmieni czy rozbuduje to inni programiści się w tym nie połapią, i tak dalej.
Ponieważ ~99% początkujących (disclaimer: statystyka wzięta z powietrza) zaczyna od języków z mniejszą lub większą inklinacją obiektową, ów drugi etap jest wspomnianym przez gmpro "przyuczeniem do tworzenia klas" z dużym zamiłowaniem do abstrakcji wyrażanej obiektowymi wzorcami projektowymi.

Niektórzy zatrzymują się na tym etapie i dobrze im z tym, ale w przypadku wielu (chciałoby się powiedzieć: koderów z powołania) jest jeszcze etap trzeci:
  • Delikwent zauważa, że wyrafinowane konstrukcje służące do lepszej organizacji kodu, podniesienia jego czytelności, utrzymywalności, elastyczności itp. stają się coraz większym obciążeniem, bo zasłaniają rzeczywistą (żeby nie użyć brzydkiego słowa "biznesową") logikę. Jednocześnie - i to jest kluczowy punkt - zauważa, że kod który wcześniej uważał za nieczytelny bałagan niekoniecznie już takim się wydaje: można jednak go strawić, przeczytać, zrozumieć - ba, czasem nawet zmodyfikować i rozszerzyć. Dzieje się tak oczywiście dlatego, że w międzyczasie zdążył już zobaczyć te kilka czy kilkanaście milionów linii co wydatnie wpłynęło na jego umiejętności wzrokowego parsowania kodu.
W osiągnięciu tego etapu bardzo pomaga, wydaje mi się, programowanie w więcej niż jednym języku. Mnie na przykład z choroby nadmiernej elastyczności i over-engineeringu skutecznie wyleczył Python ze swoją prostotą i łatwością prototypowania. Ostatecznie jednak każda nowa perspektywa związana z nowym językiem może tutaj wydatnie pomóc, i nie musi to być od razu Haskell czy Lisp :)

Z tego co naprodukowałem powyżej wynika rzecz jasna punkt (1) i (2) z początku posta: ponieważ wydaje się, że istnieje istotna korelacja między ogólnym poziomem doświadczenia koderskiego a umiejętnością napisania czegoś quick & dirty (& working!), nie sądzę aby był to skill którego da się łatwo nauczyć. Trzeba po prostu więcej kodować :)

Offline Xion

  • Redaktor
    • xion.log

# Czerwiec 28, 2012, 11:52:03
W C++ każdy namespace (albo nawet plik) to obiekt singletonowy i też masz mechanizm wbudowany. :)
Ale (z tego co wiem) nie da się odwoływać do namespace'a albo pliku jako pojedynczego obiektu który da się np. gdzieś przekazać, albo zamockować do testów (w zakresie na ile w ogóle w danym języku da się mockować singletony).

Offline bies

  • Użytkownik

# Czerwiec 28, 2012, 11:53:49
Widzę, że ustawiacie w opozycji pisanie szybko oraz poprawnie (w sensie projektu). Co oznacza tylko (przynajmniej tak to wygląda z mojej perspektywy), że rzadko piszecie poprawnie i dobry projekt jawi się jako dwa tygodnie myślenia nad strukturą klas. Tymczasem pisanie poprawnie powinno być szybsze niż ,,quick & dirty'' (bo ,,dirty'' daje narzut na każdą linię kodu).

Inna sprawa to ,,quick & dirty'' poprawki w kodzie produkcyjnym. Tu dochodzi proces zarządzania zmianą. Ale skoro wątek jest o amatorskich projektach to kodu produkcyjnego w nim nie ma. A poza tym gry to produkt o bardzo obniżonych standardach jakości (vide fuckup ze startem D3).
« Ostatnia zmiana: Czerwiec 28, 2012, 12:44:19 wysłana przez bies »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

  • +1
# Czerwiec 28, 2012, 12:02:17
Cytuj
Ale (z tego co wiem) nie da się odwoływać do namespace'a albo pliku jako pojedynczego obiektu który da się np. gdzieś przekazać, albo zamockować do testów (w zakresie na ile w ogóle w danym języku da się mockować singletony).
Powiedz mi tylko jaki jest sens przekazywania gdziekolwiek singletona, skoro może on być tylko jeden?

Offline Xion

  • Redaktor
    • xion.log

# Czerwiec 28, 2012, 12:14:55
Powiedz mi tylko jaki jest sens przekazywania gdziekolwiek singletona, skoro może on być tylko jeden?
Nie wszyscy muszą wiedzieć, że jest on tylko jeden. Mogę się mylić - bo singletona chyba każdy rozumie inaczej - ale cała idea tego patternu to właśnie fakt, że mimo wszystko mamy konkretny obiekt, a nie zbiór zmiennych globalnych.

Offline Xion

  • Redaktor
    • xion.log

# Czerwiec 28, 2012, 12:17:14
Cytuj
Co oznacza tylko (przynajmniej tak to wygląda z mojej perspektywy), że rzadko piszecie poprawnie i dobry projekt jawi się jako dwa tygodnie myślenia nad strukturą klas.
Używałem terminu quick & dirty bo podchwyciłem go od Krzyśka, ale patrząc z tego punktu widzenia pewnie bardziej neutralne będzie mówienie o podejściu "just code it". To właśnie miałem na myśli, tj. całkowitą opozycję w stosunku do owych dwóch tygodni myślenia nad diagramem klas.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Czerwiec 28, 2012, 12:29:24
Cytuj
Nie wszyscy muszą wiedzieć, że jest on tylko jeden.
Przekazując ten obiekt gdzieś kod w miejscu docelowym żeby tego użyć musi wiedzieć co to jest i do czego (chociaż fakt, można przypadki sobie wyobrazić).

Cytuj
Mogę się mylić - bo singletona chyba każdy rozumie inaczej - ale cała idea tego patternu to właśnie fakt, że mimo wszystko mamy konkretny obiekt, a nie zbiór zmiennych globalnych.
Ładnie ogarnięty zbiór zmiennych globalnych też możesz nazwać obiektem. Tyle że nie jest to klasa (ale nie musi być).

Cytuj
Używałem terminu quick & dirty bo podchwyciłem go od Krzyśka, ale patrząc z tego punktu widzenia pewnie bardziej neutralne będzie mówienie o podejściu "just code it".
Nie no - w żadnym wypadku "quick & dirty" w moim rozumieniu nie wymaga od kodera zrealizowania tej drugiej części. Wymagane jest tylko "quick". ;)

Offline koirat

  • Użytkownik

# Czerwiec 28, 2012, 13:02:19
Powiedz mi tylko jaki jest sens przekazywania gdziekolwiek singletona, skoro może on być tylko jeden?
Jest sens przekazywania singeltona, dlatego często robi się go w ten sposób.
Singelton.Instance

Przykładowo możemy mieć więcej niż jedną przestrzeń adresową w aplikacji co spowoduje powstanie więcej niż jednego singeltona.

W środowisku webowym często korzystamy z singeltonów o zasięgu thread, request,session.
Dzięki uprzednio przedstawionej konstrukcji mamy możliwość przekazania singeltona jako argument.
« Ostatnia zmiana: Czerwiec 28, 2012, 13:03:56 wysłana przez koirat »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Czerwiec 28, 2012, 13:11:53
Cytuj
Przykładowo możemy mieć więcej niż jedną przestrzeń adresową w aplikacji co spowoduje powstanie więcej niż jednego singeltona.
Wtedy nie jest on już singletonem, tylko mniej więcej normalnym obiektem.

Cytuj
W środowisku webowym często korzystamy z singeltonów o zasięgu thread, request,session.
Z takim podejściem to zaraz każda klasa będzie dla Ciebie singletonem. ;)

Offline menajev

  • Użytkownik
    • Karate Inowrocław

  • +2
# Czerwiec 28, 2012, 13:23:57
Powiedz mi tylko jaki jest sens przekazywania gdziekolwiek singletona, skoro może on być tylko jeden?
Hindusi się takimi rzeczami nie przejmują. ;D