Obiektowe modelowanie dziedziny

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.

Lepiej gdybyś zrobił coś takiego.

class Osoba{
Set<Muzyk> role  = new HashSet();
 }

abstract class Muzyk{}
class Perkusista extends Muzyk{}
class Gitarzysta extends Muzyk{}

Staraj się aby obiekty jak najbardziej oddawały rzeczywistość.

Przy czym osoba to tak skomplikowany obiekt, iż oczywiście nie opisuje się go w pełni, tylko pod kątem danego oprogramowania, ale najlepiej w taki sposób, aby łatwo było rozszerzyć ten opis.

Na przykład możesz stworzyć obiekt Osoba, do tego interfejs Zawód, i klasy które implementują ten interfejs (Perkusista, Gitarzysta), dobrze też między interfejsem a klasami właściwymi zrobić jeszcze Adapter (ale to też zależy jak leży). Następnie w obiekcie osoba robisz listę zawodów jakie ta osoba może wykonywać. Trochę podobnie jak odpowiedź wyżej, z tym, że ja proponuję ogólny interfejs Zawód, a nie abstrakcyjne klasy.

TomRZ napisał(a):

Na przykład możesz stworzyć obiekt Osoba, do tego interfejs Zawód, i klasy które implementują ten interfejs (Perkusista, Gitarzysta),

Ciekawe co robi taki gośc z interfejsem Zawód... zawodzi?

Interfejsy to może być dobra odpowiedź ale...
Interfejs powinien oddawać jakąś użyteczność danego obiektu. Czyli np. w interfejsie **Gitarzysta **może być metoda walPowercorda(akord).
A w interfejsie Perkusista napier...ajWGary().

Ogólnie modelowanie samo z siebie bez ograniczenia sie co ma modelowany system robić jest bez sensu.
Może nie potrzebujesz rozgraniczenia na te dwie klasy ... bo w twoim systemie i tak funkcjonalność jest ta sama dla jednego i drugiego?

Interfejs Zawód może mieć różne metody spajające wszystkie zawody w zależności od potrzeb oprogramowania, np.:

wykonaj() - czyli w przypadku perkusisty - oznacza zagrania na perkusji, w przypadku gitarzysty - na gitarze, a w przypadku lekarza - leczenie itd.
miesiecznyKosztPracy() - zwróci dla danego zawodu koszt miesięcznej pracy, etc,
albo metoda: kosztZaGodzinePracy()

Poszczególne zawody różnie mogą implementować interfejs, mieć różne właściwości i dodatkowe metody, ale interfejs jest po to aby wprowadzić jakiś standard, ułatwić sobie życie.

Zamiast dla każdej klasy wykonywać osobne inne metody, mamy jedną spajającą wszystkie zawody.

NIe ma uniwersalnej recepty podałem interfejs jako jeden z przykładów jak to można zrobić, wszystko zależy od potrzeb oprogramowania.

Dziękuję wszystkim za pomoc!