[studi1221]

witam, zakupilem ksiazke design patterns, ale spis tresci jest troche zbyt fency opisany, orientuje ktory rozdzial jest o depency injection? xD
#wzorceprojektowe #programowanie #java #csharp

[C.....y]

@studi1221: Inversion of control?

jaką książkę kupiłeś może napisz xD

[C.....y]

@studi1221: Możesz to napisać po ludzku? Jaką książkę Design Paterns, gang czworga? .NET Design Patterns?

[studi1221]

@Czarzy: ale jestem leb, zapomnialem napisac head first na poczatku

[mrooczilla]

"ale jestem leb, zapomnialem napisac head first na poczatku"
@studi1221: jesteś pewien że programowanie to coś dla Ciebie ?!

[studi1221]

@mrooczilla: nie, tak po prostu z nudow se ta ksiazke przeczytam

[studi1221]

@Czesiowcy: jw

[MQs]

@studi1221: Żaden, bo to nie jest wzorzec. Tak samo nie piszą o dziedziczeniu (subtyping), chociaż jednego i drugiego używają cały czas.

[szczesc_borze]

@MQs: Tez bez pewnej przesady. To jest wzorzec projektowy. Bardzo zresztą prosty. Z technicznego punktu widzenia, nawet przekazanie argumentów do metody jest rodzajem wstrzykiwania zależności. O DI jednak mówimy głównie w ujęciu obiektowym, czyli o wstrzykiwani jednych obiektów innym w celu rozluźnienia powiązań.

[MQs]

@szczesc_borze: Gdyby DI uznać za wzorzec to o każdym innym trzeba by mówić jako o szczególnym przypadku DI lub dziedziczenia, a cała obiektówkę można by opisać jako używanie dwóch wzorców, co nie niesie żadnej informacji. Nie dotyczyłoby to jedynie tych "wzorców", które są z kolei nazwami opisującymi rodzaje obiektów (zwykle składowych jakiegoś wzorca bez abstrakcji - np factory czy builder), chociaż bliżej im do definicji wzorców projektowych niż samemu DI moim

[szczesc_borze]

@MQs:

Gdyby DI uznać za wzorzec to o każdym innym trzeba by mówić jako o szczególnym przypadku DI lub dziedziczenia, a cała obiektówkę można by opisać jako używanie dwóch wzorców, co nie niesie żadnej informacji.

Wydaje mi się, że kluczowe dla tej dyskusji jest zrozumienie, że wzorce rozwiązują pojedyncze problemy i robią to na różnych poziomach abstrakcji. DI pozwala budować zależności między komponentami zgodnie z bardziej ogólną koncepcją IoC, a taka

[MQs]

wzorce rozwiązują pojedyncze problemy i robią to na różnych poziomach abstrakcji.

@szczesc_borze: Wciąganie różnych poziomów abstrakcji kończy się tym, że wzorcem może być wszystko, bo całe programowanie to rozwiązywanie problemów na pewnym poziomie abstrakcji. Immutable object - wzorzec, bo pozwala na..., private method - wzorzec, bo pozwala na..., if-else też rozwiązuje pewien problem itd. Mnożysz byty bez potrzeby i wprowadzasz niejednoznaczność. Jeden powie, że użył strategii, a drugi że dependency

[szczesc_borze]

@MQs: Nie rozumiem chyba do końca idei stojącej za tym co piszesz. Wzorce to sprawdzone techniki, które doczekały się nazw ze względu na popularność i skuteczność danego rozwiązania dla powtarzającego się problemu. Podział wzorców jest oparty o ich rolę i poziom abstrakcji własnie. Wzorce architektoniczne to chociażby MVC i opisują działanie całych systemów, kiedy wzorce projektowe dotyczą relacji w jakich pozostają klasy i obiekty.
DI dotyczy bezpośrednio relacji między obiektami i

[MQs]

Podział wzorców jest oparty o ich rolę i poziom abstrakcji własnie.

@szczesc_borze: No przecież dlatego to poruszyłem, bo próbowałeś mnie przekonać że wzorce projektowe dotyczą różnych poziomów abstrakcji.

Nie wiem czemu Fowler DI przeciwstawia Service Locator. Dla mnie to trochę niespójne, bo DI zawsze traktowałem jako sposób na kompozycję obiektów, a SL to jeden z wzorców z niej korzystający - wypaczony, bo ukrywa bezpośrednie zależności poprzez wstrzyknięcie kontenera jako zależności bezpośredniej.