eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingJaki wzorzec projektowy: pilnowanie cyklu życia innego obiektu ?Jaki wzorzec projektowy: pilnowanie cyklu życia innego obiektu ?
  • Data: 2012-03-16 09:39:17
    Temat: Jaki wzorzec projektowy: pilnowanie cyklu życia innego obiektu ?
    Od: zażółcony <r...@c...pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    Najbardziej mi tu pasuje Proxy, ale Proxy jest zbyt ogólny.
    Może macie inny pomysł.

    Sytuacja jest taka: mamy język programowania,
    w którym destruktory są wywoływane w ściśle określonych
    momentach, tzn. mamy np. C++ bez garbage collectora
    lub np. FoxPro.

    Wykorzystujemy destruktory obiektów do tego, by
    obiekty sprzątały po sobie. Np. mamy obiekt File, który
    w destruktorze robi closa na deskryptorze otwartego pliku.
    Albo mamy obiekt Transakcja, który w destruktorze stara
    się zrobić commit'a. Albo mamy obiekt BlokadaZasobu czy
    Mutex, który w destruktorze zwalnia zablokowany
    zasób/podnosi opuszczony wcześniej semafor.

    Wykorzystujemy tu destruktory po to, by zminimalizować
    potrzebę pamiętania o sprzątaniu po obiektach, u których
    czas życia nie budzi wątpliwości (bo są np. tworzone
    lokalnie w procedurze, czy nawet zagłębionej sekcji jakiejś
    procedury(funkcji,metody), a referencja nie jest nigdzie
    przekazywana. Da się na tym budować bardzo ładny, elegancki kod,
    który w przypadku języków z garbage collectorem trzeba najczęściej
    dodatkowo obudowywać klauzulami try {}finally {...}, żeby sprzątać
    jawnie. Tu tego nie mamy, a przynajmniej mamy znacznie mniej.

    A teraz idźmy dalej: teraz chcę wszystkie w.w. obiekty plików czy
    blokad zasobów gromadzić w jakiejś kolekcji utrzymywanej i zarządzanej
    przez jakiś singleton (np. Manager Blokad, Manager Transakcji ...),
    np. po to, żeby móc je sobie wszystkie wyświetlić.
    Czyli łamię zasadę nie przekazywania/nie trzymania referencji
    obiektów na zewnątrz. Złamanie tej zasady wprost prowadzi
    do tego, że przestaje działać sprzątanie/zamykanie (ze względu
    na wiszące referencje).
    Nie mamy do dyspozycji czegoś takiego, jak weak reference, więc żeby
    temu zaradzić działamy wg. wzorca takiego:

    Lokalnie tworzymy obiekt proxy, który trzyma referencję
    na obiekt właściwy i proxy w swoim destruktorze pilnuje,
    by obiekt, którym się obiekuje "wypisać z systemu"/posprzątać
    po nim/zlikwidować wszystkie referencje.

    Pasowało mi określenie 'strażnik', ale Guard Pattern to raczej do
    walidacji się nadaje, więc nie pasuje.

    Teoretycznie każdy z obiektów typu Plik czy Semafor mógłby sam siebie
    zapisywać i wypisywać z globalnych list - ale uważam, ze czystsze jest
    rozwiązanie, kiedy tego typu obiekty nie maja za bardzo pojęcia
    kto i dlaczego się nimi interesuje, zajmują się swoimi technicznymi
    zadaniami i niczym więcej.
    Cały obowiązek pilnowania powiązań składam więc bardziej na factory
    tych obiektów, które to będą bardziej świadome, co jest w systemie
    i gdzie obiekty są zapisywane. No właśnie - z kreacją nie ma
    problemu - jest wzorzec factory. A brakuje mi tu jakiegoś wzorca
    typu 'Garbage', 'Złomuj' :)))
    Jakiegoś urzędnika, który uczestniczył w narodzinach, zapisał to
    w swoich papierach i jest bardzo zainteresowany, by zarejestrować
    również śmierć. Bez tego papiery mu się nie będą zgadzać :)

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: