fbpx

Obiektowo orientowana pogoń za własnym ogonem

6 komentarzy

  1. Znowu z ostatniego akapitu wynika, że mówimy o tym samym, mając jedynie inne nazwy na problemy i podejścia do rozwiązań:)

    Na początek trochę prostowania pojęć: w DDD nie chodzi o Object Oriented ani o Building Blocks. Są to jedynie techniki stworzone na potrzeby pewnego kontekstu. Można użyć sobie innych technik i innych BB (np z kontekstu formsów).

    Co do książki Evansa trzeba ją czytać co pół roku poczynając od drugiej połowy:)

    Co do tego, że ktoś nie narzeka, to różne mogą być tego przyczyny – np. to, że jest super, albo brak świadomości, że super nie jest:P

    Odnośnie modelu… no więc właśnie, co to jest model? Jakie są rodzaje modeli? Czym różni się model od szkicu wizji, słownika rzeczowników i (jedynie) semantycznych relacji pomiędzy nimi. Jaką wartość ma sam diagram relacji encji? Na pewno lepiej go mieć niż nie mieć. Czy w systemie klasy "przeglądarka do bazy danych" z autystycznym UI, od którego nikt nie wymaga szybkich zmian dostosowujących biznes do walki z konkurencją potrzeba DDD? :PPP

    Lepiej od strony praktycznej: do czego służy model? Kiedy i do czego go potrzebujemy oraz w jakiej formie a kiedy jest zbędny. Bez odpowiedzi na to pytanie wszyscy będziemy jedynie dokonywać projekcji swoich doświadczeń na zbyt szeroką ogólność.

  2. Nie wierzę w to co przeczytałem.

    Kojarzy mi się z tym "po co te wszystkie klasy" taka historia, że kiedyś po wygłoszeniu wykładu o systemie, który automatyzował pewien proces, ktoś z sali zapytał mnie:
    "po co automatyzować skoro równie dobrze może to zrobić człowiek"
    Niby można odpowiedzieć: "żeby człowiek tego nie musiał robić", ale czasem po prostu ręce opadają.

    W tym przypadku można byłoby polecić przejrzeć badania porównujące wyniki projektów pisanych w językach proceduralnych do tych pisanych w obiektowych, zamiast opierać się na własnych (niemierzalnych) doświadczeniach, ale po prostu ręce opadają.

  3. ToJaJarek pisze:

    Ciekawa interpretacja… problem z Oracle i Formsami (i nie tylko) polega na tym, że model relacyjny jako taki nie spełnia elementarnej zasady: "niezmienny ale rozszerzalny". Po co ona? No po to by możliwe było rozszerzanie dodawania kolejnych usług, "naprawianie" już istniejących bez zmiany struktury całego systemu. W metodach relacyjnych raz opracowany model relacyjny danych, opisujący jakąś firmę jest betonowym fundamentem aplikacji. Po drugie niestety model relacyjny to model stratny, zebranie danych z faktur, zamówień, kartotek itp. i znormalizowanie tego powoduje, że mamy uporządkowane dane ale już nie mamy biznesowych ich znaczeń i roli. Miasto w słowniku przestaje być miejscem ulokowania magazynu, itp.

    Wyobraźmy sobie, że mamy "out of the box" system, który zarządza od lat magazynem, struktura bazy przewiduje rekordy opisujące towar z polem ilość itp.. system pracuje kilka lat (ma dużo tych danych) i nagle pojawia się wymóg ustawowy: musimy zacząć operować wiedzą o każdym sprzedanym egzemplarzu (np. numer seryjny), rozbudowa dobrze zaprojektowanego, obiektowo zorientowanego systemu, będzie możliwa bez prucia całości, baza relacyjna będzie do przeróbki i migracji…

    Owszem mało mamy programistów Evansow, tak samo jak mało mamy murarzu architektów i projektantów, jeżeli ktoś uważa, że to programista na "obmyślać implementację" to czyni błąd w założeniach…

    Patryku, obawiam się, że masz rację…

  4. @Sławek
    Wpadnę na http://2013.33degree.org/talk/show/24, bo chyba tam szerzej rozwijasz swoje stanowisko z komentarza.

    @Patryk
    "(…)można byłoby polecić przejrzeć badania porównujące wyniki projektów pisanych w językach proceduralnych do tych pisanych w obiektowych"
    A mógłbyś przytoczyć konkretne badania, z którymi moglibyśmy się zapoznać?

    @ToJaJarek
    "problem z Oracle i Formsami (i nie tylko) polega na tym, że model relacyjny jako taki nie spełnia elementarnej zasady: "niezmienny ale rozszerzalny". Po co ona? No po to by możliwe było rozszerzanie dodawania kolejnych usług, "naprawianie" już istniejących bez zmiany struktury całego systemu. W metodach relacyjnych raz opracowany model relacyjny danych, opisujący jakąś firmę jest betonowym fundamentem aplikacji. Po drugie niestety model relacyjny to model stratny, zebranie danych z faktur, zamówień, kartotek itp. i znormalizowanie tego powoduje, że mamy uporządkowane dane ale już nie mamy biznesowych ich znaczeń i roli. Miasto w słowniku przestaje być miejscem ulokowania magazynu, itp"

    Wnioskowanie ok. Tyle, że jest dedukcyjne. Bierzesz założenia i potencjalne konsekwencje jednego i drugiego podejścia i wnioskujesz o wyższości jednego nad drugim. Oprócz tego, że żadne z podejść nie jest lepsze "w ogóle" lecz w ściśle zdefiniowanym kontekście, trzeba zauważyć, że to wnioskowanie jest czysto teoretyczne. Czy doszedłbyś do tych samych wniosków, gdybyś zaczął analizować konkretne rozwiązania rzeczywistych zespołów stosujących oba podejścia, ich problemy i efekty?

    "Wyobraźmy sobie, że mamy "out of the box" system, który zarządza od lat magazynem, struktura bazy przewiduje rekordy opisujące towar z polem ilość itp.. system pracuje kilka lat (ma dużo tych danych) i nagle pojawia się wymóg ustawowy: musimy zacząć operować wiedzą o każdym sprzedanym egzemplarzu (np. numer seryjny), rozbudowa dobrze zaprojektowanego, obiektowo zorientowanego systemu, będzie możliwa bez prucia całości, baza relacyjna będzie do przeróbki i migracji…"

    Podobnie j.w. "będzie możliwa". W domyśle: teoretycznie. Jak wspomniałem we wpisie, opieram się tylko i wyłącznie na własnych spostrzeżeniach bez formułowania ogólnych idei, aczkolwiek zespoły pracujące z OO-warstwą aplikacji zazwyczaj mają problemy, które opisałeś. Doprowadzają do monolitycznej architektury, trudnej w rozbudowie, a bezmyślnie stosowane frameworki i *-Driven* jeszcze bardziej komplikują sprawę. W zespołach stosujących teoretycznie "gorsze i mniej elastyczne" podejścia, wspomnianych problemów jest mniej.

    Nawet jeśli któreś z podejść ma lepsze założenia teoretyczne, to nie oznacza to, że efekty jego stosowania będą również lepsze. Tak jak wspomniałem we wpisie, ogromną barierą w zespołach są kompetencje. Niezwykle rzadko się wspomina, że do sensownego zastosowania OOP, DDD, itd, trzeba mieć naprawdę, ale to naprawdę świetny zespół ze sporym doświadczeniem. Dogmatyczne i bezkontekstowe stosowanie jakiegoś podejścia, bo jest najlepsze "w ogóle" zazwyczaj przynosi więcej szkody niż pożytku.

  5. ToJaJarek pisze:

    To wyjaśnienie wiele: "Tak jak wspomniałem we wpisie, ogromną barierą w zespołach są kompetencje."

    Jeżeli ktoś z góry zakłada, że projekt będą realizowali nieudacznicy faktycznie chyba musi zadowolić się metodami pracy dostosowanymi do tych kadr… żadne inne wytłumaczenie nie przychodzi mi do głowy…

  6. @ToJaJarek

    A ten wykres

    http://pl.wikipedia.org/wiki/Rozk%C5%82ad_normalny

    jest Ci znany? Jak mawia bohater z tej sceny http://www.youtube.com/watch?v=f5RsG2Oiw6k "mamusię oszukasz, tatusia oszukasz, ale życia nie oszukasz"