Coders' city

[wowo098]

Witam,
Wiem, ?e temat jest bardziej ogólny, ale umie?ci?em go tutaj, poniewa? programuje w javie i chcia?bym, aby uwzgl?dniono jej "ograniczenia" (np. brak mo?liwo?ci wielodziedziczenia klas).
Zmagam si? z pewnym problemem ju? d?u?sz? chwil? i nie mog? znale?? rozwi?zania, które by mnie satysfakcjonowa?o. Problem wygl?da nast?puj?co, mam klas? Osoba. Po klasie Osoba dziedzicz? klasy Wokalista i Gitarzysta. Mo?emy stworzy? obiekty klas Perkusista i Gitarzysta. Bardzo fajnie, ale co w przypadku gdy dana Osoba jest Wokalist? i Gitarzyst? jednocze?nie? Czy istnieje jaki? struktura klas, wzorzec projektowy, który by ?adnie oddawa? takie zale?no?ci?
Z góry dzi?kuj? za jakiekolwiek sugestie i pomoc.

[samolot]

Je?li ?le my?l? to mnie poprawcie. Ja bym w klasie osoba doda? w?a?ciwo?? "Funkcja", której mo?na by nadawa? warto?ci takiego enumeratora, zdefiniowanego wcze?niej:
1-Wokalista
2-Gitarzysta
4-Perkusista
8-Wiol?czelista
16-Skrzypoek
Tworzysz now? klas? typu Osoba i nadajesz jej warto?? w?a?ciwo?ci Funkcja
Przyk?adowo:
- je?li równ? 3, co b?dzie oznacza?o, ?e ta osoba jest zarówno Wokalista jak i Gitarzyst?
- je?li równ? 6, co b?dzie oznacza?o, ?e ta osoba jest zarówno Perkusist? jak i Gitarzyst?

[wowo098]

Problem w tym, ?e sama identyfikacja nie wystarcza. Ka?da z klas pochodnych b?dzie mia?a oddzielny zestaw metod.

[samolot]

Klasa pochodna dziedziczy metody "ogólne" po klasie bazowej
A specyficzne metody klasy pochodnej implementujesz w klasie pochodnej.

[wowo098]

Dzi?kuj? za pomoc!

[marcin_an]

Ehh... efekt nauczania obiektowo?ci na przyk?adzie "postaci z gier" (tudzie? podobnych) w po??czeniu z podchodzeniem do tworzenia programu od strony literki "M" w MVC.

Zacznij od przemy?lenia, jakie operacje mo?esz wykona? na cz?onkach zespo?u. Czyli jakie metody b?dziesz mia?. Zestawy tych metod maj? by? w interfejsach, nie klasach. Konkretne klasy jedynie implementuj? te metody. Nic ponad to: nie dziedzicz? po innych klasach, nie tworz? mi?dzy sob? hierarchii. Od tego s? interfejsy, które mog? dziedziczy? po sobie - tak?e w postaci dziedziczenia po kilku interfejsach jednocze?nie. Zatem nic nie stoi na przeszkodzie, by? mia? interfejs WokalistaGitarzysta.

Nic oprócz... prawie na pewno braku potrzeby tworzenia takiego potworka. Na tej zasadzie móg?by? i?? dalej i tworzy? WokalistaGitarzystaBasista itd. Dla standardowego, 4-instrumentowego zespo?u masz ju? 23 mo?liwo?ci. Dla typowej kapeli folk-metalowej z 7 instrumentami masz z 5 tysi?cy opcji i warto?? ta ro?nie bardzo szybko. Nie t?dy droga - i to jest bol?czka, o której napisa?em na pocz?tku.

Nie próbuj robi? kopii ?wiata w swoim programie. Definicje powinny by? zale?ne od tego, jakie metody b?dziesz musia? wywo?ywa? na swoich obiektach. Czy jakikolwiek fragment twojego programu oczekuje, ?e istnieje obiekt, który b?dzie musia? by? jednocze?nie wokalist? i gitarzyst?? Czy jest chocia? jedna metoda, która przyjmuje jako argument co?, co musi by? wokalist? ORAZ gitarzyst? i wywo?uje metody obydwu*? Je?eli nie, to znaczy, ?e nie potrzebujesz takiego interfejsu.

