Witam, mam problem teoretyczny. Jest taka sytuacja
Mam klasę abstrakcyjną Człowiek, która realizuje jakieś opcje.
I różni ludzie dziedziczą po tej klasie np:

[PHP] pobierz, plaintext 
class Daniel extends Czlowiek
{
...
}
[PHP] pobierz, plaintext 

i chcę aby każdy człowiek posiadał odpowiednie metody(które np ustalają co człowiek potrafi, jak myśli, dla każdego wykonanie tej metody ma być inna).

mogę zrealizować to za pomocą interfejsu np. Interface Genetyka

[PHP] pobierz, plaintext 
interface Genetyka
{
public function wyglad();
public function umiejetnosci();
}
[PHP] pobierz, plaintext 

i wtedy będę miał:

[PHP] pobierz, plaintext 
class Daniel extends Czlowiek implements Genetyka
{
...
}
[PHP] pobierz, plaintext 

ale coś mnie to kole w oczy. Ale mogę dodać metody do klasy abstrakcyjnej skoro i tak każdy człowiek po niej dziedziczy.
Co wy byście zrobili. Zastosowali interface czy dodali definicje metod do klasy.

Najczysciej będzie jak zrobisz najpierw interfejs z metodami ktore maja byc publiczne i sluzyc do komunikacji z obiektem, a pozniej klasę abstrakcyjną go implementującą, a kolejne klasy ludzi bedziesz tworzyl rozszerzajac tą klasę abstrakcyjną.

Jedna uwaga - jezeli te metody maja byc chronione/prywatne to interfejs na to nie pozwoli, wtedy zostaniesz zmuszony by byly one publiczne, co z definicji jest bez sensu bo interfejs ma byc zbiorem metod publicznych pozwalajacych sie komunikowac z obiektem.

[PHP] pobierz, plaintext 
interface Genetics
{
  public function look();
  public function skills();
}
 
// Nie dodajesz juz abstrakcyjnych metod Look i Skills bo interfejs je wymusza
abstract class Human implements Genetics
{
  public function createHuman()
  {
     $this->makeHumanCosTam();
     $this->look();
     $this->skills();
  }
 
  protected function makeHumanCosTam()
  {
      // TODO wpisz cos
  }
}
 
class Daniel extends Human
{
  public function look()
  {
    // TODO wpisz cos
  }
 
  public function skills()
  {
    // TODO wpisz cos
  }
}
 
abstract class UfoHuman implements Genetics
{
  public function createHuman()
  {
     $this->look();
     $this->skills();
     $this->drawLegs();
  }
 
  abstract protected function drawLegs();
}
[PHP] pobierz, plaintext 

interfejs ma tą wadę że żadnych wspolnych metod do niego nie wrzucisz a ludzie na pewno beda mieli wspolne metody.

Albo np ludzie beda cos robic tak samo ale w nieco inny sposob, wtedy mozesz uzyc wzorca metoda szablonowa i wspolną czesc kodu zapisac w klasie abstr. a te wyrozniajace ludzi w klasach potomnych a w samym interfejsie szablonu nie zaimplementujesz.

A jak cie dalej bedzie kuło w oczy, to zacznij pisac nazwy metod i zmiennych po angielsku


Interfejsu uzywaj tylko wtedy jak wiesz ze bedziesz musial dziedziczyc po kilku klasach - w php tego nie zrobisz, bedziesz musal zastapic klasy interfejsami. Choc i wtedy mozna wylaczyc wspolny czynnik przed nawias - porobic klasy abstrakcyjne dla kazdej kombinacji interfejsów ze sobą.

jesli chcesz podszkolic sie z podręcznikowej obiektowości to polecam książkę Kenta Becka chyba ale nie dam sobie głowy uciąć, w każdym razie książka nazywa się "Clean Code" lub "Czysty kod. Podręcznik dobrego programisty". Jest na pewno w twojej bibliotece na uczelni, a jeżeli nie to na necie po angielsku.

