Zbyt wysokie sprzężenie lub w porządku do takiego projektowania?

Question

Załóżmy, że mam classA, który ma własne metody z własnymi polami prywatnymi i co masz (zasadniczo przestrzegać standardów enkapsulacji). Następnie mam classB, który potrzebuje do jego wykonania stanu końcowego (który jest uzyskiwany za pomocą jednej z metod classA, która nieco przerywa enkapsulację) classA. A następnie mamy classC, który ponownie potrzebuje stanu końcowego classB. I tak dalej i tak dalej, powiedzmy, classM. Czy uważa się to za zbyt duże sprzężenie, czy nie?

Edycja: Ok, załóżmy, że projektowałem system Łupów, który zależy od tego, czy spadek nastąpi w wyniku pokonania wroga (każdy przeciwnik ma inną szansę spadnięcia). Jeśli wróg zostanie pokonany, rzeczy bitewne klasy będą rzucać kostką, niezależnie od tego, czy coś spadnie, czy nie, a następnie muszę przekazać ten stan drugiej klasie obsługującej dystrybucję łupów. W przypadku upuszczenia łup zdobywa łupy, a gracz otrzymuje wygraną łupu i jego dystrybucję, jeśli nie, unieważnia.

Ostateczne wykonanie byłoby coś takiego:

classA a = new classA; 
... //classA does its stuff 
classB b = new classB(a.getFinalState()); 
... // again class does its stuff based on outcome of A 
classC c = new classC(b.getFinalState()); 

i tak dalej.

Answer 1

Edycja: można osiągnąć to, co chcesz przez następujące Delegation Pattern i jego blisko rodzeństwo Decorator Pattern

budowniczy, jak już sugerowano, jest dobrą alternatywą. To zawsze zależy od tego, do czego zmierza twój pierwotny projekt.

Answer 2

Tak. Istnieje ścisłe powiązanie z poziomem 2. Jest to wysoce możliwe do uniknięcia i uważane za złą praktykę, co zmniejsza elastyczność i możliwość wielokrotnego wykorzystania kodu. A testowanie to nocna klacz.

Jeśli mają powiązane ze sobą właściwości, należy rozważyć spojrzenie na Builder Pattern.

budowniczy jest znaleźć rozwiązanie do konstruktora teleskopowy anty-wzorzec

To konstruktor anty-wzorzec jest to, co masz do tej pory.