Często spo­ty­kam się z zarzu­tem, że udziw­niam mode­le, tak­że te ana­li­tycz­ne. Chodzi o sto­so­wa­nie, mię­dzy inny­mi, wzor­ca ana­li­tycz­ne­go o wdzięcz­nej nazwie Fabryka ([[wzo­rzec pro­jek­to­wy fabry­ka abs­trak­cyj­na]] lub, zależ­nie od sytu­acji, [[wzo­rzec pro­jek­to­wy Prototyp]]).

[[Analiza dzie­dzi­ny sys­te­mu]] pole­ga mię­dzy inny­mi na ​„zro­zu­mie­niu isto­ty rze­czy”. Pierwszą rze­czą jaką da się dostrzec w ​„świe­cie” jest to, że każ­dy byt ma swo­je­go (s)twórcę. W naszym oto­cze­niu nic się samo nie robi, więc roz­są­dek naka­zy­wał by uzna­wa­nie tego fak­tu tak­że w pro­jek­tach programistycznych.Oczywiście, jeże­li uzna­je­my ten styl pro­jek­to­wa­nia, obo­wiąz­ku nie ma. Kod pro­gra­mu to abs­trak­cja, jej auto­rem jest twór­ca pro­gra­mu, więc po co, ja ana­li­tyk i pro­jek­tant, o tym piszę?

Powód jest pro­sty: każ­dy (no pra­wie) zama­wia­ją­cy ocze­ku­je, że ​„pro­gram będzie pozwa­lał na łatwe wpro­wa­dza­nie zmian i aktu­ali­za­cję w takt zacho­dzą­cych zmian w oto­cze­niu biz­ne­so­wym”. Co to oznacza?

To zna­czy, że

im bar­dziej opro­gra­mo­wa­nie – abs­trak­cja świa­ta, któ­re­go opis ono mode­lu­je i prze­twa­rza – będzie odbie­ga­ło od realiów tego świa­ta, tym trud­niej będzie utrzy­mać zgod­ność tego opro­gra­mo­wa­nia ze zmia­na­mi zacho­dzą­cy­mi wokół nas.

Pewnie wie­lu czy­tel­ni­ków, zada­jąc dostaw­cy opro­gra­mo­wa­nia pyta­nie o koszt wpro­wa­dze­nia nowych funk­cjo­na­li­ści lub mody­fi­ka­cji ist­nie­ją­cych, spo­tka­ło się z odpo­wie­dzią: ​„to będzie dużo kosz­to­wa­ło” (cza­sem wię­cej niż koszt wytwo­rze­nia sys­te­mu). To z regu­ły wła­śnie efekt tego, że model uży­ty do wytwo­rze­nia opro­gra­mo­wa­nia odbie­ga od rze­czy­wi­sto­ści, został uprosz­czo­ny lub wręcz ina­czej zre­ali­zo­wa­ny. Typowym przy­kła­dem takie­go sta­nu rze­czy jest opie­ra­nie archi­tek­tu­ry opro­gra­mo­wa­nia na fun­da­men­cie w posta­ci rela­cyj­ne­go, znor­ma­li­zo­wa­ne­go model danych. Niestety ​„świat” nie jest ​„znor­ma­li­zo­wa­ny”, nafa­sze­ro­wa­ny jest powtó­rze­nia­mi (redun­dan­cja­mi). Np. nasze dane są powie­la­ne na każ­dym rachun­ku, fak­tu­rze czy poda­niu. Każdy z tych doku­men­tów żyje wła­snym życiem, nie jest połą­czo­ny ​„sznu­recz­kiem” rela­cji z naszym dowo­dem oso­bi­stym. Oprogramowanie, jeże­li ma odwzo­ro­wy­wać nasze oto­cze­nie, powin­no zacho­wy­wać się tak samo.

