Re: come astrarre un problema reale in OOP

Andrea Laforgia ha scritto:
> On Wed, 02 Jul 2008 14:23:30 +0200, rmontaruli@yahoo.com (Roberto
> Montaruli) wrote:
>
>> 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.

Io insisto col mio punto di vista.
Qui non stiamo parlando di una classe "general purpouse" dalle decine di
applicazioni, dalla quale far derivare centinaia di oggetti piu'
complessi, e per la quale e' opportuno definire tanti costruttori quanti
ne vengono in mente (e ne manchera' sempre uno).

Qui stiamo parlando di una classe per incapsulare QUEL database, fatto
con QUEI campi, e basta!

Quindi, o possiedi una classe generica dalla quale far derivare quello
che ti serve, e sfruttare i costruttori esistenti, o ti scrivi dal nulla
una classe ricalcando le proprieta' dai campi del db e nel qual caso un
costruttore o al massimo due bastano e avanzano.

Poi se a te piace dichiarare tanti costruttori quante sono le possibili
combinazioni di tutte le proprieta' da inizializzare in fase di
costruzione, non e' certo vietato.
A me pare una perdita di tempo.

> La leggibilità non discende da QUANTO codice viene scritto, ma da COME
> 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.