Mo?esz, oczywi?cie, mie? klas? implementuj?c? obydwa interfejsy. Przyk?adowo:

[samolot]

[marcin_an]

Przepraszam, nie mia?em zamiaru ci? zruga?. Mo?e powinienemby? bardziej rozwin?? tamt? wypowied?, co te? zrobi?.

Pomijaj?c na chwil? sensowno?? takiego podej?cia (o tym dalej), zauwa? jedn? rzecz. W zaproponowanym rozwi?zaniu faktycznie jeste? w stanie rozró?ni? ró?nych muzyków: mie? wokalist?, perkusist?, skrzypko-wokalist? itp. Ale nie mo?esz w ?aden sposób spo?ytkowa? tej informacji. Wszystkie obiekty b?d? mia?y bowiem dok?adnie ten sam zestaw metod. Tutaj s? dwie opcje: znale?? najmniejsz? cz??? wspóln? albo u?y? sumy wszystkich mo?liwo?ci. Pierwsze oznacza, ?e nie b?dzie ?adnych metod "muzycznych", czyli obiekty b?d? bezu?yteczne. Drugie jest jeszcze gorsz? sytuacj?: wi?kszo?? metod jest obecna, ale w rzeczywisto?ci nie dzia?aj?, bo dla danej osoby nie maj? sensu.

Wracaj?c teraz do obiektowo?ci: jedn? z g?ównych zalet podej?cia obiektowego jest uniezale?nienie od siebie elementów programu, swobodne zmienianie ich implementacji bez wp?ywu na reszt? programu oraz mo?liwo?? nieograniczonego dodawania nowych implementacji. U?ycie rozwi?zania takie, jakie zaproponowa?e?, stoi w sprzeczno?ci z tymi tematami.

Nie mo?esz dodawa? ile chcesz nowych implementacji, bo ka?da musi mie? przyporz?dkowany bit w zestawie flag, okre?laj?cym jej typ. W zale?no?ci od sytuacji, j?zyka i mo?liwo?ci, liczba bitów jest zwykle ograniczona do czego? pomi?dzy 32 a 128. Typowo: 64. Mo?na u?ywa? kilku zmiennych, ale chyba zaczynasz ju? czu?, ?e jest to tylko uciekanie od problemu, które nie jest te? pozbawione kosztów. A je?li dzisiaj nie widzisz mo?liwo?ci utworzenia 64 ró?nych muzyków, to podpowiem, ?e w hitorii informatyki niedoszacowanie mo?liwej liczby opcji jest powszechne. Nie szukaj?c daleko: w X11 (najpopularniejszy system okien) na uk?ad klawiatury przeznaczono 2 bity, bo uznano, ?e 4 uk?ady klawiatury wystarcz? ka?demu. Je?li nawet mimo tego 64 wydaje si? du?? liczb? dla czego? opisuj?cego zespó? muzyczny, to przypomn? o dwóch innych rzeczach. Pierwsze: w in?ynierii zachowuje si? pewien zapas "na wszelki wypadek". Drugie: w czasie rozwoju programu na przestrzeni wielu lat powstan? alternatywne implementacje tych samych muzyków. Po uwzgl?dnieniu powy?szego okazuje si?, ?e 64-bitowa ma du?o mniejsz? "pojemno??": mo?e nawet rz?du 4-8 muzyków.