To co tu kole w oczy to kompletny brak związku z OOP. Daniel czy inna Ilona nie mogą dziedziczyć po klasie Człowiek, ponieważ te dwa pierwsze to imiona, zaś ostatnie to gatunek. A jak wiadomo imię nie jest wyspecjalizowaną formą gatunku, ani gatunek nie jest uogólnioną formą imienia, racja? Tak więc nie ma tutaj miejsca na jakąkolwiek hierarchiczną zależność pomiędzy tymi rzeczami - nie ma miejsca na dziedziczenie.
Imię to właściwość człowieka. Podobnie sprawa ma się z umiejętnościami. To co dany człowiek potrafi jest jego właściwością, a praktyczniej rzecz biorąc... człowiek posiada kolekcję (zbiór) umiejętności. Z wyglądem sprawa ma się dokładnie tak samo.
Tak więc powinieneś skończyć z czymś w stylu:

[PHP] pobierz, plaintext 
class Human {
  protected $firstName;
 
  protected $skills = array(); // umiejętności same w sobie mogą być obiektami implementującymi jakiś interfejs
 
  public function __construct($firstName) { ... }
  public function setFirstName($firstName) { ... }
  public function getFirstName() { ... }
  public function addSkill(Skill $skill) { ... }
  public function removeSkill(Skill $skill) { ... }
  public function hasSkill(Skill $skill) { ... }
}
[PHP] pobierz, plaintext 

Mnozysz byty ponad miarę. Brzytwa ockhama. Przekombinowujesz. Jezeli czlowiek o imieniu daniel ma specyficzne akcje a czlowiek o imieniu Tania ma inne akcje specyficzne dla siebie to nie widze powodu by nie mogły byc one klasami dziedziczącymi po człowieku.
Dodawanie kolejnej klasy przechowującej skile to niepotrzebne utrudnianie sobie zycia. Dodalbym ją wtedy gdy stanie sie potrzebna.

W tym kontekscie Daniel/Tania jest typem czlowieka takim samym jak homosapiens czy heterosapiens.

Czy Daniel nie jest czlowiekiem? Czy Kamil - obiekt kamil, ten ktory siedzi wlasnie przed laptopem i pisze odpowiedz nie jest czlowiekiem? Jestem imieniem?

Natomiast jezeli tworzymy gre simsy gdzie kazdemu mozna nadac wlasne imie i to są te same hipki to oczywiscie imie powinna byc wartoscią. - w tym momencie daniel jest tylko specyficznym obiektem klasy Sim

Zapedziles sie crozin. Zapominasz ze kolega nie implementuje w programie rzeczywistosci 1:1 tylko jakis własny wymysł, urojony swiat w ktorym wszystko moze byc wszystkim.

Nie wcielaj tutaj potocznych form języka. Gdy mówisz że Kamil siedzi przed komputerem albo że Audi to fajny samochód masz na myśli osobę o imieniu Kamil albo samochód marki Audi.

No właśnie błędny model - jaki Ty i autor próbujecie wprowadzić - mocno komplikuje życie. Spróbuj zmienić umiejętności Daniela (całkiem prawdopodobne zjawisko, ludzie się uczą) albo utworzyć nową osobę z nowym zestawem umiejętności. Modyfikacja istniejących i pisanie nowych klas - jak dla mnie spore utrudnienie.

Na dobrą sprawę wątek powinien trafić do przedszkola, bo mówimy tutaj o absolutnych podstawach OOP, tj. o wydzielaniu i modelowaniu prostych struktur danych i ich wzajemnych relacjach.

bla bla bla to nie pisz klas wcale skoro to dla ciebie takie utrudnienie.

to jak pisze np FileBuffer czy cos i to ma rozne funkcje to tez zamiast utworzyc normalne metody mam utworzyc kolekcje obiektow przechowujacych po jednej czynnosci?

ty NIE WIESZ jaki model obrał sobie ten czlowiek wiec nie mów że jest błędny. Nie wiesz czy ten typ w ogole chce implementowac dowolnych ludzi w swoim programie. Daniel NIE STWIERDZIŁ że chce zaimplementować system ludzi ala sims. Jak tak stwierdzi to twoje stwierdzenie nabierze sensu. Wtedy bedzie jak najbardziej prawidłowe. Wtedy to bedzie bardzo ciekawy wzorzec umozliwiajacy przypisywanie roznych skilow roznym osobom, wymiennie.

Jak zajdzie potrzeba zmian to kolega sobie to zrefaktoryzuje i juz. Idąc twoim tokiem myslenia trzeba by bylo dodac wszystko co sie moze przydac kiedys za 20 lat do tej klasy. A moze przegladarka www sie przyda temu czlowiekowi? ziuuu - i dodajemy. a moze botnet bedzie nam za 10 lat potrzebny - uuu trzeba zaimplementowac zanim sie uzyje klasy.

