[OOP] Design Animal

Shinji, on 12 august 2019 - 18:22, said:

Nu o sa faca parte, easy.
In clasa animal vei avea metode comune tuturor animalelor, cele care au un comportament diferit in functie de tipul animalului ramanand abstracte.
Mai departe extinzi clasa Animal cu ce ai tu nevoie.

Asta cu metode pe care o parte le implementam, altele nu ca nu au treaba cu ce avem noi dar sunt in clasa de baza e o eroare de conceptie.

Edited by sftpdt, 12 August 2019 - 19:40.

sftpdt, on 12 august 2019 - 19:37, said:

Nicidecum pt asta sunt clasele abstracte care contin metode abstracte si metode ne-abstracte.Astfel de clase actioneaza ca routere  de business-logic, dar si ca huburi de flow-uri ale business-logicului.Pentru asta sunt facute.
In astfel de clase pot sa despart business-logicul in mai multe magistrale de flow-uri si astfel clasa se comporta ca o functie demultiplexare sau pot sa cumulezi mai multe flowuri de business-logic,caz in care se comporta ca  o functie de multiplexare.

Ceea ce te numesti eroare de conceptie este de fapt functia de multiplexare sau demultiplexare a magistralelor unui business-logic. Functii vitale pt proiectarea unui sistem software.

@Shinji

class AbilitatiSpeciale {
void danseaza() {
	 //......
}
void clipesteCuUnOchi() {
	 //......
}
}
abstract class Catel extends Animal{
void latra(){
	 System.out.println("ham");
}
}

class CatelSpecial extends Catel{
private Abilitati abilitati;
public CatelSpecial(AbilitatiSpeciale abilitati) {
	 this.abilitati = abilitati;
}
//setters & getters
}

Pentru mai multe detalii studiaza cartile de oop
https://zodml.org/si...sing_Java_0.pdf
https://www.amazon.c...n/dp/0596008678

Dupa ce o sa le studiezi pe amandoua, de abia atunci stii OOP.

Edited by Iulius-Foyas, 12 August 2019 - 20:07.

Iulius-Foyas, on 12 august 2019 - 20:00, said:

Ma refeream ca nu e ok sa ai un obiect caine de tip Animal si sa poti apela caine.zboara() pentru ca este metoda zboara() in clasa Animal.

sftpdt, on 12 august 2019 - 20:24, said:

A , idiomatic ai dreptate , trebuie un nivel intermediar pt special Caine sa zicem.

sftpdt, on 12 august 2019 - 19:37, said:

Si daca am o metoda care este stufoasa de realizat si acea metoda o fac abstracta pt ca este folosita de un tip de animal atunci am urmatoarele optiuni
1.fie scriu o singura data metoda respectiva, pe care o pun intr-o clasa care de fapt extinde clasa Animal si este extinsa de clasa Catel sa zicem(adica imi bag o clasa intermediara
in lantul de derivare al claselor
2.fie deriv direct din clasa Animal si apoi implemntez metoda dintr-o interfata ,ca apoi sa extind clasa Catel

Daca am  niste propietati complexe de implemntat atunci conform, variantei 1 o sa am o multime de clase intermediare  care nu fac decat sa-mi complice inutil codul
sau conform variantei 2 o sa am o multime de interfete aditionale care o sa-mi complice inutil codul

Si atunci ca sa reduc/tai direct tot codul boileplate din ambele variante. scriu in clasa de baza Animal metodele pe care le doresc insa nu le fac abstracte (ca sa nu fiu obligat sa le implementez peste
tot) ci le fac metode normale si apoi in functie de ce clase extinde Animal imi aleg ce metode sa folosesc direct pt acea clasa sau chiar de ce nu ce metode as putea suprascrie.Daca nu doresc sa le
suprascriu atunci le folosesc asa cum sunt definite in clasa de baza fara a fi nevoie de a duplica codul metodei.

In varianta mea cum am spus eu clasa de baza devine de fapt un repository selectiv de metoda.

O alta varianta mult mai buna decat am zis este  aplicarea compozitiei in detrimentul mostenirii
Adica am clasa de baza si apoi toate celelalte propietati speciale le  introduc ca obiecte, prin intermediul compozitiei din constructor.
Insa si aici as avea probleme daca imi trebuie polimorfism la acele propietati speciale. si atunci daca am aplic intai principiul inversarii dependintelor si apoi aplic compozitia
astfel clasa Catel va depinde de niste interfete insa dpdv al principiului Dependency Inversion si nu interfete al compozitiei.
Si uite asa o dam in design-patterns.

Edited by Iulius-Foyas, 12 August 2019 - 20:41.

Imi place ideea sa avem interfete gen Zburator pe care le implementeaza doar animalele care zboara. Asta rezolva eroarea de a avea un caine cu functie zboara().

Insa cum diferentiem actiunile animalelor din aceeasi clasa? In esenta avem doua tipuri de actiuni, cele care tin de natura animalului (e clar ca un urs nu poate zbura) si cele care tin de fiecare animal individual (un urs dresat poate sa danseze, unul salbatic nu).

Iulius a sugerat sa avem doua clase, Catel si CatelSpecial, dar mi-as dori sa exista o singura clasa Catel. Aceasta ar avea desigur toate actiunile specifice oricarui catel plus eventual niste actiuni individuale fiecarui catel (instantei).

Asta sugereaza sa avem o clasa de baza (sau interfata) ActiuneAnimal. Pentru ca limbajul e C++, am sa vb mai mult in termeni de clase. Clasa de baza ActiuneAnimal ar putea fi mostenita de ActiuneRegnAnimal si ActiuneIndividualaAnimal. ActiuneRegnAnimal ar fi mostenita de ActiuneRegnAnimalLatra.

Si atunci clasa Catel ar mosteni (sau implementa interfete) din Animal, ActiuneRegnAnimalLatra, ActiuneRegnAnimalDaDinCoada, ActiuneRegnAnimalFugi etc. In interiorul clasei Catel ar putea exista o colectie (array) de ActiuneIndividualaAnimal care sa fie diferita de la instanta la instanta. De exemplu am putea avea o ActiuneIndividualaCatelStaInDouaPicioare care ar fi o clasa definita in interiorul clasei Catel si pentru ca e la baza o ActiuneIndividualaAnimal ar putea in acelasi timp fi o parte din arrayul de actiuni specifice unui anume catel (unei instante).

Cu aceasta abordare avem insa problema ca putem zice Grivei.Latra() (tine de toti cateii) dar nu putem zice Grivei.StaiInDouaPicioare() (tine de Grivei daca poate sau nu). Putem ocoli asta scriind ceva de genul Grivei.Executa(Latra) si Grivei.Executa(StaiInDouaPicioare).

Edited by Shinji, 12 August 2019 - 20:28.

Pai atunci deja ai  "Inheritance hell" cam ce zici tu pe acolo si atunci in cazul acesta nu mai dezvolti pe mosteniri ci pe compozitie.
"favor composition over inheritance"
https://en.wikipedia...ver_inheritance

Quote

pai n-ai cum, doarece un catel obisnuit nu danseaza si nici nu da din ochi.
CatelSpecial deriva din Catel insa este construit prin compozitie  cu AbilitatiSpeciale.

Edited by Iulius-Foyas, 12 August 2019 - 20:53.

Shinji, on 12 august 2019 - 19:21, said:

Întotdeauna vezi care-i scopul demersului. Poți să faci cazuri particulare până o iei pe câmpii, totuși vezi dacă merită efortul.

La modul practic, prefer ca un programator să nu piardă o săptămână săpând în excepții care nu vor fi folosite niciodată, ci să rezolve problema. Doar dacă e cazul se face refactoring, alți bani, altă distracție. Dar doar dacă e nevoie.

Din punct de vedere teoretic, poți să-i implementezi animalului ochi și să poată să fie chior sau orb complet. Valabil pentru membre și organe interne, dacă vrei. Întrebare e - ai nevoie de așa ceva?

Alt aspect, pe clasa Animal nu trebuie să o intereseze ce metodă folosește rața sau pisica, ăsta-i scopul abstractizării.

Shinji, on 12 august 2019 - 20:27, said:

În C++ cu dynamic cast.

Da, e urât, dar asta e.

În alte limbaje cu typesystem mai modern există soluții ceva mai elegante. De exemplu în rust ai traits. Dar nici acolo nu e elegant, însă măcar limbajul evoluează mai rapid.

Oricum ai da-o, soluția care deschide cele mai multe porți și care închide cât mai puține e exact asta: segregarea în interfețe cât mai granulare.

Shinji, on 12 august 2019 - 20:27, said:

Corect, asta e cealaltă abordare curată: extinderea prin adăugare de noi clase, strategy pattern, etc.

Si daca Grivei poate sta in doua picioare insa Azorel nu poate sta in doua picioare doarece nu are aceasta abilitate ?
Strategy Design pattern il aplici doar pe tipuri compatibile si nu asa ca sa scriem cod.

Edited by Iulius-Foyas, 13 August 2019 - 06:00.

Iulius-Foyas, on 13 august 2019 - 05:57, said:

Ok, nu vad de ce ai duce cazuri de genul la nivel de implementare a unor clase. Nu e nevoie sa faci o clasa separata pentru fiecare entitate in parte ca are nu stiu ce proprietati.
Daca ai catei cu diferite afectiuni poti sa tii o lista la fiecare catel cu ce afectiuni/probleme are.

Edited by sftpdt, 13 August 2019 - 08:14.

Quote

Daca sunt din aceeasi clasa, cu ce ajuta dynamic cast? Sau te referi sa faci clase noi gen UrsCareDanseaza?

Shinji, on 13 august 2019 - 08:26, said:

Da, UrsCareDanseaza.

Vino cu probleme reale, și vedem cum pot fi modelate în OOP.

Nu cu animale și alte scenarii fanteziste, ci cu scenarii realiste.

Software este scris în c++ și pus în producție, și evident situația nu e chiar așa de rea, din moment ce oamenii rezolvă probleme reale în c++.


Problema e cu scenariul tău educativ.

Daca ai niste abilitati specifice mai multor animale, creezi clase pentru ele si eventual metode virtuale specifice, care vor fi folosite de clasa concreta a animalului prin extindere sau compozitie(depinde care are sens mai mult). Daca ai niste abilitati sau caracteristici unice unui animal, acestea la pastrezi doar in clasa concreta a animalului respectiv, nu trebuie sa le derivi de undeva. De asemenea, denumirile claselor nu e o obligatoriu(si nici recomandat) sa descrie toate caracteristicile prezente, ci doar sa faca usoara intelegerea cand este vazuta denumirea clasei(adica sa stii cu ce ai de-a face).

sftpdt, on 13 august 2019 - 08:13, said:

ma refeream la metoda .Executa(actiune);
Avem pe Grivei si pe Azorel. Grivei spre deosebire de Azorel mai poate merge in doua labe si poate face cu ochiul(ca e dresat sa presupunem)
si atunci
Grivei.Executa(Latra) si Azorel.Executa(Latra)  este ok , amandoi caini pot latra.
Grivei.Executa(StaiDouaPicioare) merge doarece Grivei este un caine dresat
Azorel.Executa(StaiInDouaPicioare) nu mai mergem doarece Azorel nu are aceasta abilitate.

Cum faci ca pt Grivei sa poti delega actiunea de  "StaiInDouaPicioare"  insa pt Azorel sa nu poti sa deleghezi aceasta actiune doarece Azorel n-o suporta?
Si mai este o chestie Grivei si Azorel nu pot fi instante al acelaiasi clase doarece acestia au abilliati diferite asta inseamna ca  unul din ei (Grivei in acest caz) trebuie sa fie
instanta unei clase compozite("baza" compus cu "abilitati")
https://forum.softpe...8#entry25097102
https://forum.softpe...8#entry25096867

LOLkekLOL, on 13 august 2019 - 14:50, said:

Aceasta metodologie este solutie pt termen mediu si de obicei de uz didactic insa daca in productie ai de  implementat niste propieati complexe care necesita teoretic cam vreo 20 de clase si vreo 10 interfete incepi sa cauti niste design pattern-uri mai avansate bazate insa pe compozitie si nu mostenire.

OriginalCopy, on 13 august 2019 - 14:50, said:

pai si asta este o problema reala, de modelare OOP.

Edited by Iulius-Foyas, 13 August 2019 - 16:17.

Iulius-Foyas, on 13 august 2019 - 16:19, said:

Arunci exceptie.

Edited by sftpdt, 13 August 2019 - 16:51.

Cum ? Ca iti mai trebuie o alta etapa de filtrare cel putin pe baza unei liste sau a unui map.So ?

Edited by Iulius-Foyas, 13 August 2019 - 17:17.

Si apoi nu mi se pare correct sa arunc exceptie doar pt ca am apelat o metoda pe care pot s-o apelez tehnic dar n-am voie pt ca s-a intentionat sa nu fie apelata dar totusi se poate.

Nu, grivei trebuie sa aiba acces fizic la metode care tin de abilitati pe care Azorel sa nu
le poata accesa si atat grivei cat si Azorel sa aiba acces la metodele de baza ale cateilor si atunci suntem OOP complianti

Edited by Iulius-Foyas, 13 August 2019 - 18:38.

public void execute(Action action) throws OperationNotSupportedException {
  if(!canExecuteAction(action) ) {
	throw new OperationNotSupportedException("Action " + action + " currently not supported");
  }
  // do stuff
}

Iulius-Foyas, on 13 august 2019 - 16:19, said:

N-are sens sa expui toate astea prin cate o clasa diferita.
Daca faci un soft pentru un adapost de animale, faci 100 de clase pentru 100 de caini deoarece fiecare difera cu cate ceva de restul? Pentru asta exista campuri intr-o clasa, sa specifici acolo ce caracteristici are fiecare (ziceam mai sus de o lista de afectiuni de ex. daca un caine nu poate merge etc).