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 :

Programming is not sole­ly abo­ut con­struc­ting softwa­re, pro­gram­ming is abo­ut desi­gning software.

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:

Making Architecture Matter – Martin Fowler Keynote

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

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. 

Design First APIs and Domain-Driven Design – Ljubica Lazarevic – DDD Europe 2022

Źródła

D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116. Cite
Evans, E. (2003). Domain-Driven Design. Pearson Education (US). Cite
Fowler, M. (1997). Analysis pat­terns: reu­sa­ble object models. Addison Wesley. Cite
Gamma, E. (Ed.). (1995). Design pat­terns: ele­ments of reu­sa­ble object-orien­ted softwa­re. Addison-Wesley. Cite
Martin Fowler, & Martin Fowler. (2013). bli­ki: TellDontAsk [Martinfowler​.com]. Martinfowler​.Com. https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​T​e​l​l​D​o​n​t​A​s​k​.​h​tml Cite
Ousterhout, J. K. (2018). A phi­lo­so­phy of softwa­re design (First edi­tion (v 1.0)). Yaknyam Press. Cite
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049 Cite
Pugh, K. (2006). Interface-orien­ted design. Pragmatic Bookshelf. Cite
Robert C. Martin. (2018). Czysta archi­tek­tu­ra Struktura i design opro­gra­mo­wa­nia Przewodnik dla pro­fe­sjo­na­li­stów (Wojciech Moch, Trans.). Helion SA. Cite
Steimann, F., & Mayer, P. (2005). Patterns of Interface-Based Programming. Journal of Object Technology, 4, 75 – 94. https://​doi​.org/​1​0​.​5​3​8​1​/​j​o​t​.​2​0​0​5​.​4​.​5​.a1 Cite
Wirfs-Brock, R., & McKean, A. (2006). Object Design: Roles, Responsibilities and Collaborations,. 88. Cite

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma jeden komentarz

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.