Poza tym czy nie moge powiedziec ze samochody Audi mają fajny wygląd i dobrze sie nimi jezdzi?
odnoszę się w tym momencie do klasy carFromAudiFactory rozszerzającej Car. Nie mówie że TEN samochód ma fajny wygląd i sie dobrze nim jezdzi tylko że TE (Ten rodzaj jakim są samochody wyprodukowane przez markę audi) samochody mają fajny wyglad i sie nimi jezdzi.

i zebys mi nie wciskal ze to bledne uzycie potocznego jezyka - przyklad z Car i klasą dziedziczącą VolvoCar byl w ksiazce fowlera refaktoryzacja...

@Orzeszekk

Twoje uwagi w stosunku do Crozina mają się nijak do tematu, a założenia że klasa Daniel powinna dziedziczyć po klasie Human są idealnym przykładem, jak dziedziczyć się nie powinno.

Po pierwsze jak wspomniano wyżej Daniel to imię, a nie rodzaj człowieka, więc jakakolwiek wymiana rodzic - dziecko tutaj nie powinna mieć w ogóle miejsca.

@daniel1302

Zawsze możesz wszystko rozdzielić na kilka interfejsów, nic nie stoi na przeszkodzie.

Orzeszekkk... przecież to teraz Ty strasznie mieszasz! ;o

Własnie o to chodzi - teoretycznie można zrobić sobie klasę VolvoCar. W klasie VolvoCar miałbyś pewnie pole "model". Bo jest wiele aut Volvo o różnej nazwie modelu.
Ale klasa "OsobaDaniel" to co innego. To jest po prostu nielogiczne, żeby tworzyć dla konkretnej osoby (czytaj: dla konkretnego MODELU samochodu Volvo) osobne klasy! I co, autor będzie musiał tworzyć dla każdej kolejnej osoby osobną klasę? ;> Gdzie tu logika? (już widzę ten folder Human\Daniel,Iwona,Ania i tu milion kolejnych imion )

Jak tam sobie chcecie. Dla mnie nielogiczne jest zeby zamiast utworzyc relacje rodzic dziecko opakowywac pojedyncze metody w obiekty.

Daniel moze byc rodzajem czlowieka, to juz zalezy jaki punkt widzenia sobie przyjmie autor modelu. To co, jakbym nazwał klasę Daniel klasą HomoSapiens to juz byloby poprawnie? to jest jakies duze nieporozumienie.

Moze (nie ujmując Danielom, podążając za horoskopami) kazdy daniel to swir i ma zawyzony wspolczynnik inteligencji? wtedy co? tworząc kolejnych danielów musze pamietac o ile im podniesc wspolczynnik inteligencji? czy nie naturalniejszym sposobem jest utworzenie klasy daniel ktora w konstruktorze przemnozy IQ bazowe przez to zawyzenie?

Co jezeli fabryka volvo wytwarza swoje samochody najnowsza technologia, a fabryka chinaszajs rzezbi swoje auta w drewnie? kompletnie inny proces produkcyjny - ten sam interfejs -> metoda szablonowa tak czy siak nową klase wypadaloby zrobic, niby mozna wydzielic z tego klasę ProductionProcess i dawac ją jako parametr klasy FabrykaSamochodow ale to nadal wymaga utworzenia nowej klasy przy dodaniu kolejnej fabryki.

Co jezeli Darek znacząco rozni sie dzialaniem od Izy?

jezeli ktos chce traktowac metody jak atrybuty to niech przerzuci sie z php na python

jak dla mnie sensowne jest utworzenie klasy volvocar, a nastepnie nawet klas volvoX40, volvoS60 - w koncu to są wzorce (modele) tych samochodów -> obiektami będą już konkretne samochody jezdzace po ulicy przy czym bedzie kilka milionów obiektów klasy volvoS60 - beda to konkretne auta jezdzace po ulicy. ale to volvoS60 jest typem samochodu.

to co piszecie to jest kompletne zaprzeczenie dziedziczenia jakiego uczono mnie na studiach / w kursach / wszędzie. Klasa - szablon. Obiekt - gotowy egzemplarz zyjący wlasnym zyciem.

