Swego cza­su pisa­łem o tym, że np. kla­sa prze­cho­wu­ją­ca infor­ma­cje o pra­cow­ni­ku raczej powin­na nazy­wać się DaneOPracowniku a nie Pracownik. Dlaczego? Bo pro­jekt sys­te­mu zawie­ra­ją­cy infor­ma­cje o pra­cow­ni­kach i klien­tach, a tak­że treść wie­lu doku­men­tów, powi­nien pozwa­lać zro­zu­mieć co jest w sys­te­mie” a co w rze­czy­wi­sto­ści” (pra­cow­nik jest żywym orga­ni­zmem, opro­gra­mo­wa­nie co naj­wy­żej zarzą­dza dany­mi opi­su­ją­cy­mi tego pracownika).

Ku moje­mu zasko­cze­niu ale tak­że rado­ści, nie­mal­że ten sam pro­blem poru­szył Ron Ross (blo­ger i autor książ­ki BUILDING BUSINESS SOLUTIONS: Business Analysis with Business Rules):

To make a long sto­ry short, busi­ness models talk direc­tly abo­ut real-world things (as busi­ness people do); sys­tems models talk abo­ut sur­ro­ga­tes for real-world things (as sys­tem desi­gners do). Not the same thing! (za Business Model vs. System Model: eCommerce ? Ron Ross on Business Rules).

W uprosz­cze­niu: model biz­ne­so­wy opi­su­je real­ny świat, model sys­te­mu (opro­gra­mo­wa­nia) opi­su­je jego [[suro­gat]]. Warto o tym nie zapo­mi­nać. Podobne podej­ście pre­zen­to­wa­ne jest przez auto­rów książ­ki: Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approach). Tu poja­wia się meta­fo­ra opi­su­ją­ca opro­gra­mo­wa­nie (sys­tem) jako narzę­dzia i mate­ria­ły”. Tu tak­że wewnątrz sys­te­mu nie ma Pracownika a jedy­nie jego Kartoteka.

Warto jed­nak pamię­tać, ze w sys­te­mach biz­ne­so­wych np. doku­ment ma (może mieć) wer­sje papie­ro­wą i elek­tro­nicz­ną. W przy­pad­ku owe­go pra­cow­ni­ka już nie, pra­cow­nik (jak każ­dy czło­wiek) ma tyl­ko wer­sję żywą” (pomi­ja­my tu kwe­stie gier kom­pu­te­ro­wych, któ­re tak­że są opro­gra­mo­wa­niem). Tak więc sys­tem zapew­ne ma w sobie” np. fak­tu­rę czy umo­wę ale na pew­no nie pra­cow­ni­ka czy klienta.

Szybkie pod­su­mo­wa­nie

Każdy model opro­gra­mo­wa­nia, a spe­cy­fi­ka­cja wyma­gań jest tak­że takim mode­lem, powi­nien być opa­trzo­ny jego kon­tek­stem i prag­ma­ty­ką. Przede wszyst­kim sys­te­my biz­ne­so­we to nie gry kom­pu­te­ro­we, tu mamy (sys­tem prze­twa­rza) doku­men­ty, dano o czymś lub kimś, ale nie ludzi, nie pojazdy.

Zaniedbanie tej pozor­nie bła­hej róż­ni­cy (kła­nia się [[semio­ty­ka i teo­ria komu­ni­ka­cji]]) pro­wa­dzi to dużych nie­po­ro­zu­mień, a nie raz do wręcz beł­ko­tli­wej tre­ści w rodza­ju: sys­tem ma pozwa­lać na usu­wa­nie pra­cow­ni­ków z poszcze­gól­nych wydzia­łów fir­my. Nie! Co naj­wy­żej sys­tem powi­nien pozwa­lać na two­rze­nie nowych zakre­sów obo­wiąz­ków lub umów o pra­cę na pod­sta­wie wzo­rów umów lub tre­ści umów poprzed­nio zawar­tych (plus wzo­ry lub mode­le tych dokumentów).

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.

