Operacje na składowych pomiędzy klasami

Witam

Uczę się programować obiektowo i mam pytanie.

Jak operować na zmiennych pomiędzy klasami. W sensie, że mam np. jakąś tablice, którą chcę, żeby była dostępna do operacji przez dwie klasy. I teraz mogę to zrobić na kilka sposobów.

1. Utworzyć tablicę w pierwszej klasie, a następnie przez referencję przekazać do konstruktora drugiej klasy.

2. Utworzyć tablicę w pierwszej klasie i przekazywać przez referencję do jakichś metod drugiej klasy.

3. Zamiast 2 klas utworzyć jedną dużą, która będzie obejmowała funkcjonalność tych klas i wtedy po prostu zadeklarować w niej tablicę.

4. Utworzyć trzecią klasę abstrakcyjną w niej umieścić tablicę jako statyczną, a potem zrobić dziedziczenie tej klasy przez 2 wspomniane klasy.

I teraz pytanie. Która z tych opcji jest najlepsza. W sensie, że zdaje sobie sprawę, że każdego ze sposobów używa się w zależności od sytuacji, pytam która z opcji jest jakby najczęściej używana i zgodna z ideą programowania obiektowego. A może robicie to zupełnie inaczej?

Jeśli ktoś nie rozumie o co mi chodzi dam pewien przykład. Ostatni robiłem menu do gry. Mam jakąś funkcję main w której tworzę obiekt klasy Menu. Te menu ma składową "obraz", czyli po prostu obraz, który jest wyświetlany na ekranie. W klasie Menu tworzę obiekt klasy WskażnikMenu, który będzie po prostu podświetlał odpowiednią opcję w menu, lecz żeby to zrobić muszę mieć dostęp do zmiennej obraz i musi być to ten sam obraz, który jest w obiekcie menu. Jak to zrobić?

Klasa w klasie powinna mieć dostęp do pól klasy wyżej tak więc bez kombinowania po prostu ich używasz. Natomiast nie podałeś języka więc moja odpowiedź nie jest pewna.

Po pierwsze do kogo "należy" tablica? Do pierwszej czy do drugiej klasy.
Po drugie czy operacje są podobnego rodzaju? Jeżeli tak to czym się różnią.
Po trzecie czy klasy mają wspólną logikę czy tylko współdzielą jakieś dane?

Lukasz_ napisał(a):

Klasa w klasie powinna mieć dostęp do pól klasy wyżej tak więc bez kombinowania po prostu ich używasz. Natomiast nie podałeś języka więc moja odpowiedź nie jest pewna.

Czyli sugerujesz, żeby za każdym razem, gdy dojdzie do wspomnianej sytuacji w klasie wyżej deklarować tablicę, a klasa zagnieżdżona będzie miała dostęp do tablicy (nie mylić z dziedziczeniem).
Wydaję mi się, że idea programowania obiektowego jest taka sam dla wszystkich języków programowania, ale jeżeli ma to jednak jakieś znaczenie to swoje programy piszę w Javie oraz C++.

Koziołek napisał(a):

Po pierwsze do kogo "należy" tablica? Do pierwszej czy do drugiej klasy.
Po drugie czy operacje są podobnego rodzaju? Jeżeli tak to czym się różnią.
Po trzecie czy klasy mają wspólną logikę czy tylko współdzielą jakieś dane?

1. Wydaję mi się, że z pytania wynika, że nie ma znaczenia, do której klasy należy tablica.
2. Nie rozumiem. Mówiąc operacje miałem na myśli po prostu dostęp do zmiennej. Czyli przypisywanie do niej czegoś, czy zwracanie jej wartości.
3. Pytanie zadałem dosyć ogólne właśnie po to by dowiedzieć się co robić w obu tych przypadkach (jak mają wspólną logikę lub nie mają).

ad 1. Ma znaczenie kto jest "właścicielem". Jeżeli jest nim jedna z klas to należy zastanowić się czy przekazanie tablicy do innej klasy nie jest ujawnianiem szczegółów implementacji. W takim wypadku można zamiast przekazania tablicy wzbogacić interfejs takiej klasy o metody pozwalające na modyfikację tablicy.
Może też być tak, że tablica nie należy do żadnej z klas. Jest zwyczajnym nośnikiem danych. W takim wypadku można ją swobodnie przekazywać jako np. parametr wywołania metody albo jako parametr konstruktora.
ad 2. Wpisanie czegoś do tablicy lub modyfikacja któregoś z elementów może być realizowana na kilka sposobów. Najprościej to mieć bezpośredni dostęp do tablicy i pracować bezpośrednio na nie. Jeżeli jednak zależy ci na bardziej obiektowym podejściu to można tablicę opakować w obiekt, który będzie miał metody pozwalające na różne operacje na tablicy. Ma to tą zaletę, że tablica wtedy staje się szczegółem implementacyjnym i można ją łatwo w razie czego zamienić na na przykład listę. Dodatkowo nasza opakowująca klasa będzie całkiem przyjemnym rozwiązaniem problemu dostępu współbieżnego to danych.
ad 3. Jeżeli klasy mają wspólną logikę (powtarza się w nich kod) to rozsądnym wydaje się wydzielenie nadklasy, ale tylko pod warunkiem, że klasy te są też jakoś powiązane w modelu aplikacji. Jeżeli jest to na przykład Pies i Kot to można by wydzielić im wspólną nadklasę. Jeżeli jednak masz do czynienia z klasą Pies i Bulbulator to uwspólnianie ich w hierarchii klas jest złem. W takim wypadku należało by wspólną część kodu wynieść do jakieś klasy pomocniczej.

1. nie
2. nie
3. nie
4. nie

http://en.wikipedia.org/wiki/Single_responsibility_principle