Zacznijmy od tego, że to że Daniel to świr i ma nie wiadomo jakie umiejętności - To tylko właściwości obiektu klasy Człowiek.



Samochód stworzony z drewna czy ze stali nierdzewnej to już inna działka, bo wtedy to byłyby klasy osobne DrewanianeAuto, MetaloweAuto, PapieroweAuto, które mogłyby dziedziczyć po AbstrakcyjneAuto, z abstrakcyjną metodą buduj.



W takim razie albo źle uważałeś na kursach, albo wykładowca sam źle dziedziczył, ale umysłowo.

Dalej to co mówisz jest nielogiczne. Z tego by wynikało, że każdy Daniel ma to samo IQ...
Czemu upierasz sie przy czymś takim, zamiast po prostu:
Czlowiek czlowiek = new Czlowiek();
czlowiek.setImie("Daniel");
czlowiek.setIq(120);
?
Jak dla mnie to jest po prostu naturalne.

Przykład z samochodami zachodzi niestety za daleko. Nie wiadomo jak chcesz je modelować.

Czy volvo s60 jeździ inaczej od x40? I czy dlatego powinny być osobnymi klasami?
Odpowiedź na peirwsze pytanie jest oczywista: jeździ INACZEJ. Ale zastanów się dlaczego? Ano dlatego, że ma inny silnik i zawieszenie (proszę, nie wnikajmy w większe szczegóły - nie w tym rzecz).
Dlatego na etapie produkcji auta - czyli w czasie tworzenia obiektu "wkładasz" do niego konkretny silnik (setSilnik) i zawieszenie (setZawieszenie). Ale metoda do wyliczania "osiągów" fury będzie taka sama dla x40 i s60. Wynik oczywiście będzie inny, bo metoda ta korzysta z danych silnika i zawieszenia - uwzględnia je przy obliczeniach.
I z tego wynika, że nie, s60 i x40 nie muszą być osobnymi klasami.

Ps. co to za studia? We Wrocławiu uczą inaczej

umiejetnosc jest metodą a nie polem chyba ze uzywamy języka na prototypach

nie mozliwe zeby tyle ludzi na raz sie pomylilo wiec najprawdopodobniej zafiksowaliscie sie na jakims niefortunnym zdaniu i nie chce wam sie przeczytac calego posta np to:

Z tego by wynikało, że każdy Daniel ma to samo IQ... < jakim cudem skoro napisalem ze mnozymy przez mnoznik specyficzny dla daniela?
__construct(IQ)
{
$this->IQ = IQ*self::mnoznik;
}

ew.
{
$this->IQ = IQ*$this->getMnoznik();
}

studia lublin, ale przedmiot inzynierie oprogramowania akurat zrobilem w danii bedac na wymianie wiec pretensje do duńca mającego firmę obslugujaca dunskie systemy lotnisk ktory nam to wykladal. z pewnoscia byl chory umyslowo i niedouczony.

przyklad z zycia wziety: mam klase PhotoUploader ktora calosciowo odpowiada za upload obrazka, obciecie uzytkownikowi limitów etc.
moze rowniez ona zmniejszyc zbyt duzy obrazek.

Wprowadzam sobie zalozenie ze wszystkie avatary maja miec po 200 px.

wiec uploadujac kazdy avatar ktorych mam kilka dla roznych obiektow na stronie mam pisac new PhotoUploader(200,200) lub PhotoUploader(Avatar_Width, avatar_height) ?

Ja to wole zrobic prosciej: class AvatarUploader{ public function __construct() { parent::__construct(avatar_width, avatar_height) } }

Im mniej parametrow tym lepiej. Biore klase avatarUploader za kazdym razem gdy potrzebuje wrzucic obrazek i nie musze pamietac co wpisac w parametry by dzialalo ok.

Dlaczego metodą? Może być równie dobrze obiektem klasy Umiejętność. Dlaczego upierasz się przy swojej racji i tłumaczysz wszystkim dookoła, że to my mamy coś nie równo, zamiast dać coś komuś wyjaśnić i pomyśleć trochę LOGICZNIE.

dlatego ze nie ma sensu strzelac do muchy z armaty? nie wiemy jaki model chce sobie zrobic autor, jak stwierdzi ze mu potrzeba takiego systemu z wymiennymi umiejetnosciami to go uzyje jak nie to walnie dwie metody i tez bedzie si. A moze dlatego ze nie jest powiedziane ze mozna to zrobic na jeden sposob a tylko wasz jest prawidlowy a wszystkich ktorzy robia to inaczej trzeba spalic na stosie?

