Newsgroup: it.comp.programmare.win32
Titolo: come astrarre un problema reale in OOP

ciao
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

f22 ha scritto:

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.

enoquick ha scritto:

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!

 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).

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.

Andrea Laforgia ha scritto:

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

=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.

Andrea Laforgia ha scritto:

Ok, vada per il virtual (piccola semantica del C++ )
virtual int calcola()=0    //metodo astratto

 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

 
Nel senso che si tratta solo di semantica,
non altera il significato del discorso

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.

Andrea Laforgia ha scritto:

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