OOP - Felelősség lánc minta - Adatátadás
2010-12-01T16:45:40+01:00
2010-12-02T12:35:22+01:00
2022-07-24T21:07:26+02:00
  • Köszönöm a válaszotokat. Klorand-nak igaza van, valóban nem tartozik szorosan a mintához a kérdésem. Elnézést a félrevezetésért.

    @Paleko: Megtaláltam az idézet oldalt a könyvben is. Valóban ez egy normálisabb és rugalmasabb megoldás.

    ---

    Mostani elgondolásom(C#):

    abstract class Request { private string strType; public string getType() { ... } public string setType(string type) { ... } } class EgyikFajtaRequest : Request { ... adatok stb ... } class MasikFajtaRequest : Request { ... adatok stb ... }

    majd egy Request típusú objektumot vár a függvény. Switch-ben lekéri a típust getType-on keresztül és ha számára megfelelő akkor átcastolja a Request-et a kérdéses típusra.

    Ehhez tartozó kérdésem:

    Ha az
    EgyikFajtaRequest
    -et adom át egy függvénynek ami
    Request
    -et vár, majd ebből visszacastolom
    EgyikFajtaRequest
    -re, akkor keletkezhet kivétel?
    Mutasd a teljes hozzászólást!
  • A "Programtervezési Minták"-ból az un. KérelemObjektum-ok használata a szimpatikus nekem.

    Idézem: "A kérelmeket mondjuk egy egy Request (Kérelem) osztály képviselheti, új kérelemtípusokat pedig úgy vehetünk fel, hogy alosztályokat származtatunk ebből az osztályból. Ezek az alosztályok aztán különböző típusú paramétereket határozhatnak meg."

    A továbbiakban elmagyarázza, hogy a beérkező kérelem típusát meg kell határozni (egy switch -el), és mehet is a feldolgozás...
    Mutasd a teljes hozzászólást!
  • Az üzenet
    tárgya
    lehetne egyben az
    adat
    típusa. Ezáltal elkerülnéd az érvénytelen eseteket (adott tárgyu üzenethez nem kasztolható adat érkezik).

    A fenti gondolatot bemutatandó tekintsd a következő példát:

    if (message instanceof SomeDataType) // C# esetén az "is" a megfelelő kulcsszó { SomeDataType msg = (SomeDataType) message; // nem fog kasztolási kivételt kiváltani, tehát felesleges try-catch-be helyezni ... ... // az üzenetet feldolgozó kód helye ... } else { nextProcessor.process(message); }
    Mutasd a teljes hozzászólást!
  • A cast-olast nem fogod elkerulni ha a feldolgozo kodban kozvetlenul szukseged van az adat ertekere. A problemanak semmi koze a mintahoz...
    Mutasd a teljes hozzászólást!
  • Üdv mindenkinek.

    Felelősség lánc - angolul
    Chain of Responsibility
    mintával kapcsolatban keresnék egy általánosan használt megoldást a következő problémára: milyen módon adjak be különböző típusú adatokat a láncba.

    Tehát, például van egy ilyen lánc:

    Vezérlő_3 -> Vezérlő_2 -> Vezérlő_1

    Vagyis a Vezérlő_3 kap egy üzenetet. Ha nem neki szól akkor továbbadja Vezérlő_2 -nek. Ha neki sem, akkor Vezérlő_1-nél köt ki.

    Üzenetnek két paramétere van:
    - tárgya - ez alapján dönti el, hogy az adott vezérlőnek szól-e
    - adat - ezt dolgozza fel, ha az adott vezérlőnek szól

    A gondom az adat résszel van, mivel az lehet int/string/boolean...stb...

    ---

    Egyik ötletem, hogy az üzenet egy Object típusú paramétert vár, majd az adott vezérlő akinek szól, az átcastolja a megfelelő típusra (int/string/boolean...) majd azzal dolgozik.

    Nekem ez nem nagyon tetszik, mivel akkor kéne try-catch, hogy lekezeljem, hogy ha nem sikerül neki a castolás.

    ---

    Másik ötlet, hogy adat helyett a küldő Vezérlőt adom át (pl Vezérlő_3) majd ha megkapja a címzett (pl Vezérlő_1) akkor majd visszanyúl a küldőbe és lekéri az értéket ami kell neki.

    [szerk.:]

    Ha gondolom, viszont itt is castolni kellene.

    ---

    Fenti 2 ötlet mennyire gányolás? Van erre valami általánosan elfogadott megoldás?

    Köszönöm a válaszotokat.
    Mutasd a teljes hozzászólást!
abcd