Wprowadzenie

Tym razem krót­ka recen­zja pew­nej książ­ki z roku 2006, a raczej jej pole­ce­nie każ­de­mu pro­jek­tan­to­wi i archi­tek­to­wi dzi­siaj. Na koń­cu pole­cam tak­że kolej­ną now­szą pozy­cję jako uzu­peł­nie­nie. Adresatami tej recen­zji są głów­nie ana­li­ty­cy i pro­jek­tan­ci, jed­nak adre­su­ję ten wpis tak­że do deve­lo­pe­rów, zakła­dam że dla nich nie jest to ​„coś nowe­go”, ale być może mają jakieś rady dla projektantów. 

Warto tak­że pod­kre­ślić, że pomię­dzy OOP a OOAD jest coraz więk­sza róż­ni­ca i podział na role: ana­li­za i pro­jek­to­wa­nie oraz imple­men­ta­cja, a tak­że postę­pu­ją­ca sepa­ra­cja tych ról, sta­ją się stan­dar­dem w inży­nie­rii opro­gra­mo­wa­nia :

Kolejna war­ta zwró­ce­nia uwa­gi rzecz: pro­jek­to­wa­nie inte­gra­cji sys­te­mów w orga­ni­za­cji to nic inne­go model sys­te­mu zorien­to­wa­ny na inter­fej­sy (patrz wcze­śniej­szy wpis: Integracja sys­te­mów ERP jako źró­dło prze­wa­gi ryn­ko­we).

Recenzja

Interface-Ofriented Design , to książ­ka o archi­tek­tu­rze i jej pro­jek­to­wa­niu. We wstę­pie autor pisze (oryg):

Autor, na wie­lu przy­kła­dach poka­zu­je jak moż­na pro­jek­to­wać (two­rzyć) opro­gra­mo­wa­nie budu­jąc je ze współ­pra­cu­ją­cych komponentów. 

Wiele się mówi o pro­gra­mo­wa­niu obiek­to­wym a mało o pro­jek­to­wa­niu zorien­to­wa­nym na kom­po­nen­ty (modu­ły). Ważna rzecz: pro­jek­to­wa­nie zorien­to­wa­ne na inter­fej­sy kon­cen­tru­je się na kom­po­nen­tach i ich inter­fej­sach, kom­po­nen­ty te mogą, ale nie muszą, być imple­men­to­wa­ne za pomo­cą języ­ków obiek­to­wych. Projekty, któ­re sku­pia­ją się na kom­po­nen­tach i ich inter­fej­sach mają ogrom­ną zale­tę: pre­cy­zyj­nie opi­su­ją co ma pro­gram robić a jed­no­cze­śnie nie narzu­ca­ją narzę­dzia implementacji.

Kolejna rzecz to fakt, że obec­nie znacz­nie bar­dziej niż w cza­sach gdy książ­ka była pisa­na (uka­za­ła się w 2006 roku), nabie­ra zna­cze­nia roz­pro­szo­na archi­tek­tu­ra: real­nie nie ma już mono­li­tów, mamy inte­gra­cje sys­te­mów mię­dzy part­ne­ra­mi han­dlo­wy­mi, z reje­stra­mi publicz­ny­mi, mię­dzy lokal­ny­mi i chmu­ro­wy­mi infra­struk­tu­ra­mi. Rozproszone prze­twa­rza­nie to archi­tek­tu­ry zorien­to­wa­ne na usłu­gi, któ­re kła­dą szcze­gól­ny nacisk na interfejsy. 

Interfejsy mogą być zorien­to­wa­ne na pro­ce­du­ry (takie jak zdal­ne wywo­ła­nia funk­cji) lub na doku­men­ty (ser­wi­sy inter­ne­to­we i inte­gra­cje z pro­to­ko­łem RESTful API). Autor opi­su­je tak­że wzor­ce i meto­dy pro­jek­to­wa­nia bazu­ją­ce na luź­nych powią­za­niach, któ­re są klu­czo­we dla budo­wa­nia sys­te­mów roz­pro­szo­nych. Więcej o inter­fej­sach zorien­to­wa­nych na doku­men­ty w moich pro­jek­tach,

Ważna rzecz, na któ­rą autor tak­że zwra­ca szcze­gól­ną uwa­gę: dzie­dzi­cze­nie jest czę­sto trud­ną do osią­gnię­cia tech­ni­ką, jest to tak­że czę­sto jed­na z naj­bar­dziej nad­uży­wa­nych cech języ­ków obiek­to­wych. Nacisk auto­ra na inter­fej­sy może wyda­wać się nie­co eks­tre­mal­ny, jed­nak (świe­że w 2006 roku) spoj­rze­nie na pro­jek­to­wa­nie archi­tek­tu­ry zorien­to­wa­ne na kom­po­nen­ty i ich odpo­wie­dzial­ność, daje zaska­ku­ją­co dobre efek­ty, a pamię­taj­my, że gene­ral­nie liczy się cykl życia apli­ka­cji czy­li kosz­ty jej utrzy­ma­nia i roz­wo­ju, a nie samo jej wytwo­rze­nie. Warto pamię­tać, że dzie­dzi­cze­nie z zasa­dy łamie zasa­dę her­me­ty­za­cji i jest zastę­po­wa­nie sto­so­wa­niem sza­blo­nów lub po pro­stu rezy­gnu­je się z tej tech­ni­ki na rzecz agregatów. 