Jak dziedziczyc taki zestaw umiejetnosci? musze miec metode ktora tworzy jeden zestaw i druga ktora go dekoruje wy powiecie ze to fajne a ja powiem ze to dzialanie naokoło. i kto ma racje?

a poza tym bez takich najpierw stwierdziles ze wjezdzam na crozina, pozniej wjechales na mnie i na mojego wykladowce a teraz oceniasz moj sposob myslenia nie doszukuj sie podtekstów agresywnych w dyskusji, zreszta z mojej strony eot po z tego co widze zaraz posypia sie wrzuty na moje miasto.

Na Ciebie nigdzie nie wjeżdżam więc przestań zmyślać, a ironię w stosunku do twojego wykładowcy niestety źle przyjąłeś.

Ale tutaj nie ma znaczenia jaki model przybierze sobie autor tematu, spytał o prawidłowe programowanie obiektowe, więc takie mu przedstawiamy.

Co do twojego PhotoUploader - Uploader zdjęć nie powinnien IMHO się zajmować skalowalnością zdjęć czy też ich nazwą, rozmiarem czy rozszerzeniem, bo to już należy do innej klasy.

Dokładnie tak się powinno trworzyć aplikację. Uelastycznianie na wyrost to poważny błąd. A co jeśli w aplikacji będzie 4 aktorów o różnych imieniach i przez kolejne 10 lat nic poza tym ? Myślenie o elastyczności w takim przypadku nie ma sensu. Macie wszyscy po trochu racji, ale jak zwykle na tym forum.. eh nie ważne.
Każdy z was mówi o nieco innych przypadkach i podejściach. Najlogiczniejsze jest dla mnie to co pisze Orzeszekk. Dziedziczenie jest użyteczne, przy komplikowaniu się kodu w którym jest ono używane - należy go refaktoryzować w celu stosownia np. Strategii, ale nigdy tych czynności nie należy robić zbyt wcześnie ponieważ elastyczność potrafi niepotrzebnie skomplikować projekt.

A poza tym nie ma wiedzy jedynie prawdziwej, biorąc pod uwagę fakt oszczędzania czasu i nie marnowania go na "kombinatorykę elastyczną" - należy pójść na początku po najmniejszej linii oporu Orzeszka, jeśli zajdzie potrzeba użyć rozwiązania Crozina lub zupełnie innego, bo można ten apsekt zaprogramować na dziesiątki sposobów. Będzie to zależeć od wymagań jakie postawi nam dalszy rozwój aplikacji. Jeśli Crozin na początku zaczniesz wszystko uelastyczniać na "wydaje mi się" - możesz się zakopać w swoich kombinacjach i gdy przyjdzie czas na wdrożenie czegoś nowego okarze się, że tak uelastyczniłeś system, że stał się nieczytelny i trudny w rozwoju. Niekoniecznie to co napisałeś musi być jedynie prawdziwe i poprawne. Znajde Ci 10 sposobów różnych na to jak sprawić aby to rozwiązanie Człowieka było elastyczne i przygotowane na ewentualnie - każdą zmiane - ale takie myślenie nie ma zupełnie sensu, jest alogiczne, bo który sposób wybierzesz ? A jeśli strategia którą wybierzesz okarze się nieużyteczna i błędna to będziesz musiał zmienić większą ilość kodu niż przed wprowadzeniem strategii. Z elastycznością czeka się do ostatniego momentu - nigdy nie robi się tego na samym początku projektowania. Tak podpowiada mi moje doświadczenie.

@Orzeszekk:

[PHP] pobierz, plaintext 
class Human {}
 
class Dog {}
 
class Rottweiler extends Dog {} // to ma sens!
 
class Daniel extends Human {} // to nie ma sensu bo:
 
class Daniel extends Dog {} // cannot redeclare bla bla bla
 
class Daniel_Kowalski extends Daniel {} // 
[PHP] pobierz, plaintext 

- i pewnie dlatego olbrzymia większość aplikacji webowych nadaje się tylko do przepisania od nowa a jakiekolwiek poprawki zamieniają się w dochodzenie jak w aferze FOZZ.


