Newsgroup: it.comp.programmare
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

 creare una Classe per ogni entità
Il suggerimento non e' sbagliato.
Ma, considerando che la situazione da te ipotizzata, normalmente deve 
rispecchiare un database gia' esistente, le tue classi dovranno 
semplicemente rispecchiare la struttura del database.

Roberto Montaruli ha scritto:

ti ringrazio per la pronta risposta
quindi mi consigli di rimodulare il costruttore, prevedendo come 
parametri obbligatori, quei dati che appunto restano costanti nel tempo.
p.s. l'accesso al database in C# non è ancora fra le mie conoscenze 
purtroppo, l'unica esperienza in merito l'ho maturata con php ma li tra 
l'altro era un approccio classico non OOP.
buon lavoro!

immutabili.
Scusa ma dove sta scritto? il costruttore può accettare benissimo
anche dati opzionali e mutabili. Il *costruttore* accetta tutto ciò
che è utile a *costruire*. Più che altro, non si deve progettare
classi che mappano stati temporanei (come Studente e Lavoratore,
perché in qualunque momento uno Studente potrebbe trasformarsi in un
Lavoratore).

l'altro era un approccio classico non OOP.
Se ti può essere d'aiuto, guarda l'
ADO.NET
 Entity Framework.

 Settore e posizione possono cambiare nel tempo.
Sono curioso...quali sarebbero i vantaggi di questa tua personalissima 
regola?

 Roberto Montaruli ha scritto:


Il vantaggio e' nella leggibilita' del codice.
Inoltre vengono messe in evidenza immediatamente le chiavi primarie sul
database (visto che il caso in questione generalmente ha un database
sotto).
Il costruttore assegna i valori fissi dell'oggetto.
I valori variabili verranno poi assegnati usando le specifiche proprieta'
pubblicate.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 p.s. l'accesso al database in C# non č ancora fra le mie conoscenze 
Un database non deve essere necessariamente un DB, puo' benissimo essere
anche un file di testo, tanto il concetto non cambia dal punto di vista
del tuo programma: cambieranno le prestazioni, ma finche' si tratta di
gestire un centinaio di record al massimo...
Prevedi dei metodi per leggere, scrivere, modificare e cancellare un
record, poi ci penserai dopo come implementare e in funzione di che cosa.


anche un file di testo
Se vuole imparare a usare i DB, che usi i DB e non si arrabatti coi
file di testo.

Il vantaggio e' nella leggibilita' del codice.
Ma che stai dicendo...
Quando si scrive un software bisogna considerare gli aspetti pratici
essenziali. Se ci vogliono diversi costruttori, che si scrivano
diversi costruttori. I tuoi "precetti" sono assurdi.
La leggibilità non discende da QUANTO codice viene scritto, ma da COME
lo si scrive. 

 Che ne dite?