Ten post ma 6 komentarzy

  1. Tomasz Nazar

    OK.

    ..Ale roz­róż­nij­my repre­zen­ta­cję oso­by pra­cow­ni­ka, od jego danych. Dane pra­cow­ni­ka moż­na sobie trzy­mac w obiek­tach Kartoteka. Nawet nie on je bedzie posia­dal, ale moze Kierownik depar­ta­men­tu, w któ­rym pra­cu­je Pracownik. A nawet nie Kierownik, a jego SzafaZKartotekami.

    Ale, byt Pracownik jak naj­bar­dziej ma sens. Przecież tu jest zde­fi­nio­wa­ne jego zacho­wa­nie (część jedy­nie z real world, ale jednak).
    Pracownik.pijeKaweRano().. prze­ciez nie KartotekaPracownika.pijeKaweRano()

    Może to być jakieś mini­mum odzwier­cie­dla­ją­ce real world busi­ness model, ale być musi. 

    Również Pracownik korzy­sta­ja­cy z sys­te­mu infor­ma­tycz­ne­go, prze­by­wa w danym momen­cie w jakiejś jego czę­ści. Coś robi, prze­cho­dzi po dzia­łach, zle­ca wyko­na­nie akcji. 

    Pracownik lubi inne­go Pracownika. Nawiazują się mię­dzy nimi róż­ne relacje.

    Ma sens odzwier­cie­dle­nie 1:1 real world => sys­tem objects. Nie widzę prze­szkód, aby model biz­ne­so­wy zaim­ple­men­to­wać w sys­te­mie odzwier­cie­dla­jąc 1:1 obiek­ty biz­ne­so­we na systemowe.

    Nic nas rów­nież nie zwal­nia z dzie­le­nie sys­te­mu wg odpo­wie­dzial­no­ści (aka SRP). Jeśli dane pra­cow­ni­ka zasłu­gu­ją na oddziel­ny byt, to jak najbardziej.

    Przejrzałem źró­dło­wy blog. W zasa­dzie dużo z tego nie wyni­ka, oprócz jasno okre­ślo­nych defi­ni­cji business/system. Z tego z pew­no­ścią nie moż­na wysu­nąć wnio­sków, że nie ma Pracownika 😉

    1. Jarek Żeliński

      Ogólnie jest to przy­kład myle­nia Modeli Dziedziny sys­te­mu z mode­lem jakiejś rze­czy­wi­sto­ści”. Dodam pyta­nie: co mode­lu­je­my pro­jek­tu­jąc oprogramowanie?

      Cytuję: Ale, byt Pracownik jak naj­bar­dziej ma sens. Przecież tu jest zde­fi­nio­wa­ne jego zacho­wa­nie (część jedy­nie z real world, ale jednak).
      Pracownik.pijeKaweRano().. prze­ciez nie KartotekaPracownika.pijeKaweRano()”

      Ok, ale o jaki model cho­dzi? O obiek­to­wy model jakiejś rze­czy­wi­sto­ści? Wtedy owszem, ma sens Pracownik.pijeKaweRano(). Ale jeże­li pro­jek­tu­je­my np. sys­tem HR to taki ele­ment kom­plet­nie nie ma sen­su, z powo­dów chy­ba oczy­wi­stych: sys­tem HR to nie gra kom­pu­te­ro­wa o nazwie Moja Korporacja” a System mają­cy zastą­pić papie­ro­we meto­dy doku­men­to­wa­nia danych o pra­cow­ni­ku, więc Pracownik Pije kawę, ale w swo­im poko­ju. System HR co naj­wy­żej zawie­ra dane o tym pra­cow­ni­ku (w tym np. numer tego poko­ju) ale System HR nie słu­ży do gra­ficz­ne­go zobra­zo­wa­nia na ekra­nie fak­tu picia kawy przez tegoż pracownika. 

      Nie widzę prze­szkód, aby model biz­ne­so­wy zaim­ple­men­to­wać w sys­te­mie odzwier­cie­dla­jąc 1:1 obiek­ty biz­ne­so­we na sys­te­mo­we.” A ja widzę, bo sys­tem biz­ne­so­wy to nie gra kom­pu­te­ro­wa. Druga waż­na uwa­ga: model biz­ne­so­wy i model dzie­dzi­ny to zupeł­nie odręb­ne poję­cia. Model biz­ne­so­wy opi­su­je to co robi fir­ma (w tym jej pra­cow­ni­cy a raczej role jakie peł­nią bo nie obcho­dzi mnie kon­kret­ny Kowalski a co naj­wy­żej to co robi Dyrektor Handlowy”. Model Dziedziny Systemu to model tego co System ma zastą­pić, w koń­cu to nowe narzę­dzie pra­cy, czy­li Model Dziedziny to model narzę­dzia jakie­go uży­je Aktor. 

      Wskazałem na ten blog, bo poru­szył waż­ną kwe­stię zaś mój post to nie tłu­ma­cze­nie czy inter­pre­ta­cja tego wpi­su a moje wnio­ski i doświad­cze­nie. Moim zda­niem wie­le szkód w pro­jek­tach pro­gra­mi­stycz­nych przy­no­si myle­nie (może nawet mie­sza­nie) stron: świat akto­rów (poza Systemem) i świat sys­te­mu (to czym jest System). Bardzo przy­dat­ny dia­gram przy­pad­ków uży­cia ma magicz­ny i naj­waż­niej­szy chy­ba ele­ment: pro­sto­kąt System. Tak więc co, jaką kla­sę, będzie zawie­rał System: Pracownik czy KartotekaPracownika? Pracownik to Aktor Systemu, jest poza nim (bo to aktor), System zawie­ra ele­men­ty prze­twa­rza­ne (sko­ro Pracownik jest Aktorem to nie jest Obiektem w Systemie, to zasa­da wyłą­czo­ne­go środ­ka dla prze­strze­ni pojęciowych).

      Bo tak na praw­dę: co ma zro­bić pro­gra­mi­sta współ­two­rzą­cy System HR z kla­są i ope­ra­cją: Pracownik.pijeKaweRano()”?

  2. Tomasz Nazar

    Hmm.. wie­le nie­pra­wi­dlo­sci, wie­le… chy­ba ktoś musi wró­cić do real­ne­go pro­jek­to­wa­nia i reali­za­cji (imple­men­ta­cji) mode­lów ze świa­ta rzeczywistego 🙂

    a) oczy­wi­ście, że obiekty/klasy. A co inne­go? To pasu­je naj­bar­dziej do odzwier­cie­dle­nia świa­ta, acz i tak ułom­ne w jego odzworowaniu. 

    b) nie wiem czym sys­te­my HR się cha­rak­te­ry­zu­ją, ale jak naj­bar­dziej jeśli prze­twa­rza­ją dane ludzi i ich doświad­cze­nie zawo­do­we, prze­szłych pra­co­daw­ców, ich hob­by, to wszyst­kie te mode­le ze świa­ta biz­ne­so­we­go mają 1:1 odpo­wied­nik w mode­lu sys­te­mo­wym (kla­sach dane­go języ­ka programowania).
    To czy ktoś, gdzieś, u kogoś pra­co­wał programuje/projektuje się naj­zwy­czaj­niej i naj­nor­mal­niej two­rząc te (Pracodawca, Osoba, Stanowisko) kla­sy, te usecase’y ..

    c) To, że sys­tem HR pre­zen­tu­je się wido­ko­wo” jako sys­tem zarzą­dza­nia doku­men­ta­mi (tak?), w niczym nie prze­szka­dza. To tyl­ko war­stwa pre­zen­ta­cji dla osób obsłu­gu­ją­cych sys­tem. To tyl­ko to, co wyplu­wa drukarka.
    Ale aby to zapre­zen­to­wać, koniecz­ne jest 1:1 zapro­jek­to­wa­nie sys­te­mu _wewnątrz_, tak jak dzia­ła i wyglą­da biz­nes. Inaczej się nie da.

    Skrótów i uprosz­czeń robić nie wol­no i nie ma sensu.

    d) A co złe­go jest w grze kom­pu­te­ro­wej? Może dalej za bar­dzo sku­piasz się na pre­zen­ta­cji? Tam rów­nież jest jakis model biz­ne­so­wy zapro­jek­to­wa­ny (infan­tyl­ny, ale jakiś)

    e) rela­cja mię­dzy Janem Kowalskim, któ­ry jest Dyrektorem Handlowym, jest oczy­wi­sta, i oba mają byt w świe­cie rze­czy­wi­stym, jak i w systemie

    f) jeśli zało­ży­my, że nie mogę imple­men­to­wać jakoś” p.wypijKawę(), bo wla­nie wody do moni­to­ra zwią­że się z przy­kro­ścią wizy­ty co naj­mniej inspek­to­ra BHP, to rów­nież nie mogę i Pracownik i Osoba – bo to nie smer­fy i się na dysk twar­dy nie zmieszczą.
    Ale to bez sensu.

    Przy takim ogra­ni­cze­niu, zosta­ją nam fak­tycz­nie BitoweKartotekiWRamieLubDyskuOOsobie… ojej! Wyjeżdżam stąd pierw­szym autobusem

    🙂

    I na koniec odpo­wiedź na pyta­nie: mode­lu­je­my świat real­ny. Robimy to pro­gra­mu­jąc, bo takie nam Bóg dał narzę­dzia, a nie inne.
    Ułomności nie­umie­jęt­no­ści zro­bie­nia tego może­my odło­żyć na bok i zało­żyć, że się da to zrobić.

    Jak już czy­tać, to http://​www​.lean​so​ftwa​re​ar​chi​tec​tu​re​.com/ Copliena

    1. Jarek Żeliński

      a. kon­kret­ne opro­gra­mo­wa­nie, jako narzę­dzie pra­cy, odwzo­ro­wu­je narzę­dzie pra­cy a nie jego użyt­kow­ni­ka bo ten może być być tyl­ko po jed­nej stro­nie monitora…
      b. sys­te­my HR cha­rak­te­ry­zu­ją się tym, że poma­ga­ją w pro­wa­dze­niu spraw kadro­wych, inny­mi sło­wy zastę­pu­ją papie­ro­wą doku­men­ta­cję (jej część) i auto­ma­ty­zu­ją np. nali­cza­nie wyna­gro­dze­nia, tak więc pyta­nie o cel pro­jek­tu brzmi: ma powstać opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie dany­mi o pra­cow­ni­kach czy pracownikami?
      c. oczy­wi­ście, że nie ma sen­su robie­nie skró­tów, ale jest coś co się nazy­wa w nie­któ­rych tech­ni­kach pro­jek­to­wa­nia boun­ded con­text” (DDD), dla sys­te­mu HR nie mode­lu­je­my więc całe­go świa­ta” a jedy­nie to co jest zwią­za­ne z zada­nia­mi (odpo­wie­dzial­no­ścią) tego sys­te­mu, a to nie jest uprosz­cze­nie tyl­ko selekcja.
      d. nie ma nic złe­go w grach kom­pu­te­ro­wych, po pro­tu do cze­go inne­go służą,
      e. w świe­cie real­nym jest Dyrektor Handlowy, zapew­ne jest akto­rem sys­te­mu HR, w Systemie mamy jego dane i histo­rie zatrud­nie­nia ale nie jego samego,
      f. jak wyżej.

      Obracamy się w sfe­rze pro­ble­mu jak nazwać kla­sę repre­zen­tu­ją­cą imię, nazwi­sko, datę uro­dze­nia i potra­fią­cą wyli­czyć aktu­al­ny wiek tej oso­by”, ja ją nazwę InformacjeOOsobie”, owszem moż­na ją nazwać Osoba”. W czym tkwi pro­blem? Ano orga­ni­za­cja uży­wa sło­wa Osoba w sto­sun­ku do żywych ludzi (swo­ich pra­cow­ni­ków, klien­tów itp.), po dru­gie Aktorem Systemu (jest jego użyt­kow­ni­kiem) jest tak­że Osoba. Patrząc na to z per­spek­ty­wy orga­ni­za­cji zaczy­na zacie­rać się zna­cze­nie sło­wa Osoba. Do tego wczo­raj” Pani Kadrowa uży­wa­ła na swo­im biur­ku KartotekiOsobowejPracownika” a od jutro ktoś mówi jej, że ma przed sobą Pracownika. Wdrożenie takie sta­je się dla wie­lu bene­fi­cjen­tów nowe­go opro­gra­mo­wa­ni prze­ży­ciem trau­ma­tycz­nym. Po dru­gie MUSZĄ się nauczyć nowe­go zna­cze­nia wie­lu sta­rych” pojęć, a to tyl­ko utrud­nia cały pro­ces wdro­że­nia. Nie rozu­miem co zna­czy BitoweKartotekiWRamieLubDyskuOOsobie”.

      W kwe­stii ksią­żek ja dla odmia­ny gorą­co pole­cam ści­śle obiek­to­we i bar­dzo prak­tycz­ne podej­ście w:
      – E.Evansa (DDD) – o mode­lo­wa­niu dzie­dzi­ny sys­te­mu w kon­wen­cji mode­lo­wa­nia tego co repre­zen­tu­je i prze­twa­rza dane oprogramowanie”
      – Heinz Züllighoven, Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approach – o pięk­nej meta­fo­rze two­rze­nia opro­gra­mo­wa­nia: pro­gram to narzę­dzia i mate­ria­ły” w rękach użytkownika
      – Rebecca Wirfs-Brock, Alan McKean, Projektowanie obiek­to­we. Role, odpo­wie­dzial­ność i współ­pra­ca, dosko­na­ła książ­ka o ana­li­zie obiek­to­wej i projektowaniu.
      – Fowler albo Go4, Wzorce Projektowe, wska­zów­ki roz­wią­zy­wa­nia wie­lu pro­ble­mów pro­jek­to­wych, ze szcze­gól­nym uwzględ­nie­niem wzor­ców ana­li­tycz­nych domenowych.
      – gorą­co pole­cam tak­że prze­czy­ta­nie jed­nak krót­kie­go arty­ku­łu, któ­ry cyto­wa­łem na począt­ku tego postu.

      Zapewne róż­ni­my się bar­dzo sty­lem ana­li­zy i pro­jek­to­wa­nia. Autobusów mamy wie­le, cele i dro­gi ich osią­ga­nia róż­ne… nie ma problemu 🙂

  3. Tomasz Nazar

    Ciekawe..

    To na co chcę zwró­cić uwa­gę, to, że pre­zen­ta­cja w posta­ci kartotekiPracownika dla Pani Ewy, któ­rej trau­my nikt nie chce doświad­czyć nie ma nic wspól­ne­go z tym jak mode­lu­je­my sys­tem wewnątrz.
    Ta kla­sa tyl­ko kwe­stia war­stwy prezentacji.

    Kto powie­dział, że spo­sób reali­za­cji wnętrz­no­ści sys­te­mu ma mieć wpływ na to jak pre­zen­tu­je­my to na ekranie/drukarce dla Pani Ewy.

    Mnie inte­re­su­je jak prze­no­sić świat real­ny w sys­te­mo­wy i nie widzę tu żad­nych ogra­ni­czeń wspomnianych.
    A wnętrz­no­ści sys­te­mu pro­gra­mu­je­my my, i aby to robi­ło się naj­ła­twiej, było jak naj­bli­żej real­nym wyma­ga­niom, i less bugs, i był gdzieś kod, któ­ry i oso­ba biz­ne­so­wa może łatwo przeczytać/zmodyfikować (z pomo­cą IT) – to i nazwy i obiek­ty muszą być jak naj­bar­dziej 1:1

    W moim sys­te­mie KartotekaPracownika”, to była­by jedy­nie wart­stwa pre­zen­ta­cji. A do tego, aby ja wyge­ne­ro­wać potrze­bo­wał­bym klas/obiektów: Pracownik, Osoba, Kraj (pol­ska), UrządMiasta (do trzy­ma­nia pese­li, nazwisk i imion), Czas (do trzy­ma­nia even­tów, kie­dy oso­ba się urodziła).

    Z tego wyni­ka, że u mnie nie ma potrze­by w sys­te­mie posia­da­nia kla­sy InformacjeOOsobie, jako, że jest to jedy­nie kwe­stia pre­zen­ta­cji i tyl­ko w tej war­stwie wystę­pu­je, powiedz­my jako szablon/template do gene­ro­wa­nia pli­ku html/pdf.

    Aby ją wyge­ne­ro­wać na ekran, pyta­my urządMiasta.podajPesel(osoba)”, czas.narodziny.kiedy(osoba)”, itd.. 

    Tak to wyglą­da w świe­cie rzeczywistym 🙂

    Można sobie upro­ścić, że to ja mam pesel, ale w rze­czy­wi­sto­ści ja o nim wiem przez to, że gdzieś, ktoś mi go wyge­ne­ro­wał w Urzędzie Miasta.
    Podbnie z imionami..

    I wie­le, wie­le innych atry­bu­tów, któ­re przez lata wylą­do­wa­ły w kla­sie Person, co jest oczy­wi­stym zła­ma­niem SRP, a nawet same­go RP 😉

    1. Jarek Żeliński

      Ogólnie to tyl­ko, moim zda­niem – prag­ma­ty­ka mode­lu dzie­dzi­ny. Można, nie ma zaka­zu, zbu­do­wać model dzie­dzi­ny zawie­ra­ją­cy kla­sę Osoba, rzecz w tym, że (cytat z lin­ko­wa­ne­go arty­ku­łu) jest to jed­nak tyl­ko suro­gat”, bo praw­dzi­wa Osoba jest czło­wie­kiem z krwi i kości, zapew­ne korzy­sta z tego opro­gra­mo­wa­nia… Prezentacja danych imię i nazwi­sko” na ekra­nie (poza sfor­ma­to­wa­niem) wyma­ga wywo­ła­nia ope­ra­cji JakSięNazywasz kla­sy Osoba, lub w kon­wen­cji, któ­rą pre­fe­ru­ję, wywo­ła­nie ope­ra­cji PodstawoweDaneOsoby kla­sy KartotekaPracownika. Pojęcie real world” ma sens ;), jeże­li opro­gra­mo­wa­nie HR zastę­pu­je papie­ro­wy sys­tem kadro­wy, to czym tu jest real world”? Klasą repre­zen­tu­ją­cą papie­ro­wą kar­to­te­kę, któ­ra zastę­pu­ję nowym oprogramowaniem…

      Przykład z PESEL jest OK, bo pyta­nie o PESEL mogę zadać oso­bie jak i Urzędowi, pyta­nie czy pytam o to żywe­go kowal­skie­go czy Urząd, czy klasę/komponent SystemPESEL, to samo pyta­nie moż­na zadać róż­nym bytom”. Kto ma PESEL? Ja nie, jest atry­bu­tem moje­go dowo­du oso­bi­ste­go, pomi­ja­jąc ewen­tu­al­ne zapa­mię­ta­nie go, jak ktoś zapy­ta mnie mnie o PESEL, muszę naj­pierw zapy­tać” o to mój dowód. Tyle w kwe­stii real world”. W moich pro­jek­tach nie ma klas DowódOsobisty, jest kla­sa DaneDowoduTożsamości z atry­bu­ta­mi rodzajDokumentu, numerSerii (i pew­nie inne).

      Obracamy się wokół tego jaką kon­wen­cję mode­lo­wa­nia sto­su­je­my… ja o tej, któ­rą sto­su­je (nie ja jeden) powiem, że jest inna niż Twoja, nie że lep­sza czy gor­sza… co naj­wy­żej bro­nie tezy, że real world” w opro­gra­mo­wa­niu pole­ga na tym, że opro­gra­mo­wa­nie jest narzę­dziem w rękach czło­wie­ka podob­nie jak kal­ku­la­tor, papier, ołó­wek, papie­ro­we for­mu­la­rze itp. a nie symu­la­to­rem fir­my dla któ­rej pro­jek­tu­ję opro­gra­mo­wa­nie, no chy­ba, że fak­tycz­nie ma być symu­la­to­rem ale wte­dy nazy­wa się GRA BIZNESOWA lub SYMULATOR BIZNESU. 

      SRP (o ile rozu­miem: Single Responsibility Principle) jest bar­dzo wygod­ne i pomoc­ne w pro­jek­to­wa­niu, zaś zamia­na moje­go dowo­du oso­bi­ste­go, pasz­por­tu, tecz­ki z papie­ra­mi i mojej sza­fy w poko­ju na jeden obiekt z dzie­siąt­ka­mi atry­bu­tów to wła­śnie szko­dli­we nad­mier­ne uprosz­cze­nie, któ­re o ile pamię­tam krytykowałeś.

Dodaj komentarz

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