Ugrás a tartalomhoz

General Responsibility Assignment Software Patterns

A Wikiszótárból, a nyitott szótárból


Főnév

General Responsibility Assignment Software Patterns (tsz. General Responsibility Assignment Software Patternses)

  1. (informatika) A GRASP (General Responsibility Assignment Software Patterns) egy objektum-orientált tervezési minta halmaz, amely a felelősségek helyes hozzárendelését célozza meg szoftverkomponensekhez. A GRASP segít abban, hogy moduláris, könnyen karbantartható, és újrafelhasználható szoftvert tervezzünk.


🧠 Mi a célja a GRASP mintáknak?

A GRASP célja, hogy irányelveket adjon a felelősségek logikus és jól kezelhető elosztására az osztályok és objektumok között. Ez segít a következőkben:

  • a magas kohézió és alacsony csatolás elérésében,
  • a változások hatásának lokalizálásában,
  • a kód újrafelhasználhatóságának növelésében,
  • a tesztelhetőség és karbantarthatóság javításában.


🧩 A GRASP 9 mintája

  1. Information Expert (Információ Szakértő)
  2. Creator (Létrehozó)
  3. Controller (Vezérlő)
  4. Low Coupling (Alacsony csatolás)
  5. High Cohesion (Magas kohézió)
  6. Polymorphism (Polimorfizmus)
  7. Pure Fabrication (Mesterséges osztály)
  8. Indirection (Közvetítés)
  9. Protected Variations (Védett változatok)


📘 1. Information Expert

Elv: Azt az osztályt bízzuk meg egy felelősséggel, amely rendelkezik a szükséges információval annak teljesítéséhez.

Példa: Ha a Cart osztály tartalmazza a LineItem objektumokat, akkor a Cart számolja ki az összegzett végösszeget, hiszen ő rendelkezik a szükséges adatokkal.


📘 2. Creator

Elv: Egy osztály akkor legyen felelős egy másik példányosításáért, ha:

  • tartalmazza azt (aggregation/composition),
  • azt használja,
  • azt inicializálja,
  • vagy logikailag hozzá tartozik.

Példa: A Customer hozza létre a Order objektumot, mivel az ügyfél rendelést indít.


📘 3. Controller

Elv: Egy vezérlő osztály kezelje a felhasználói eseményeket, ne a GUI elemek, és ne a modell osztályok (pl. Customer).

Példa: A SalesController vagy OrderHandler osztály dolgozza fel a „Rendelés létrehozása” parancsot.


📘 4. Low Coupling

Elv: Olyan osztályokat tervezzünk, amelyek kevés más osztálytól függnek, így a változások kevés hatással lesznek más modulokra.

Előnyök:

  • Könnyebb karbantartás
  • Jobb újrafelhasználhatóság
  • Tesztelhetőség nő


📘 5. High Cohesion

Elv: Egy osztálynak legyen egységes és fókuszált felelőssége, vagyis a metódusai logikailag összetartozzanak.

Példa: Egy InvoicePrinter csak nyomtatással foglalkozzon – ne számoljon kedvezményeket is.


📘 6. Polymorphism

Elv: Használjunk polimorfizmust a változó viselkedés elrejtésére.

Példa: Egy Shape absztrakt osztály draw() metódusát minden leszármazott (pl. Circle, Rectangle) saját módján valósítja meg.

Ez helyettesíti a sokágú if-eket, és bővíthetőbbé teszi a rendszert.


📘 7. Pure Fabrication

Elv: Ha egyetlen természetes osztály sem illik egy felelősségre, hozzunk létre egy mesterséges osztályt, amely megkapja a felelősséget – főként kohézió vagy csatolás csökkentésére.

Példa: Egy DatabaseMapper vagy FileLogger osztály, amely nem a modell része, de fontos szolgáltatást végez.


📘 8. Indirection

Elv: Helyezzünk be egy közvetítő objektumot két osztály közé, hogy csökkentsük a közvetlen csatolást.

Példa: Egy ServiceLocator vagy EventDispatcher objektum, amely egyfajta híd.


📘 9. Protected Variations

Elv: Védjük meg a változásra hajlamos komponenseket úgy, hogy absztrakciós rétegeket hozunk létre közöttük.

Példa: Egy PaymentProcessor interfészt használunk ahelyett, hogy közvetlenül PayPalProcessor vagy StripeProcessor osztályokra támaszkodnánk.


🧱 GRASP összefoglaló táblázatban

Minta Leírás röviden Előny
Information Expert Ahol az adatok vannak, ott legyen a logika is Magas kohézió
Creator Példányosítási felelősség logikusan Alacsony csatolás
Controller GUI és logika szétválasztása Kód átláthatóság
Low Coupling Kevés függés más osztályoktól Könnyű karbantartás
High Cohesion Egységesség az osztályban Jó olvashatóság
Polymorphism Dinamikus viselkedésváltás Nyitott/zárt elv
Pure Fabrication Mesterséges osztály a tisztább design érdekében Jobb struktúra
Indirection Közvetítés két modul között Modularitás nő
Protected Variations Absztrakcióval védés a változások ellen Stabil architektúra


🛠️ Használat a gyakorlatban

GRASP nem konkrét kódszintű megoldás, hanem irányelvek és design elvek. Ezeket legjobban akkor használhatjuk, ha:

  • új rendszert tervezünk, és a felelősségek helyes szétosztása kritikus,
  • refaktorálunk egy bonyolult rendszert,
  • tanítjuk vagy dokumentáljuk a szoftver szerkezetét.


🎓 Összegzés

A GRASP minták segítenek okosan szétosztani a felelősségeket a rendszer különböző komponensei között, így:

  • jobban strukturált,
  • karbantarthatóbb,
  • rugalmasabb rendszert kapunk.

Ezek az alapelvek komplementerei más tervezési mintáknak (pl. GoF design patterns), és megalapozzák a helyes objektum-orientált tervezést.


A lap eredeti címe: „https://hu.wiktionary.org/w/index.php?title=General_Responsibility_Assignment_Software_Patterns&oldid=3499727”