Nella pratica, probabilmente vorrai eliminare queste due enumerazioni ed 
appoggiarti ad un paio di tabelle di database (se prevedi di usarlo, 
s'intende), di modo che non ti tocchi mettere mano alla classe se per 
caso aggiungono la posizione "sguattero": lo aggiungono loro nel DB e 
buona notte al secchio.
Per quando riguarda la disputa sui costruttori, tenderei a dare ragione 
ad Andrea. In fondo, un costrutture serve principalmente ad 
inizializzare una classe prima di usarla: il fatto di poterla 
inizializzare in modi diversi (leggi "sfruttando l'overloading dei 
costruttori") mi sembra un vantaggio.
IMHO, naturalmente.
S.

buona notte al secchio.
Questo può valere per gran parte delle enumeration che rappresentano
dati "opachi" per l'applicazione. Se invece l'applicazione deve essere
al corrente (pessima traduzione di "aware") di certi valori, allora la
tecnica che adotto è che la tabella esiste comunque, con tanto di FK
sulla tabella collegata, e l'enumeration a livello applicativo...
...pure. Se dovessi fare una scelta, ovviamente eliminerei la tabella
e non la enumeration (essenziale per l'applicazione). Però può valer
la pena tenere comunque la tabella a scopo documentativo per chi
guarda il database.

 lo si scrive. 
E anche da QUANTA GENTE ci deve mettere mano. Un po' di limitazioni alla 
radice impediscono a chi deve metterci mano di spaziare un po' troppo e 
attenersi a quello che c'e'.
Stiamo parlando di software aziendale, non del programmino fatto nel 
tempo libero che uno ci tiene a scriverlo bene.
Il software aziendale deve essere chiaro, semplice, robusto e facilmente 
modificabile. Nessuno pretende che sia anche performante: e' gia' troppo 
richiedere che funzioni.

 file di testo.
Non ha detto che vuole imparare ad usare i DB.
Ha detto che voleva creare una classe orientata ad una situazione piu'
concreta.
Sono io che gli ho fatto notare che una classe che rappresenta dei
dipendenti di azienda ha sotto di se' un DB.
Per operare con una classe che rappresenta un dipendente, anche leggere da
un file di testo va bene: il suo problema e' lavorare con la classe.
Quando comincera' ad avere bisogno di interfacciarsi con un DB allora
scrivera' codice per interfacciarsi con un DB.
Procedendo un passo alla volta non si rischia di andare a sbattere.


 richiedere che funzioni.
Quando io parlo di software, ho in mente solo quello scritto a livello
professionale. Non sprecherei energie a discutere della rubrichetta fatta
in casa. C'è solo un modo per scrivere il software aziendale perché
funzioni e sia manutenibile: scriverlo bene. E per scriverlo bene, bisogna
adottare tutte le tecniche di progettazione del caso (compresa quella di
prevedere tanti diversi costruttori, se la loro esistenza ha un senso o
potrebbe averlo in futuro). E poi, che diavolo c'entrano le performance
ora? Quello che dici - tanto per cambiare - è molto lontano dal vero.
Forse tu lavori in un contesto in cui la gente si accontenta e forse per
il TUO software è già troppo richiedere che funzioni. Io lavoro in
contesti in cui i parametri da tener presente sono innumerevoli, comprese
le performance (che nel software aziendale, in generale, hanno di solito
un ruolo chiave).
Non fare per cortesia delle TUE regole, le regole di tutti.


 Non ha detto che vuole imparare ad usare i DB.
Irrilevante. Vuoi che riformulo la frase? Se gli consigli di usare un DB,
consigliagli di usarne uno vero. Sveglia, non siamo più negli anni '80.


 consigliagli di usarne uno vero. Sveglia, non siamo più negli anni '80.
E infatti si vede che non siamo piu' negli anni 80! Molti hanno perso di
vista i fondamenti, e i nuovi neanche sanno piu' che cosa sono i
fondamenti.
E il file di testo e' ancora oggi lo strumento per far migrare
informazioni da un sistema ad un altro, e che ti piaccia o no, un file di
testo bisogna saperlo ancora maneggiare, leggere, scrivere, interpretare.


 potrebbe averlo in futuro).
[snip]
Sono d'accordo con quanto scrivi.
Vorrei solo precisare una cosa, visto che stiamo cercando di dare dei 
suggerimenti di buona programmazione: è bene stare attenti a scrivere 
codice che "si pensa possa essere utile in futuro", perché spesso si 
tratta di lavoro inutile.
Purtroppo la nostra capacità di prevedere cosa potrà esserci utile in 
futuro è limitata.
Questo, naturalmente, non va confuso con l'obiettivo di creare del 
codice flessibile, inteso come codice che possiamo modificare con la 
massima facilità possibile.
S.

testo bisogna saperlo ancora maneggiare, leggere, scrivere, interpretare.
Quello che stai dicendo non ha alcun senso e non trova alcuna
collocazione nella discussione.

tratta di lavoro inutile.
Non si tratta meramente di "scrivere codice", ma di "progettare una
classe". Un programmatore esperto sa bene quali sono le tecniche da
adottare per delinare un'interfaccia che si adatti bene agli sviluppi
futuri (questo, paradossalmente, significa proprio far sì che non si
produca troppo codice), mentre un novizio tende a sovraingegnerizzare.