AbstractFactory poza główną klasą, wiele razy wywoływany

0

Wzorce projektowe - początek nauki niestety :[

Stworzyłem prosty projekt, który służy mi do nauki DesignPatterns. Zamierzenie jest takie, że wprowadzam po jednym wzorcu po kolei. Pierwszy był Factory, no i w sumie fajnie poszło. Następnie AbstractFactory i tu zaczynają się dla mnie niestety schody. Nie chce źle się nauczyć, a widzę, że chyba zmierzam w złą stronę.

Zamieszczam kod w załączniku, fajnie jakby ktoś rzucił okiem i odpisał, czy to jest prawidłowa implementacja Abstract Factory. Moje wątpliwości wzbudza:

1) Jeśli dobrze rozumiem, wywoływanie AbstractFactory powinno mieć miejsce w DesignPatternsExamples, jednak jednocześnie wygodniej mi kolejny AbstractFactory wywołać w PattermService.

2). Jeżeli stworzenie AbstractFactory w PatternService jest ok, to czy powinienem znowu to zrobić w CreationalFactory? Czy generalnie motać CreationalFactory?
src.rar
3) Właściwie to wprowadzenie AbstractFactory do projektu tylko namotało IMO i zaprzecza zasadzie KISS tj, dużo lepiej wydaje mi się było wcześniej: miałem 4 osobbne fabryki (PatternTypeFactory, DemoFactory, Wewnętrzne fabryki dem, oraz CreationalFactory.

Program jest niedokończony więc prosiłbym o łaskawe potraktowanie niedociągnięć pobocznych ;) To jest projekt stricte do nauki wzorców ;)

Edit: kod usunięty by nie demoralizować dalej młodzieży

3

Kodu nie widziałem, bo utrudniasz jego zobaczenie jak tylko się da, ale nie wierzę, aby specjalny projekt do nauki wzorców mógł mieć jakikolwiek sens.

4

o_O Wzorce stosuje się do rozwiązania konkretnego problemu. Próba ich wprowadzenia z innych powodów to głupota bo ani się ich nie nauczysz, ani nie zrozumiesz po co są. Abstract Factory to jest bardzo szczególny przypadek i ciężko to z sensem zrobić w jakimś Hello World. Zupełnie nie tędy droga.

6

tylko skąd mam wiedzieć, że akurat mój problem rozwiązuje jakiś wzorzec skoro ich nie znam? @TheLearner

To jest bardzo dobre pytanie. @somekind odpisał - w ogniu walki.
Po prostu pisz kod, rozwiązuj problemy. A zupełnie z boku czytaj sobie (ale nie za dużo - o wzorcach). Samo się poskłada.

(Zresztą - przyznam uczciwie, że jestem osobiście do wzorców mocno zniechęcony. IMO przwewżnie to nie są rozwiązania typowych problemów, tylko przykłady uwypuklające problemy języków programowania z lat 90tych zeszłego wieku).

0

Przyznam szczerze, że na chwilę obecną nie do końca do mnie trafia koncepcja nauki w ogniu walki bez wcześniejszego zapoznania z pewnymi koncepcjami. Jednak, na forum trochę już tu jestem, zdaje sobie sprawę kim są osoby wypowiadające się, więc ujmując sprawę krótko: ufam wam na słowo. Swój pomysł nauki przenoszę do zapomnianych otchłani folderu "onHold", a za 5 lat wraz z resztą mojego githuba, wyląduje pewnie w temacie Ściana Wstydu. Do tego czasu, rozpalam ognisko i szukam walki.

1

@TheLearner: w ogniu walki proponuję zadawać sobie pytania kontrolne:
1) "Jak podzielić na mniejsze fragmenty?" (do tego jak możesz stosować te kategorie wzorców - tworzenie / zachowanie / struktura)
2) "Jak połączyć fragmenty?" (te które wcześniej wydzieliłeś :) )
3) "Jakiej elastyczności potrzebuję?" (im mniej wiesz o problemie tym większa potrzeba większej abstrakcji, im więcej tym mniejsza potrzeba stosowania takiej)

2

@TheLearner: poza tym co koledzy powiedzieli, dodam że zgadzam się z @jarekr000000 - część tych wzorców może nie miec sensu dzisiaj w takiej formie implementacji jak w książkach. Polecam

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0