Model dzie­dzi­ny nie powi­nien więc być dia­gra­mem słow­ni­ko­wym (dia­gram klas z gęsto powią­za­ny­mi kla­sa­mi nafa­sze­ro­wa­ny dzie­dzi­cze­niem i aso­cja­cja­mi). Taki dia­gram to model poję­cio­wy (poję­cia słow­ni­ko­we) nie nada­ją­cy się do imple­men­ta­cji. Wymaga jesz­cze wie­le pra­cy. Jeżeli ska­że­my na nią pro­gra­mi­stę, oso­bę któ­ra nie zna tej ​„dzie­dzi­ny”, to z dużym praw­do­po­do­bień­stwem powsta­nie ​„coś co nie koniecz­nie jest tym czymś co powin­no powstać”, i nie jest to wina tego pro­gra­mi­sty tyl­ko tego, któ­ry mu dał opis tego co ma powstać w takiej wła­śnie, nie­zde­fi­nio­wa­nej postaci.

W naszej rze­czy­wi­sto­ści prak­tycz­nie zawsze ​„wszyst­ko ma swo­je źró­dło”, jest to z regu­ły ​„jed­no źró­dło” sta­nu rze­czy. W związ­ku z tym podob­nie powin­no to wyglą­dać w opro­gra­mo­wa­niu (model dzie­dzi­ny) i tu poja­wia się ​„zasa­da poje­dyn­czej odpo­wie­dzial­no­ści”, któ­rą war­to sto­so­wać tak­że w pro­jek­to­wa­niu oprogramowania.

Czemu o tym tu piszę? Bo w zasa­dzie wynik ana­li­zy biz­ne­so­wej to opis tego ​„jak ten świat u klien­ta funk­cjo­nu­je” i im wier­niej go odwzo­ru­je­my i opi­sze­my, tym więk­sza szan­sa, że powsta­nie ​„dobre opro­gra­mo­wa­nie”. Poniżej kil­ka słów na ten temat z per­spek­ty­wy pro­gra­mi­sty, czyż to nie (pra­wie) to samo?

Wczoraj mówi­li­śmy o sin­gle respon­si­bi­li­ty prin­ci­ple (SRP) czy­li o zasa­dzie poje­dyn­czej odpo­wie­dzial­no­ści. Jest to zasa­da, któ­ra moim zda­niem naj­wię­cej zmie­nia w dotych­cza­so­wych przy­zwy­cza­je­niach pro­gra­mi­stycz­nych. Na począt­ku jest tro­chę męczą­ca ponie­waż zgod­nie z nią w kla­sie nie powin­ni­śmy two­rzyć innych obiektów.

Jak to? Nie mogę uży­wać sło­wa klu­czo­we­go new? Nie mogę two­rzyć obiektów?

No wła­ści­wie to nie. Jeżeli chcesz w kla­sie two­rzyć obiek­ty to to już jest odpo­wie­dzial­ność. Wiec kla­sa nic poza two­rze­niem obiek­tów nie powin­na robić. Ale prze­cież kla­sa któ­ra nie robi nic poza two­rze­niem obiek­tów to fabry­ka. Wszystko jak naj­bar­dziej się zga­dza. Fabryka ? wzo­rzec kre­acyj­ny (hm? a może zna­cie jakieś bar­dziej odpo­wied­nie sło­wo) gan­gu czte­rech. (za Single Responsibility Principle ? ciąg dal­szy | @rek onli­ne | Arkadiusz Benedykt).

Tak więc sza­now­ni klien­ci: spraw­dzaj­cie co Wam dają ana­li­ty­cy, jeże­li model dzie­dzi­ny sys­te­mu jest dla Was total­nie nie zro­zu­mia­ły (to co mówi lub refe­ru­je ana­li­tyk), to praw­do­po­dob­nie jest to zły model…

Tak więc model dzie­dzi­ny opi­su­ją­cy sprze­daż, powi­nien zawie­rać obiekt biz­ne­so­wy Faktura ale obiekt ten nie powi­nien mieć ope­ra­cji ​„nowa fak­tu­ra”, model powi­nien zawie­rać odręb­ny obiekt np. NarzędzieFakturzysty, mają­cy ​„w sobie” wie­dzę o tym jak się wysta­wia fak­tu­ry. Powody są dwa: tech­nicz­ny opi­sał powy­żej kole­ga pro­gra­mi­sta, dru­gi powód jest bar­dzo pro­za­icz­ny: bo fak­tu­ry same się nigdzie nie wysta­wia­ją… Wnikliwym, pole­cam pozna­nie sty­lu pro­jek­to­wa­nia o wdzięcz­nej nazwie [[Domain Driven Design]].

Polecam tak­że arty­kuł: Czym jest to co modelujesz…