Podsumowując: Kluczowym prze­sła­niem auto­ra jest ​„odej­ście” od ​„pro­gra­mo­wa­nia obiek­to­we­go” (orien­ta­cja kodu na dzie­dzi­cze­nie oraz łącze­nie funk­cji i danych w obiek­ty, OOP) na rzecz ​„pro­jek­to­wa­nia zorien­to­wa­ne­go na nie­za­leż­ne, luź­no powią­za­ne kom­po­nen­ty” (poli­mor­fizm i her­me­ty­za­cja), cechu­ją­ce­go się peł­ną sepa­ra­cją kom­po­nen­tów, luź­ny­mi powią­za­nia­mi (tyl­ko wywo­ła­nia ope­ra­cji) i poje­dyn­czą odpo­wie­dzial­no­ścią (OOAD). Autor zwra­ca uwa­gę na spraw­dzo­ne wzor­ce, klu­czo­we: to fabry­ka (zwa­na tak­że meto­dą wytwór­czą, jest to sepa­ra­cja metod two­rze­nia obiek­tów od ich utrwa­la­nia), adap­ter (sepa­ra­cja współ­pra­cu­ją­cych kom­po­nen­tów o nie­do­pa­so­wa­nych inter­fej­sach). Co do zasa­dy też (wzor­ce) sepa­ru­je­my prze­twa­rza­nie danych od ich samych (wzo­rzec repo­zy­to­rium ). Dzisiaj domi­nu­ją­ce są więc mikro ser­wi­sy i mikro apli­ka­cje, nato­miast łącze­nie danych i metod je prze­twa­rza­ją­cych w jed­nej kla­sie to antywzorzec. 

Początek lat 2000 to nie tyl­ko mani­fest Agile, to tak­że już kil­ka lat po nim, nawo­ły­wa­nie sygna­ta­riu­szy Agile do porząd­ku w inży­nie­rii opro­gra­mo­wa­nia . Poza oma­wia­ną tu książ­ką poja­wi­ły się, w tam­tym okre­sie, mię­dzy inny­mi opis budo­wy kom­po­nen­to­wej archi­tek­tu­ry , opis pro­jek­to­wa­nia zorien­to­wa­ne­go na odpo­wie­dzial­ność kom­po­nen­tów .

Autor zwra­ca tak­że szcze­gól­ną uwa­gę na doku­men­to­we mode­le budo­wy inter­fej­sów i inte­gra­cji. Dokumentowe czy­li zorien­to­wa­ne na prze­ka­zy­wa­nie mię­dzy kom­po­nen­ta­mi całych agre­ga­tów danych (zwa­nych doku­men­ta­mi) zamiast wyni­ków dzia­ła­nia poszcze­gól­nych funk­cji. Znakomicie uprasz­cza to archi­tek­tu­rę, powo­du­je mniej­sze uza­leż­nie­nia, w kon­se­kwen­cji cykl życia takie­go sys­te­mu jest znacz­nie tań­szy. O tym aspek­cie archi­tek­tu­ry inte­gra­cji pisał tak­że zna­ny autor Martin Fowfer .

Zachęcam do lek­tu­ry tej książ­ki, porząd­ku­je wie­dzę, być może wie­lu z Was znaj­dzie coś nowe­go. Od sie­bie powiem, że podej­ście takie sto­su­ję od cza­sów lek­tu­ry Systemów zorien­to­wa­nych kom­po­nen­to­we Souzy, czy­li od ponad 15 lat… 

Doskonałym i aktu­al­nym uzu­peł­nie­niem tej książ­ki jest napi­sa­na póź­niej Czysta archi­tek­tu­ra :

Dobrzy archi­tek­ci ostroż­nie oddzie­la­ją szcze­gó­ły od reguł biz­ne­so­wych, robiąc to tak dokład­nie, że regu­ły te nie mają żad­nej wie­dzy o szcze­gó­łach i w żaden spo­sób od nich nie zale­żą. Dobrzy archi­tek­ci tak pro­jek­tu­ją regu­ły sys­te­mu, żeby wszyst­kie decy­zje doty­czą­ce szcze­gó­łów moż­na było podej­mo­wać tak póź­no, jak to tyl­ko możliwe.

Przy tej oka­zji pole­cam tak­że pre­zen­ta­cję opar­tą na tre­ści książ­ki , szcze­gól­nie część o inter­fej­sach, głę­bo­ko­ści i płyt­ko­ści klas: A Philosophy of Software Design | John Ousterhout | Talks at Google

Źródła