🚀 go-pugleaf

Przemek Pokrywka <adres@zastrzezony.com> writes:

> Witam! :-)
>
> Czy zdarzyło się komuś z Państwa pisać wielki komponent systemowy
> zrealizowany w postaci pojedynczego obiektu?

Jakby na to spojrzeć w odpowiedni sposób, to wszystkie programy są
takimi obiektami.

Cześć,

> Czy zdarzyło się komuś z Państwa pisać wielki komponent systemowy 
> zrealizowany w postaci pojedynczego obiektu? Nie mam tu na myśli tego, 
> że cały kod takiego komponentu jest zawarty w jednej klasie, tylko że 
> pojedyncza klasa kontroluje całą sieć powiązanych obiektów i stanowi do 
> nich swoistą fasadę wobec klientów.

Jeśli dobrze zrozumiałem, że rzecz skupia się po prostu wokół zbudowania 
fasady udostępniającej funkcjonalność skomplikowanego subsystemu, to 
przypomina mi się mój ulubiony diagram ilustrujący wzorzec Facade:
http://home.earthlink.net/~huston2/images/facade_dcd.gif ;)

> Sam jeszcze nie miałem okazji tworzyć (lub współtworzyć) tego rodzaju 
> oprogramowania, a jeden komponent systemu, nad którym pracuję wygląda mi 
> na kandydata na taki obiekt.
> 
> Ponieważ wydaje mi się, że przy pisaniu takiego obiektu trzeba zwrócić 
> szczególną uwagę na wiele aspektów możliwych do bezkarnego pominięcia w 
> innych przypadkach (użycie Singletonów?), chciałbym się Państwa poradzić 
> co do praktyk zalecanych przy rozwoju takiego oprogramowania.

Kilka luźnych uwag:
0. Kluczowa sprawa: dobrze określić odpowiedzialności schowanego 
subsystemu i prawidłowo wyznaczyć jego interfejs
1. Jeśli liczba operacji, które można wykonać na schowanym za fasadą 
subsystemie, jest spora, i mają one różny poziom złożoności, to warto 
rozważyć zbudowanie hierarchi (choćby dwupoziomowej) fasad oferujących 
interfejsy o różnym stopniu skomplikowania, z czego niekoniecznie 
wszystkie implementacje muszą być publiczne, choć mogą. Przede wszystkim 
chodzi o zbudowanie struktury, w której operacje będą mogły być 
wykonywane na coraz większym poziomie abstrakcji - wygodnym dla 
użytkownika fasady, niekoniecznie bliskim samej implementacji operacji w 
chowanym subsystemie. Co więcej, jeśli użytkowników wykorzystujących 
fasadę można zaklasyfikować do kilku ról, to dla każdej z nich można 
zbudować fasadę o różnym stopniu złożoności, co ułatwi korzystanie z 
subsystemu.
2. Jeśli ten komponent ma charakter integracyjny i używacie Java to 
warto użyć Springa jako kontenera obiektów do wygodnej manipulacji 
zależnościami i zarządzania tworzeniem obiektów w samym subsystemie 
(przede wszystkim pilnowania singletonów) - podobnie, jeśli sam 
komponent występuje w środowisku mocno integracyjnym, to warto fasadę 
kojarzyć z innymi fasadami właśnie przez dependency injection.
3. Ostatnia praktyczna uwaga: nie przesadzając z liczbą metod w fasadzie 
i skrupulatnie dobierając metodom nazwy, przedłużasz tym samym życie 
programistom-użytkownikom twojego dzieła :)

Mam nadzieję, że choć trochę pomogłem.

-- 
pozdrawiam,
Michał

Piotr Dembiński napisał(a):
> Przemek Pokrywka <adres@zastrzezony.com> writes:
> 
> 
>>Witam! :-)
>>
>>Czy zdarzyło się komuś z Państwa pisać wielki komponent systemowy
>>zrealizowany w postaci pojedynczego obiektu?
> 
> 
> Jakby na to spojrzeć w odpowiedni sposób, to wszystkie programy są
> takimi obiektami.

W sumie tak i nie - niektóre programy nie dopuszczają możliwości 
uruchomienia więcej niż jednej instancji samego siebie (np. zakładają 
file system lock). Możliwość posiadania kilku komponentów danego typu w 
jednym programie jest dla mnie istotną cechą tak rozumianego komponentu.

Poza tym sposób ich uruchamiania bywa bardzo złożony (liczne pliki 
konfiguracyjne). Nie wyobrażam sobie możliwości traktowania serwera 
Apache jak taki obiekt.

Za to zgadzam się, że bardzo wiele tzw. "użytków unixowych" można tak 
potraktować.

Przemek Pokrywka