?eby doda? taki nowy identyfikator, trzeba poprawi? ka?dy fragment kodu, który b?dzie si? do niego dotyka?. Nie mo?esz po prostu doda? warto?ci 32 dla flecisty. Nie, ca?y program musi wiedzie?, co oznacza to 32. W przypadku identyfikatorów w postaci flag, takich jak zaproponowane przez ciebie, jest jeszcze o tyle dobrze, ?e w niektórych sytuacjach mo?na zignorowa? nieznane warto?ci i program si? nie posypie. Ale to tylko ograniczenie skutków problemu, a nie jego wyeliminowanie. A problem jest znacz?cy. W projekcie, nad którym pracuje ca?y zespó? ludzi, zsynchronizowanie ich pracy i zagwarantowanie spójno?ci takich rzeczy wymaga sporego wysi?ku. Nawet je?eli pracuje si? samodzielnie, to nadal jest to kupa roboty, konieczno?? przekompilowania sporej cz??ci programu i przetestowania jej - w tym napisania testów, które nie b?d? s?u?y?y niczemu innemu oprócz sprawdzeniu w?a?nie dzia?ania tej jednej warto?ci. Porównuj?c to do podej?cia obiektowego, gdzie jeden programista po prostu dodaje sobie klas? i nie wp?ywa to na nic innego, jest to potworne marnowanie zasobów.

I, ostatnie, niezale?no?? ró?nych cz??ci programu. Cz??ciowo poruszy?em to ju? w poprzednim paragrafie, ale tutaj podejd? do tego od strony bardziej formalnej. Istnieje co?, co nazywa si? Liskov substitution principle. Po polsku: "zasada podstawienia Liskov", ale nie polecam definicji zawartej na polskiej Wikipedii. W skrócie* mówi ona, ?e je?eli mamy dwa typy T i U, gdzie U jest podtypem T, oraz mamy kod u?ywaj?cy obiektów typu T, to kod ten musi dzia?a? - bez ?adnych zmian - tak?e dla obiektów typu U. Przyk?adowo: mamy typ Zwierz? oraz typy Pies, Kot, Ko? i Wieloryb. Mamy kod, który robi co? na obiektach typu Zwierz?: np. maluje je ca?e pomara?czowo. Do kodu tego mo?emy podstawi? Pies, Kot, Ko? albo Wieloryb i dla tego kodu nie powinno mie? ?adnego znaczenia, jakie zwierze faktycznie dosta?: ka?de ma pomalowa? na pomara?czowo. I je?li przyjdzie mi do g?owy za rok, ?eby stworzy? typ Biedronka, to kod ten powinien pomalowa? biedronk? na pomara?czowo bez zaj?kni?cia. Jak sam zapewne zauwa?asz, u?ywanie rozwi?zania z flagami przeczy tej regule.

Niezale?no?? ró?nych cz??ci programu jest te? ograniczona faktem, ?e musi istnie? centralny "rejestr" tych warto?ci. Czy to b?dzie typ wyliczeniowy, jaka? lista, czy nawet kawa?ek papieru na biurku ka?dego programisty, jest to co?, co niepotrzebnie spina ze sob? rzeczy, które powinny by? oddzielne.

____
* Formalna definicja jest bardziej precyzyjna i mniej zale?na od konkretnego j?zyka programowania. Tutaj przyj??em form? uproszczon?, pasuj?c? do praktycznego jej zastosowania w j?zykach obiektowych w stylu C++, C# czy Javy.

[samolot]

Z t? obiektowo?ci? jest tak, ?e w?a?ciwie ja j? rozumiem, ale trudno j? stosowa? "od razu", bo to wymaga dok?adnej analizy problemu pod wzgl?dem obiektowo?ci. Widz?, ?e paln??em g?upstwo, ale liczy?em w?a?nie na tak? wypowied? jak twoja.
Poza tym uwa?am, ?e nigdy nie jest tak, ?e implementuje si? dla problemu od razu gotowe, bezb??dne, niezale?ne obiekty, które s? od razu w ka?dym wzgl?dzie doskona?e. Tworzy si? raczej co? zbli?onego, a pó?niej si? to poprawia i udoskonala. Oczywi?cie dog??bne przemy?lenie problemu na pocz?tku pomaga wystartowa? z lepsz? jako?ci? obiektów, ale zawsze jest to proces dochodzenia do pe?nej obiektowo?ci.


'