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).

Zanim jed­nak wczy­ta­cie się Państwo z deta­le, pole­cam krót­ki refe­rat Martina Fowlera z 2015 roku:

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 (patrz tak­że arty­kuł Znaczenie na cykl życia…) 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 zale­ca­ne jest zastę­po­wa­ne go sto­so­wa­niem sza­blo­nów lub po pro­stu rezy­gnu­je się z tej tech­ni­ki na rzecz typów danych i kompozycji.

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… 

A architekturze

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

OOP i OOAD czyli co dalej?

[2023 – 01-07]

Od wie­lu lat obser­wu­ję rynek i pro­jek­ty z zakre­su inży­nie­rii opro­gra­mo­wa­nia. Pojęcia OOP (pro­gra­mo­wa­nie obiek­to­we) oraz OOAD (ana­li­za obiek­to­wa i pro­jek­to­wa­nie) odda­la­ją się od sie­bie. Techniki orga­ni­za­cji kodu rodem z C++/Java (mają współ­ny rodo­wód) zde­ter­mi­no­wa­ły poj­mo­wa­nie poję­cia ​„pro­gra­mo­wa­nia obiek­to­we­go”. Są to cięż­kie meto­dy pra­cy, opar­te na sta­rych wodo­spa­do­wych zało­że­niach (mono­li­tycz­na archi­tek­tu­ra opar­ta na rela­cyj­nym mode­lu danych) spraw­dza­ją się tam, gdzie zmien­ność wyma­gań jest mała. 

C++ znaj­du­je zasto­so­wa­nie w two­rze­niu sys­te­mów ope­ra­cyj­nych (np. Windows XP czy Vista), a tak­że pod­czas budo­wy apli­ka­cji desk­to­po­wych (pakie­tu Office bądź pro­duk­tów Adobe). Z wyko­rzy­sta­niem C++ moż­na spo­tkać się tak­że pod­czas budo­wy baz danych oraz ser­we­rów. Popularność C++ zde­cy­do­wa­nie nie słab­nie wśród twór­ców gier. Sprawdza się świet­nie nie tyl­ko pod­czas pro­duk­cji pro­stych pro­jek­tów 2D, ale tak­że gier typu AAA.

Język Java sto­su­je się przede wszyst­kim w bac­ken­do­wej czę­ści budo­wy inter­ne­to­wych apli­ka­cji. Wykorzystuje się go tak­że w pro­jek­to­wa­niu apli­ka­cji desk­to­po­wych, kor­po­ra­cyj­nych, a nawet całych ser­we­rów apli­ka­cji. Język Java sta­no­wi pod­sta­wę dzia­ła­nia apli­ka­cji mobil­nych oraz gier dla sys­te­mu Android. Java sto­so­wa­na jest tak­że w sys­te­mach ban­ko­wych i giełdowych.

źr.: https://​wor​k4​.dev/​b​l​o​g​/​2​8​/​C​z​y​-​C​-​i​-​J​a​v​a​-​s​a​-​d​o​-​s​i​e​b​i​e​-​p​o​d​o​b​n​e​.​h​tml

Systemy okre­śla­ne jako ​„biz­ne­so­we” to zupeł­nie inna kla­sa opro­gra­mo­wa­nia, to apli­ka­cje budo­wa­ne w opar­ciu o regu­ły biz­ne­so­we i odręb­ne doku­men­ty. Jedne i dru­gie szyb­ko sią zmie­nia­ją, sto­so­wa­niu tu metod i narzę­dzi ade­kwat­nych do budo­wy gier i sys­te­mów ope­ra­cyj­nych (one się zmie­nia­ją rzad­ko i nie słu­żą do zarzą­dza­nia dany­mi) pro­wa­dzi to do powsta­wa­nia bar­dzo kosz­tow­nych w utrzy­ma­niu i roz­wo­ju sys­te­mów. Dlatego rów­no­le­gle roz­wi­ja­ją się takie języ­ki jak JavaScript, Ruby, PHP, Pyton, HTML czy Perl.

Analiza i pro­jek­to­wa­nie ​„obiek­to­we”, pier­wot­nie opar­te na idei her­me­ty­za­cji, luź­nych powią­za­niach i inter­fej­sach, tak na praw­dę spro­wa­dza się do poprze­dza­nia kodo­wa­nia pro­jek­to­wa­niem archi­tek­tu­ry, a to ​„tyl­ko” kom­po­nen­ty i ich współ­pra­ca, bez wni­ka­nia w tech­no­lo­gie ich powsta­nia, tym bar­dziej, że wie­le z nich (kom­po­nen­ty) moż­na kupić jako COTS (ang. Commercial off-the-shelf, goto­we kom­po­nen­ty z pół­ki) bez wie­dzy o ich wewnętrz­nej struk­tu­rze (czy­li hermetyzacja).

Developerzy czę­sto posłu­gu­ją sie poję­ciem kla­sy mając na myśli kon­struk­cje zna­ne im z C++ czy Java. Poniekąd słusz­nie, bo fak­tycz­nie ich uży­wa­ją two­rząc imple­men­ta­cją (pisząc kod). Na eta­pie ana­liz i pro­jek­to­wa­nia deta­le kodu nie mają zna­cze­nia, liczy się reali­zo­wa­na logi­ka i architektura. 

A gdzie tu UML? Mityczne gene­ro­wa­nie kodu z UML nie wyszło poza mury aka­de­mic­kich entu­zja­stów tego pomy­słu. Więc gdzie? Po oczysz­cze­niu z nad­mia­ru (reduk­cja UML), jest to dosko­na­łe narzę­dzie do mode­lo­wa­nia sys­te­mów i two­rze­nia sfor­ma­li­zo­wa­nych sche­ma­tów blo­ko­wych. Czym jest kla­sa w UML? Wszystkim, a to co jest kla­są w C++/Java to malut­ka część tego ​„wszyst­kie­go”. Czy na eta­pie pro­jek­to­wa­nia (model PIM) mamy na myśli kla­sy w rozu­mie­niu kon­struk­cji kodu C++/Java? Nie, na tym eta­pie mamy kom­po­nen­ty (ale w UML wszyst­ko jest kla­są, kom­po­nent też), w zasa­dzie czar­ne skrzyn­ki z inter­fej­sa­mi, któ­re trze­ba (wystar­czy) opi­sać. To co opi­sze pro­jek­tant zale­ży od nie­go: tam gdzie uzna, że daje swo­bo­dę dewe­lo­pe­ro­wi poprze­sta­nie na kom­po­nen­tach, ich inter­fej­sach i pro­ce­du­rach (algo­ryt­mach) reali­zo­wa­nych przez te kom­po­nen­ty. Tam gdzie uzna, że to waż­ne, narzu­ca wybra­ne szcze­gó­ły (patrz Kto jest pro­gra­mi­stą).

Dlatego od bar­dzo daw­na (patrz opi­sy­wa­na wyżej książ­ka) mówi się i pisze, że pro­jek­to­wa­nie sys­te­mów to wła­śnie pro­jek­to­wa­nie zorien­to­wa­ne na kom­po­nen­ty i ich inter­fej­sy. Implementacja jest zawsze wtór­na. A to co moż­na nadal spo­tkać w wie­lu pod­ręcz­ni­kach i ana­li­zach pod nazwą ​„dia­gram klas”, to czę­sto popraw­ne i zara­zem bez­war­to­ścio­we dia­gra­my w UML (Patrz UML dla pro­gra­mi­stów Java).

Na zakoń­cze­nie cie­ka­wa pre­zen­ta­cja: naj­pierw pro­jek­to­wa­nie, kod na końcu. 

Źródła