come astrarre un problema reale in OOP
f22
da poco studio OOP
mi chiedevo se esistono delle 'best pratices' per approciare ad un
problema reale convertendolo nelle relative entità CLASSI METODI PROPRIETA'.
Esempio
viso che tutti partono dall'esempio MAMMIFERI classe base e poi giu di
li con le classi figlie dove si specificano i vari mammiferi nel
dettaglio...io vorrei seguire un esempio differente.
prendiamo il concetto di DIPENDENTE di un ' ipotetica azienda
tenendo presente che una figura tale deve possedere minimo
nome,cognome,matricola,settore,posizione, e che posso trovare
dall'amministrativo, al magazziniere, al progettista....
io farei in (c#)
enum Settore
{
amministrativo,
progettazione,
falegnameria,
magazzino,
spedizioni
}
enum Posizione
{
operaio,
contabile,
progettista,
magazziniere,
trasportatore
}
Class Dipendente
{
private string nome = "";
private string cognome = "";
private string matricola = "";
private string settore = "";
private string posizione = "";
public Dipendente(string nome,string cognome,string matricola,string
settore,string posizione)
{
this.nome = nome;
this.cognome = cognome;
this.matricola = matricola;
this.settore = settore;
this.posizione = posizione;
}
private void MemorizzaDati()
{
//fai qualcosa;
}
}
come aproccio al problema com'e' ?
un amico con cui studio mi suggeriva di creare una classe BASE e poi
creare una Classe per ogni entità
quindi ad esempio
Class Operaio:Dipendente
{
}
Che ne dite?
grazie
enoquick
L' approccio che hai usato non è sbagliato , ha solo lo svantaggio di
essere poco flessibile in certi casi.
Non solo, le operazioni simili (Es: calcola_stipendio() )
devono essere implementate con tante if quanti sono la tipologia dei
dipendenti e in un programma complesso possono essere sparse per il codice.
Molto meglio è implementare una classe base (magari astratta perchè non
puo esistere un dipendente generico) ,derivare le singole classi tipo
operaio, contabile ,ecc.. e implementare il metodo calcola_stipendio()
in ogni singola classe; in piu implementare gli attributi specifici
per ogni singola classe.
Naturalmente il metodo calcola_stipendio nella classe dipendente sarà
astratto perchè non ha senso calcolarlo.
L' attributo Settore può essere un' enum se è un attributo passivo, e a
dire il vero, la stessa cosa puo anche essere Posizione se fosse
passiva ed ogni tipologia di dipendenti non avesse attributi aggiuntivi.
In sostanza l' implementazione dipende tutto dal problema che devi
risolvere.
f22
p.s. quindi nella classe base ad esempio potrei implementare un metodo
Virtual per calcolare lo stipendio ad esempio e poi in ogni classe
derivata fare un ovveride sul medesimo metodo?
grazie!
enoquick
[CUT]
>
> p.s. quindi nella classe base ad esempio potrei implementare un metodo
> Virtual per calcolare lo stipendio ad esempio e poi in ogni classe
> derivata fare un ovveride sul medesimo metodo?
Esattamente:
in c++ si usa la parola 'virtual' per enfatizzare questi metodi,
ma il nome generico è metodi astratti
Una classe che abbia almeno un metodo astratto è anch' essa astratta, ma
in c++ 'virtual' per una classe è un' altra cosa (da non confondere).
Andrea Laforgia
<enoquickNOSPA...@gmail.com> wrote:
>in c++ si usa la parola 'virtual' per enfatizzare questi metodi,
>ma il nome generico è metodi astratti
>Una classe che abbia almeno un metodo astratto è anch' essa astratta, ma
>in c++ 'virtual' per una classe è un' altra cosa (da non confondere).
In C++, i metodi astratti sono quelli virtuali puri, che rendono per
conseguenza la classe astratta.
enoquick
Si, scusami , è un po di tempo non uso C++ e ho fatto una leggera
confusione.
Per non confondere f22:
virtual - metodi a binding dinamico Es: virtual int calcola()
=0 - metodi astratti Es: int calcola()=0
Andrea Laforgia
<enoquickNOSPA...@gmail.com> wrote:
>Si, scusami , č un po di tempo non uso C++ e ho fatto una leggera
>confusione.
>Per non confondere f22:
>
>virtual - metodi a binding dinamico Es: virtual int calcola()
>=0 - metodi astratti Es: int calcola()=0
Ahem... NO.
Come dicevo nel messaggio precedente, i metodi "astratti" in C++ sono
quelli VIRTUALI puri. La scrittura corretta č:
class Pippo {
public:
virtual void metodoAstratto() = 0;
};
La scrittura senza "void" provoca un errore in compilazione e il
motivo č chiaro: non essendo il metodo virtuale, non si potrebbe fare
l'override nelle classi figlie e quindi definire un comportamento.
enoquick
Ok, vada per il virtual (piccola semantica del C++ )
virtual int calcola()=0 //metodo astratto
Andrea Laforgia
> Ok, vada per il virtual (piccola semantica del C++ )
Che intendi per "piccola semantica del C++" ?
La semantica del C++ ha un senso preciso e concreto. Ho già spiegato il
senso di quel "virtual".
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
enoquick
> enoquick ha scritto:
>
>> Ok, vada per il virtual (piccola semantica del C++ )
>
> Che intendi per "piccola semantica del C++" ?
> La semantica del C++ ha un senso preciso e concreto. Ho già spiegato il
> senso di quel "virtual".
>
Nel senso che si tratta solo di semantica,
non altera il significato del discorso
Andrea Laforgia
<enoquickNOSPA...@gmail.com> wrote:
>Nel senso che si tratta solo di semantica,
>non altera il significato del discorso
Tanto per chiarire: non è SOLO semantica, perché la semantica è tutto,
non può essere "SOLO semantica". Se parli di metodi astratti in C++,
stai parlando di metodi *virtuali* puri. E c'è un significato preciso
del fatto che questi metodi debbano essere virtuali. Non è che puoi
dire "vada per il virtual", come se fosse una concessione
straordinaria. Il "virtual" va usato e basta.
Scusa la pignoleria, ma temo che le tue parole possano essere
fuorvianti per chi ti legge.
enoquick
Quello che volevo intendere non è certamente per declassare il C++
o non renderlo un linguaggio importante.
Semplicememente volevo intendere che i concetti OO sono indipendenti dal
linguaggio.
Ciao