7 komentářů k článku GRASP – 7– Modelové příklady:

  1. ?

    Re: GRASP – 7– Modelové příklady

    Proč v příkladu nevytváří instanci Payment objekt PaymentsHistory, když je agregátorem instancí Payment? Stejný případe je ProductCatalog – je agregátorem ProductSpecifi­cation a bere za ně odpovědnost (dohledává je podle čísla a jistě by je i vytvářel, kdyby to bylo v příkladu řešeno).
    Je nějaký důvod, proč tuto variantu při rozhodování o přidělení zodpovědnosti za vytváření instance Payment autor vůbec neuvažoval, nebo na ni prostě jen zapomněl?

    1. Mystik_7

      Re: GRASP – 7– Modelové příklady

      Přiznávám, že tuhle možnost jsem opravdu zapomněl :-)

      Podle principu Creator by instanci Payment opravdu mohl vytvářet i objekt PaymentsHistory, protože tyto objekty zaznamenává.

      Toto řešení by ale znamenalo, že inicializační data musí být předána z Register do PaymentsHistory a vzniklá instance vrácena zpátky do Register. Register by tedy pouze delegoval zodpovědnost za vytvoření Payment na PaymentsHistory.

      1. ?

        Re: GRASP – 7– Modelové příklady

        Díky za odpověď. Osobně bych to viděl spíš jako věc náhledu na PaymentHistory – pokud je to jen jakýsi log proběhlých operací, tak asi nemá smysl mu zodpovědnost za vytváření přidávat. Pokud je to ale plnohodnotný agregátor, ve kterém chci platby skladovat, dohledávat a podobně, tak by to podle mne smysl mělo.
        To mi říká jen nějaký cit nebo zkušenost. Explicitně říct, podle kterých z těch návrhových principů by se to tak určilo by mohlo být také zajímavé.
        Zřejmě by se tím (oproti vytváření přímo v Register) zvýšila soudržnost ale zároveň i zvýšila provázanost, ne?

        1. Mystik_7

          Re: GRASP – 7– Modelové příklady

          Navrhované řešení by zlepšilo soudržnost třídy Register. U Třídy PaymentsHistory by záleželo jak píšete na tom co tato třída představuje. Pokud by představovala kompletní agregátor plateb bylo by vytváření objektů plateb v souladu s ostatními zodpovědnostmi a soudržnost by tedy byla zachována. Pokud by ale představovala jen log plateb pak by po změně měla dvě už ne tolik soudržné odpovědnosti – logování plateb a vytváření plateb podle příchozích informací.

          Provázanost by se zvýšila, protože Register by byl odkázán na PaymentsHistory a nebyl by schopen zpracovat platbu bez její účasti. pokud bychom například chtěli logování zrušit nebo nahradit jiným způsobem byla by úprava obtížnější.

          Další možností by bylo použít Paymentshistory jako controller pro přijetí platby. Tj. informaci o přijaté platbě by dostal PaymentsHistory, který by vytvořil objekt Payment a pak jen zavolal Register a objekt mu předal. Tím by bylo zrušené provázání Register na PaymentsHistory. Mohlo by to ale mít negativní důsledky na okolí součásti systému.

  2. Rob

    Fakt pěkně napsaný

    Osobně zastávám názor že aplikační logika patří spíše do trigerů a uložených procedur, nicméně takhle hezky a srozumitelně napsaný článek jsem dloho nečetl. Super

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3727