Programmazione OOP - Come e dove sfruttarla (concetti chiave)?

[lore83]

Ad esempio se hai una gestione dell'utente semplice con anagrafica e ti interessano esclusivamente le funzioni
-nuovo utente
-modifica dati anagrafica
-disabilita utente
-utente loggato

Ok, sono d'accordo, ma l'eventuale metodo "nuovo utente", che implica un'interazione col DB, richiama un metodo di una classe/sottoclasse DB oppure presenta la connessione al db e i comandi per l'inserimento dei record espliciti nel metodo?

Una sotto classe eredita tutti i medodi implementati dalla classe genitore.

Quindi la sottoclasse deve essere fatta SOLO SE ha bisogno dei metodi/attributi della classe genitore (tutti o quasi)?

Grazie ancora.

[Emulman]

tanto per chiarirti la cosa facciamo un esempio.

Tu definisci la classe AUTOMOBILE che avrà come proprietà ad esempio COLORE, NUM_PORTIERE, TIPO_MOTORE, quindi in codice:

$auto = new Automobile;
$auto->colore = 'rosso';
$auto_>num_portiere=4: 

una sottoclasse che eredita le proprietà di AUTOMBILE potrebbe essere un costruttore di auto, ad esempio la FIAT che fa delle automobili che hanno in generale le proprietà e i metodi della classe AUTOMOBILE; allo stesso tempo la sottoclasse FIAT aggiunge nuove proprietà e metodi e può utilizzare proprietà e metodi della classe madre.

class FIAT extends Automobile {
  public $tipo_motore;
}
$fiat = new FIAT();
$fiat->colore = 'verde';
$fiat->num_portiere=2;
$fiat->tipo_motore='multijet'; 

[LeaderGL]

Originariamente inviato da lore83
Ok, sono d'accordo, ma l'eventuale metodo "nuovo utente", che implica un'interazione col DB, richiama un metodo di una classe/sottoclasse DB oppure presenta la connessione al db e i comandi per l'inserimento dei record espliciti nel metodo?

Una classe "utente" o più genericamente "persona" non ha alcun bisogno di connettersi al database in quanto nessuno degli aspetti di un utente/persona è in relazione con questo.
Dovrai istanziare una classe "utente", valorizzandone i campi utili, ed avere del "codice" che si occupa eventualmente di salvare il tutto nel database.

Ad un utente non importa niente se tu usi un database o altro, quello della gestione dei dati (carica/salva) è altra cosa della gestione di una persona. Se tu domani scegli di cambiare il database utilizzato o di non usare un database della tua classe "utente" non te ne fai più niente; non avrebbe quindi senso usare la programmazione ad oggetti

Originariamente inviato da lore83
Quindi la sottoclasse deve essere fatta SOLO SE ha bisogno dei metodi/attributi della classe genitore (tutti o quasi)?

Una classe B sarà sottoclasse di una classe A se è in parentela con quella.
Se hai la classe "automobile" e vuoi creare una classe "Fiat_Panda" ti devi chiedere: la fiat panda è una automobile?
La risposta è si e quindi "Fiat_Panda" può essere una sottoclasse di "automobile"....detto terra terra.

[lore83]

Ad un utente non importa niente se tu usi un database o altro, quello della gestione dei dati (carica/salva) è altra cosa della gestione di una persona. Se tu domani scegli di cambiare il database utilizzato o di non usare un database della tua classe "utente" non te ne fai più niente; non avrebbe quindi senso usare la programmazione ad oggetti

Questo volevo sentirmi dire
Ogni classe contiene quindi le operazioni specifiche per quella classe che poi andranno ad interagire (oppure no) con le altri classi.

L'idea potrebbe essere allora generare delle sottoclassi di una classe DB, con connessione magari singleton, per gli inserimenti, le ricerche o gli aggiornamenti, no?

class Utente
{
  public function Inserimento($nome, $cognome...){
   $db = new DataBase; // oppure meglio singleton
   $db->inserimento($nome, $cognome...); // magari con un costruttore prima
  }
} 

Ok?

[Emulman]

sarebbe meglio utilizzare metodi e proprietà generali nella classe madre che verranno riutilizzati dalle classi figlie, ad esempio per la connessione ad un db:

class Madre {
  private $host;
  private $username;
  private $password;
  private $database;

  function __construct() {
    $this->host = 'localhost';
    $this->username = 'nome_user';
    $this->password = 'password';
    $this->database = 'nome_db';
  }
}

class Figlia extends Madre {
  function __construct() {
    // eredita i parametri __construct della classe Madre
    parent::__construct();
  }

  public function open_db() {
    $conn = mysql_connect($this->host, $this->username, $this->password);
    $db = mysql_select_db($this->database, $conn);
    return $conn;
  }
}

$class = new Figlia();
$mysql = $class->open_db(); 

se cambi database basta solo cambiare il valore di $this->database nella classe Madre e basta

[LeaderGL]

La classe utente non sa se esiste o no un database. Quindi nei suoi metodi non sarebbe opportuno utilizzare un database. Se un giorno decidessi che memorizzare l'utente non ti interessa più che ci fai con quel metodo? E se dovessi cambiare tipo di database?

class Utente
{
  private $nome;
  private $cognome;
  private $eta;

  public function __contructor(...)
  {
  }

  public function getNome()
  {
    return $this->nome;
  }
}

class StoreUser
{
  function store(&$database, &$utente)
  {
    $database->query("...");
  }
} 

questo è un esempio volendo anche errato ma che comunque serve a farti capire che ogni classe deve fare lo stretto necessario per quello che rappresenta.

Una persona non si salva in un database da sola, non sa neanche cosa sia un database. Una persona sa come si chiama, quale è il suo cognome, la sua età, il suo sesso e cose simili.

Poi ovvio se per esigenze tue una "persona" deve obbligatoriamente sapere altro di se stessa...lo si fa.

Le classi devono essere quanto più interdipendenti tra di loro. Maggiore è la dipendenza tra le classi più problemi avrai a rendere il tuo codice (le tue classi) adatte a qualsiasi tipo di progetto.

Puoi benissimo crearti una classe ad hoc che avendo i dati di un generico cliente li può memorizzare nel database, oppure restituirti un oggetto cliente creandolo dopo aver letto i suoi dati dal database; ma un cliente è solo un cliente nient'altro. Non si occupa di database, di sessioni, di configurazioni o altro.

[lore83]

Grazie LeaderGL, ottime delucidazioni.

Obiettivo quindi delle classi è quella di creare entità totalmente indipendenti che abbiano bisogno solo dei metodi in esso inseriti.

Interessante il passaggio per riferimento dell'oggetto, mi ha chiarito molte cose.

Un'ultima cosa quando usare l'abstract? Nell'esempio di prima:

Tu definisci la classe AUTOMOBILE che avrà come proprietà ad esempio COLORE, NUM_PORTIERE, TIPO_MOTORE, quindi in codice:

$auto = new Automobile; $auto->colore = 'rosso'; $auto_>num_portiere=4; 

aveva senso definirla abstract?

Grazie a tutti.

[kuarl]

http://www.ibs.it/code/9788871921501/design-patterns

accattatevi questo, è la bibbia delle tecniche di sviluppo della programmazione ad oggetti.

[LeaderGL]

Obiettivo quindi delle classi è quella di creare entità totalmente indipendenti che abbiano bisogno solo dei metodi in esso inseriti.

Attenzione però, non è sempre così...cioè non è una legge di natura. In genere nella progettazione delle classi si hanno, tra tanti, due punti molto importanti:
1) Coesione
2) Accoppiamento (inter-dipendenza tra più classi)

La coesione è il cercare di inserire in una classe tutto lo stretto necessario che la riguarda esplicitamente.
L'accoppiamento è il legame, e quindi la dipendenza, che si ha tra le classi.

In genere bisogna tendere a minimizzare l'accoppiamento ed a massimizzare la coesione.


Per l'abstract, in pura linea teorica, è bene dichiarare una classe abstract quando si è arrivati ad un grado molto alto di astrazione inserendo in questa classe dei metodi concreti che le sue sotto-classi sicuramente utilizzeranno in quel modo (universali potrei dire) e dei metodi astratti (che impongono di definire la classe come astratta) per i quali ci può essere una particolare implementazione nelle varie sottoclassi ma che comunque è necessario che le sottoclassi concrete abbiano.

Ad esempio tornando all'automobile potresti avere:

abstract class Auto
{
  private $marca;
  private $modello;
  
  public function getModello()
  {
    return $this->modello;
  }

  abstract public getConsumo($km);
}

class Fiat_Panda extensa Auto
{
  public getConsumo($km) {
    return 3*($km-2);
  }
}

class Fiat_Punto extend Auto
{
  public getConsumo($km)
  {
    return 5*$km;
  }
} 

sicuramente tutte le auto avranno un consumo, ma ognuna di loro avrà un consumo diverso ed è quindi necessario che il metodo "getConsumo" sia ridefinito in ogni classe.

Anche se in questo caso si poteva fare in diversi modi (un overriding del metodo) ma comunque questo è uno degli aspetti relativi le classi astratte...ma ovviamente non è l'unico.

Questi sono argomenti che vanno studiati bene in ogni caso.

In genere in una classe astratta, che quindi ha raggiunto un elevalo livello di astrazione, si cerca di inserire campi e metodi che vanno bene per tutti gli "oggetti" che possono appartenere a quella classe; usando quindi la classe astratta come base per le altre classi.

Inoltre una classe astratta non è istanziabile.

[kuarl]

Originariamente inviato da lore83
Grazie LeaderGL, ottime delucidazioni.

Obiettivo quindi delle classi è quella di creare entità totalmente indipendenti che abbiano bisogno solo dei metodi in esso inseriti.

ehm no. L'obbiettivo delle classi è modellare un applicazione alzando il livello di astrazione. In altre parole è modellare degli oggetti softwarer, cioé parti del software, che rappresentino quanto più da vicino un oggetto reale.

In seguito a ciò sono state sviluppate varie tecniche. Nella programmazione ad oggetti moderna si suddivide il processo di sviluppo in analisi a cui poi consegue la progettazione. L'analisi consiste nell'individuare le entità principali che l'applicazione dovrà gestire, e collegarle in modo opportuno tramite associazioni.

Se te vuoi modellare un negozio potresti aver bisogno di modellare classi che rappresentano gli oggetti in vendita, classi che rappresentano le categorie di oggetti, le vendite, i pagamenti etc. Ogni classe è legata alle altre tramite associazioni.

Una volta completata l'analisi, che è abbastanza sommaria e riguarda giusto gli elementi prettamente teorici, si passa alla progettazione, che traduce il modello di dominio prodotto dall'analisi prima nel modello delle classi di dominio e quindi in codice.

Essenzialmente non è vero che le classi rappresentano un raggruppamento di operazioni omogenee. Le classi rappresentano concetti, quindi dati con annesse operazioni. Facendoti un esempio pratico, un oggetto vendita relativo all'esempio di sopra, potrebbe avere al suo interno oltre ai dati di fatturazione anche gli oggetti acquistati dal cliente, più qualche metodo per generare la fattura o chessò io.


Durante l'analisi e la progettazione ad oggetti si seguono diverse linee guida detti pattern (qualcuno sopra citava il pattern mvc, molto diffuso ultimamente). Tali pattern propongono soluzioni idea a problemi comuni. Due molto teorici che bisognerebbe tenere sempre a mente sono High Cohesion e Low Coupling. Per farla breve, avere una coesione alta significa far eseguire poche operazioni alle tue classi, ma assai specifiche e relative alla realtà che si intende modellare. Mantenere basso l'accoppiamento significa non far dipendere troppo la tua classe da altre classi, questo perché una modifica nel codice delle altre classi potrebbe riflettersi su diverse parti dell'applicazione.

Ce ne sono a dozzine, il libro che ho postato poco sopra ne contiene un fottio.

Un altro libro che non dovrebbe mancare nella vostra biblioteca è questo:
http://www.ibs.it/code/9788871922706...l-pattern.html

che lo definirei propedeutico al libro precedente. Specialmente se come sembra, sei a digiuno di programmazione ad oggetti.


Parlavi di classi astratte, non c'è una regola specifica in cui è richiesta l'uso delle classi astratte, ci sono insiemi di problemi che potrebbero avere come soluzione l'uso di una classe astratta.

Personalmente mi capita di rado di utilizzarle, utilizzo estensivamente l'ereditarietà, ma di solito è più comodo usare interfacce o estendere altre classi concrete.