Chyba niewygodne bo na pewno nie nielogiczne, zaraz dojdziemy do paranoi, że wystarczy jedna klasa na wszystko
Jako przykład podam formularz - formularz to obiekt, który składa się z innych obiektów (typu textarea) natomiast te obiekty nie mogą dziedziczyć po formularzu, bo to bez sensu (będą miały metodę setPOST albo setGET?) - mogą co najwyżej dziedziczyć po klasie "element formularza" zbiór odpowiednich metod (np. setLabel) wspólnych dla nich wszystkich. I to ma sens - tworzę sobie obiekt "checkbox", ustawiam mu różne właściwości a potem dodaję do obiektu "mój formularz" - co w tym nielogicznego? To na czym niby ma polegać programowanie obiektowe?

Jak komuś nie pasują obiekty to niech wróci do strukturalnego kodu - pisze się go szybciej i linijek dużo mniej. Zresztą rozsądnie napisany kod strukturalny jest dużo lepszy od "obiektowej" sieki, która tylko tym się różni od strukturalnego kodu, że jest upakowana w klamrę z napisem "class" z przodu.

@Pilsener
Nie zrozumiałeś mnie. Zdarzyło Ci się kiedyś przepisywać zbyt elastyczny kod obiektowy ? Mi tak. Przepisywałem też wiele "kodów proceduralnych". Trzeba umieć znaleźć złoty środek i nie robić niczego na wyrost zarówno w podejściu proceduralnym jak i obiektowym. O to mi tylko chodziło. Projektowanie i implementacja powinny iść za wymaganiami, a nie na odwrót. Wielokrotnie zastosowałem jakiś wzorzec zbyt wcześnie. Fan wzorców to wada, a nie zaleta. Ortodoksja w obiektowości jest tak samo zła jak w podejściu proceduralnym.

Jeśli same imiona będą wyróżnikami zupełnie innej roli klasy to dlaczego nie możnabyłoby nazywać klas imionami ? Zakładam sytuację, że są 3 osoby w grze komputerowej. Każda z nich ma imiona. Daniel - gotuje, myje okna, daje jedzenie psom na podworku. Ania - myje okna, wyrzuca smieci, odkurza, Krzysiek - myje podlogi, wyciera kurze. Jak widzimy każda z tych osób to zupełnie inna rola (dziedzinowa) w aplikacji. Jeśli założymy, że w naszej grze w pierwszej wersji nie ma możłiwości wymiany rolami między osobami po co robić osobne interfejsy i uelastyczniać ? Na co uelastyczniać ? Oczywiście tworzenie obiektów osób w takiej sytuacji jest dziwactwem, ale nie trzeba tego robić można przecież zrobić: Krzysiek::umyjPodloge(). Odrazu widzimy w kodzie Kto i Co. Na takim etapie rozwoju programu elastyczność jest bezużyteczna. Jeśłi natomiast chcielibyśmy aby nagle Krzyś również mógł robić to co Ania - wtedy dopiero elastyczność ma sens i można zastosować to co pisał Crozin i inni.

Zgadzam się z LSM, że myślenie 'na przyszłość' jest zgubne, ale pod warunkiem, że rozważasz rozwiązania, które przypuszczasz, że kiedyś, może zostaną zaimplementowane. Wtedy nie implementujesz setek wzorców itp. tylko po to, żeby można było zrobić z tym wszystko, co ci się żywnie podoba, tyle, że w przyszłości, implementując rzeczy, których możesz nigdy nie implementować, ponieważ twoje przewidywania były błędne.
Co do rozwiązania Crozina, to nie jest ono 'nad wyrost', robienie czegoś poprawnie, nie jest wprowadzaniem nadmiernej elastyczności.

Co do klasy Damian, to:
Z wikipedii:

i mamy dalej:


Czyli klasa definiuje atrybuty i zachowanie obiektów, ale dopiero przy ich tworzeniu określamy ich stan.
Rozumiem, że klasa Damian dziedziczyłaby po klasie Człowiek tyle, że ustawiałaby jakieś domyślne wartości, tak? No to się to trochę kłóci z powyższymi.

Programowanie obiektowe zostało wymyślone w celu jak najdokładniejszego odwzorowania rzeczywistości.
Załóżmy więc, że Damian to model. W takim wypadku, czym są jego instancje? Damian1, Damian2 itp.? Nawet jeżeli każdy Damian jest rudy, sympatyczny i nieprzeciętnie inteligenty, to czy oznacza to, że mamy do czynienia z nowym człowiekiem? Wątpię

