Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM    Subskrybuj kanał ATOM dla tagu design Kanał ATOM (tag: design)

Autor wpisu: bastard13, dodany: 26.06.2015 22:10, tagi: design, oop

o prawach i zasadach

Jakiś czas temu pisałem o Law of Demeter, o tym o co w tym właściwie chodzi oraz o plusach przestrzegania prawa :) Dzisiaj chciałbym przybliżyć Wam zasadę Tell, don’t ask, która w moim odczuciu jest punktem wyjścia do wspomnianego wcześniej prawa, przestrzeganie LoD jest jednym z następstw stosowania zasady TDA.Czytaj więcej »

Autor wpisu: bastard13, dodany: 12.05.2015 23:45, tagi: design, oop

Wszystko ma sens wtedy, gdy ma sens. Nie tworzysz kodu, którego nie potrzebujesz z kilku powodów. Po pierwsze, może się okazać, że go (o ironio!) nie będziesz potrzebował. Po drugie, dodajesz pracy sobie i innym, ponieważ ktoś musi o ten kod dbać, ktoś będzie go zapewne niejednokrotnie czytał, i tak dalej. Po trzecie, kod który jest niepotrzebny stwarza problemy ze zrozumieniem aplikacji, bo przecież „skoro ktoś to dodał, to jest potrzebne”. Nie zawsze jednak jest tak, że kod niepotrzebny nie jest nigdzie wykorzystywany. Zdarzają się sytuacje, gdy powstają metody, które co prawda są użyte, ale są jedynie elementem pewnej funkcjonalnej całości i same nie niosą nic poza potencjalnymi problemami. I o takich tworach chciałbym dzisiaj opowiedzieć.Czytaj więcej »

Autor wpisu: bastard13, dodany: 20.04.2015 22:39, tagi: design, oop

z obcymi (nie) za pan brat

Jeżeli chcielibyśmy ująć kwintesencję Prawa Demeter (Law of Demeter) w jednym zdaniu to brzmiałoby ono: "rozmawiaj tylko z (bliskimi) przyjaciółmi". W pełnej formie mówi ono o tym, że metoda danego obiektu może odwoływać się jedynie do metod należących do:
  • tego samego obiektu,
  • dowolnego parametru przekazanego do niej,
  • dowolnego obiektu przez nią stworzonego,
  • dowolnego składnika, klasy do której należy dana metoda.
Czytaj więcej »

Autor wpisu: bastard13, dodany: 06.03.2015 07:13, tagi: design, oop

Tematem Domain-Driven Design jestem zainteresowany już od dłuższego czasu, ale ostatnio częstotliwość jego występowania przy okazji developmentu znacznie się zwiększyła.Biorąc to pod uwagę zdecydowałem się na odświeżenie swojej pamięci i ponowne przewertowanie stronic Domain-Driven Design Eric’a Evansa. A skoro już to zrobiłem, to chyba warto podzielić się odczuciami i obserwacjami na temat tej lektury z Wami.Czytaj więcej »

Autor wpisu: bastard13, dodany: 25.11.2014 21:25, tagi: design

porozmawiajmy o diagramach

Zdaję sobie sprawę, że pewnie wielu z Was odrzuca na samą myśl o UML-ach, ale chcąc nie chcąc, na pewnym etapie Waszej kariery się z nimi spotkacie i możliwe, że nawet sami będziecie musieli je wykorzystać do pracy twórczej. Dlaczego tylu programistów czuje awersję do diagramów? Cóż, przypuszczam, że wynika to z pewnej niechęci do tego, czego nie znamy, w tym konkretnym przypadku – do języka, który jest nam obcy. Bo tym właśnie jest UML, językiem, który nie wszyscy rozumiemy, którym nie wszyscy mówimy. Dzisiaj jednak nie o tym. Czytaj więcej »

Autor wpisu: bastard13, dodany: 21.08.2014 01:01, tagi: design, oop

kolejna wizyta w świecie wzorców

Zapewne już trochę kodu mieliście okazję stworzyć odkąd pisałem o dekoratorze. Mam nadzieję, że przez ten czas mieliście możliwość go wypróbować i sprawdzić jak daje radę w świecie prawdziwych problemów. Następnym wzorcem, z którym spróbujemy się zmierzyć będzie wizytator.Muszę uczciwie się przyznać, że moje pierwsze z nim spotkanie, gdy wertowałem strony Wzorców Projektowych to nie była miłość od pierwszego wejrzenia i trochę czasu musiało minąć zanim w pełni doceniłem korzyści płynące z jego wykorzystania. Ale jak tak w ogóle ten wizytator wygląda? Gdzie i po co się go stosuje?Wierzę, że na te pytania uda mi się odpowiedzieć w poniższych akapitach.Czytaj więcej »

Autor wpisu: bastard13, dodany: 03.07.2014 00:23, tagi: design, oop

Zapewne już nie raz mieliście okazję przeczytać stwierdzenie, że bardzo istotne jest to, aby w kodzie do nazywania klas domenowych wykorzystywać, te (nazwy) których używa nasz klient. Wielu z Was uznaje to za oczywistość, wielu dodaje jakieś "ale", są tacy, którzy twierdzą, że przecież klient i tak nie wie czego chce, to po ci się przejmować. Oczywiście są też tacy, którzy sami się takimi "pierdołami" nie mają czasu przejmować, bo przecież "kod jest do napisania".Nie powiem, że się nie da i Wasz projekt bez takiego odwzorowania nie ma szans na powodzenie, bo to nie jest prawda. Przynajmniej nie w każdym przypadku. Są jednak projekty odpowiednio duże bądź skomplikowane, gdzie ten brak spójności potrafi zauważalnie wpłynąć na tempo produkcji kodu oraz na jego jakość. Niestety, jeżeli się "nie dogadamy", to nawet mimo naszych najszczerszych chęci i przy wykorzystaniu najlepszych technik i praktyk nie unikniemy błędów.Czytaj więcej »
Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.