Czy sensowne jest dostawanie się do obiektu poprzez wiele innych obiektów

Siema, w swoim projekcie mam przypadek że jeżeli chcę się dostać do konkretnej zmiennej to muszę przejść przez wiele obiektów.
Np. var zmienna= LaLiga.FcBarcelona.Formacja.Pozycja.SzansaNaBramke;
Mogą w moim projekcie wystąpić nawet i dłuższe takie przykłady, dla mnie jest to wygodne i dobrze mi idzie takim sposobem, ale czy tak powinno się robić, czy lepiej tego unikać?
Staram się uczyć dobrych nawyków.
Z góry dzięki za pomoc. :)

Lepiej unikać. "Czysty kod", strona 118. To co piszesz, jest dopuszczalne, bo nie korzystasz z akcesorów, ale wciąż wygląda to jak wykolejony pociąg :D Najlepiej jak najbardziej skracać powiązania.

Sądzę, że korzeń tych zapisów można skrócić. Tylko pewnie kawałek aplikacji by trzeba przeprojektować. Dlaczego np. nie możesz wybranej formacji przetrzymywać w jakiejś zmiennej pomocniczej, do której potem się będziesz odwoływać podczas rozgrywki? Rozumiem, że formację się wybiera w przerwach (np. przed meczem i po pierwszej połowie). A drużynę to już w ogóle znacznie wcześniej.

Łamiesz Prawo Demeter: https://en.wikipedia.org/wiki/Law_of_Demeter

U mnie działa to tak.
Jest klasa Match w której są wszystkie zmienne i funkcje meczu.
W każdym meczu są dwie drużyny.
Każda drużyna ma swoich zawodników i swoją formację.
Każda formacja w drużynie ma swoje pozycje (w każdej pozycji zawodnika są takie informacje jak np. szansa na gola z główki, szansa na gola po dryblingu), bo wiadomo że nie chcę żeby bramki strzelali równie często obrońcy jak i napastnicy.
W jaki sposób za pomocą zmiennej pomocniczej?
Czyli po prostu dążyć do tego żeby np. w Drużyna posiadała i graczy i pozycje i formacje? A nie tak że Formacja posiada pozycje?
Zobaczę sobie "Czysty kod" , warto się uczyć od początku dobrych nawyków. ;)

A do czego konkretnego potrzebujesz zmiennej z głębi tak odległego obiektu?

Do wyświetlenia np. nazwy pozycji piłkarzy , formacji drużyny przed meczem.

Nie rozumiesz o co chodzi :)

Dlaczego te obiekty po drodze nie wykonują operacji na swoich danych?

Załóżmy, że masz klikniętego tego piłkarza, to kliknięcie powinno spowodować, że gdzieś w aplikacji ustawiona będzie zmienna: kliknietyPilkarz = this;, potem jak np. klikasz przycisk "strzel do bramki" odwołujesz się do odpowiedniego pola piłkarza: kliknietyPilkarz.szansaNaBramke.

Musisz widocznie coś przeprojektować, zmienić powiązania między obiektami, żeby osiągnąć taką prostotę. Im dalej szedłeś w zaparte ze złym kodem, tym więcej trzeba będzie wyrzucić.

BTW. jeśli chcesz napisać dobrą grę o piłce nożnej, to wzoruj się na tym :)

Dzięki za odpowiedzi. :)
Postaram się coś przeprojektować.
Czyli uważasz że lepiej jest mieć po prostu więcej pól w jednej klasie niż więcej klas w których jest mniej pól?
Jak wejdziesz na flashscore.com to tam będą takie relacje tekstowe meczy, właśnie staram się zrobić taki "generator". :)

ollo98 napisał(a):

Do wyświetlenia np. nazwy pozycji piłkarzy , formacji drużyny przed meczem.

Do wyświetlania danych powinieneś mieć obiekty, które nie mają żadnych podobiektów, tzw. ViewModele, jeden ViewModel to jeden ekran w aplikacji (upraszczając).
Te obiekty powinny być oddzielne od tych, na których przeprowadzasz wykonujesz jakieś operacje biznesowe.

Czyli w skrócie mam unikać takiego rozłożenia klas i obiektów w klasach żeby nie było takiego długiego zapisu?
Czy robić taki rozkład klas że Piłkarze w drużynie, drużyna w lidze, umiejętności piłkarza itd, tylko unikać po prostu zapisu tak długiego zapisu?
@somekind, czyli muszą być to być obiekty tej samej klasy? Nie rozumiem za bardzo o co z tym chodzi, bo ViewModel kojarzy mi się tylko z ASP.NET MVC. ;)

To co teraz robisz to za zawoalowane, God Object i zmienne globalne nie tędy droga. Obrazowo rzecz ujmując chodzi o to ze masz osiągalność prosto proste klocków lego masz wiele prostych części które składasz w całość, a Ty zamiast klocków lego masz ośmiornice, zrobiłeś przyssawkę, ramie, głowę itd., możesz dowolnie dodawać przyssawki do macek, macki do głowy, zmieniać ich rozmiar i kolor i ilość. Teoretycznie fajnie pięknie ale jak spróbujesz głowę zmienić to potworek owinie Cie mackami i udusi.
Sam tak kiedyś robiłem, staraj sie pisać jak najmniej publicznych pól i możliwie jak najwiecej private readonly. A i nie powinieneś mieć pola FcBarcelona tylko klase druzyna i robić np. cos takiego var cos =laLiga.GetTeam("FC") albo var cos= laLiga["Barca"], i potem to coś obrobić w kolejnej metodzie.

Moje rozplanowanie wygląda mniej więcej tak.
http://www.bankfotek.pl/image/2026193
Oczywiście te klasy są "większe" i będą coraz większe i będą posiadały coraz więcej "zawartości" w sobie.
Nie podałem tu wszystkich zmiennych bo jest ich za dużo.
Ale czy taki rozkład jest prawidłowy? Czy może taki być tylko po prostu unikać publicznych pól i długiego dostępu do zmiennej?
@topik92, właśnie tak mam, jest klasa drużyna i według tej klasy tworzę poszczególne drużyny.