Jeżeli już koniecznie chcesz robić coś takiego, to możesz stworzyć jakąś fabrykę, która zwraca ci obiekt klasy Człowiek z odpowiednimi ustawieniami (czyli umiejętnościami, imieniem, IQ i wszystkim innym, co tylko chcesz).
Takie samo rozwiązanie zastosowałbym do przykładu, który przedstawił Orzeszekk (z klasą AvatarUploader). Tutaj też rozwiązaniem byłaby fabryka.
Bo tworzenie dziedziczenia tylko i wyłącznie po to, żeby klasy od razu miały ustawiony szereg odpowiednich wartości jest bez sensu i nie jest poprawne, nie ważne czy uczy tego Duńczyk, Holender, Polak, czy wiesz to z tutoriali. Bo w takim wypadku dojdziesz do skrajności, gdzie dla każdego zestawu danych będziesz miał osobny obiekt?

Dziedziczenie powinno rozszerzać funkcjonalność i wtedy ma ono sens. Jeżeli służy tylko do ustawiania wartości, 'bo taki zestaw danych jest często używany' tzn. że mamy do czynienia z błędnym rozumieniem dziedziczenia.

A co do pytania głównego, to tutaj pisałem trochę na temat tego, kiedy interfejs a kiedy klasa abstrakcyjne. W Twoim wypadku, uwzględniając tylko te informacje, które przekazałeś i nic więcej (bez przypuszczeń), to interfejs jest Ci nie potrzebny, wszystko ląduje w klasie abstrakcyjnej.

Może opiszę projekt dokładniej. Tworzę algorytm gry w pokera.
Każda osoba gra inaczej, jedna lubi ryzykować bardziej druga mniej, jedna osoba przewidzi 1 ruch do przodu, inna 3 lub 4... I tutaj potrzebowałem waszej pomocy. Jako, że uczę się Assemblera(narazie na uC z rodziny '51(Philips 8051)) w szkole, a PHP zajmuje się od jakiś kilku lat to postanowiłem najpierw napisać go w PHP a potem spróbować przepisać do Assemblera z podziałem na biblioteki(coś `ala klasy), a wasz sposób myślenia nie jest tak prosto zaimplementować w języku programowania tak tak niskiego poziomu. Mając do dyspozycji 128 bajtów pamięci RAM i 2 kb pamięci EEPROM co najwyżej mogę pomarzyć. Miałem 4 kb EEPROM lecz 2 KB zajęte są przez biblioteki.

Dziękuję za odpowiedzi. Napewno się przydadzą

No to możesz to zrobić w taki sposób:

[PHP] pobierz, plaintext 
$menadżerGraczy = new MenadżerGraczy();
 
$damian = new Gracz('Damian');
$damain->przewidywaneRuchy(3);
$damian->współczynnikRyzyka(0.6);
$damian->umiejętnośćBlefowania(0.1);
 
$krzysiek = new Gracz('Krzysiek');
$krzysiek->współczynnikRyzyka(0.95);
$krzysiek->umiejętnośćBlefowania(0.25);
 
$menadżerGraczy->dodaj($damian); // można jeszcze dodać klucz gracza: $menadżerGraczy->dodaj('Damian', $damian);
$menadżerGraczy->dodaj($krzysiek);
 
// ...
 
$gracze = $menadżerGraczy->znajdźRyzykantów(); // zwraca tych mających współczynnik ryzyka > 0.5
$gracz = $menadżerGraczy->znajdź('Damian');
[PHP] pobierz, plaintext 

Łatwo, wygodnie i sensownie. Jak widać w tej sytuacji obiekt gracza jest dosyć prosty.

Co do przepisywana tego do języka asemblera... nie bardzo się da. Tego ustrojstwa używa się gdy nie można sobie pozwolić na ekstrawagancje w postaci języka wysokiego poziomu.

Dziękuje, temat jest dosyć wyczerpujący. Assembler jest bardzo logicznym językiem. Wszystko opiera się tylko o 3 komendy(70% uzywanych komend w programie): MOV, CJNE, DJNZ

Jeśli chcesz to przepisać na assemblera, to nie lepiej użyć C do zaprogramowania mikroprocesora ? Będzie łatwiej choć nie wiem jak zasobami...