Impostazione classi derivate e organizzazione tabelle

[Santino83_02]

Il problema è di capire come posso sfruttare l'ereditarietà.
Diciamo che in un progetto ho già la classe persone che gestisce gli attributi dell'anagrafica e metodi di accesso al database nella sua propria tabella persone.
E' corretto pensare di fare la classe derivata impiegati sfruttando di già la classe persone e gestire quindi i soli attributi di impiegato visto che quelli di persona sono già gestiti?
Se la risposta è sì come dovrei impostare le classi e i metodi?
Spero di essermi spiegato

tu hai una persona che può essere impiegata o meno presso un'azienda, modella quest'aspetto, per ora non c'è bisogno di ereditarietà perchè stai modellando una uno-molti tra l'azienda e le persone, andando a specificare nella relazione i campi in più (data di assunzione, ruolo, salario, reparto, etc...) .... Diverso se tu debba modellare un organigramma aziendale e rispecchiare "metodi" e compiti che un ruolo piuttosto che un altro può avere nella società (ad esempio se vuoi dividere il ruolo di dirigente da quello di responsabile da quello di impiegato semplice etc ) dove allora l'idea di avere un'astratta "persona" che di volta in volta viene estesa potrebbe avere senso. Comunque, anche in quest'ultimo caso, impiegato e persona sono praticamente la stessa classe, anche perchè io la contrattualizzazione del rapporto di lavoro tra l'impiegato e la company non la modellerei dentro impiegato ma in una tabella di raccordo tra impiegato e company

[garakkio]

Questo potrebbe essere un buon punto di partenza: http://docs.doctrine-project.org/en/...e-mapping.html

[artex]

In comune persone e impiegati hanno gli attributi dell'anagrafica e i metodi per la gestione degli attributi comuni.
volevo capire se in genere è bene distinguere i dati e i metodi in questo esempio di persone e impiegati, se un giorno avrò bisogno di gestire la classe studenti (che è sempre una persona) potrei limitarmi a gestire la sola matricola e con una classe a parte gestire gli esami sostenuti.

La soluzione 2 che tu indichi potrebbe essere corretta?
person
id | nome | cognome | eta
worker
id| pid | data_assunzione | qualifica

In questo caso come imposteresti i metodi?
Grazie per la pazienza

[Al_katraz984]

La soluzione 2 che tu indichi potrebbe essere corretta?
person
id | nome | cognome | eta
worker
id| pid | data_assunzione | qualifica

In questo caso come imposteresti i metodi?
Grazie per la pazienza

Il problema di questo approccio è che se vuoi distinguere i diversi "tipi" di pesona dovrai aggiungere dei flag sulla tabella

es
person
id | nome | cognome | eta | isWorker | isFreelance
worker
id| pid | data_assunzione | qualifica
freelance
id| pid | data_contratto | mansione

in questo modo faciliti la selezione delle persone ma avrai tanti flags quanti "tipi" di persona presenti nel tuo sistema. Qui puoi gestire tutto con una classe

Io invece a livello di tabelle opterei per:
user
id | nome | mail | password | data_registrazione
impiegato
id | nome | mail | password | data_registrazione | data_assunzione | mansioni

nonostante la ripetizione di alcuni campi in questo modo sei aggevolato a livello di codice e puoi tenere nettamente separati i due tipi di persone.

a livello di codice

abstract class person {
  protected $fields = array();
  protected $table;
  protected $pdo;

  public function __construct( PDO $pdo ) {
    $this->pdo = $pdo;
  }

  // magic method __setter e __getter
  // metodi c.r.u.d comuni
  // metodi per login e logout
}

class user extends person {
  protected $fields = array( 'id', 'nome', 'mail', 'password', 'data_registrazione' );
  protected $table = 'user';

  //metodo specifico
  public function fetchByName( $name ) {
    $selectQuery = "SELECT * FROM $this->table WHERE name = :name LIMIT 0,1";
    $stmt = $this->pdo->prepare( $selectQuery );
    // ect ect

    return $userByName;
  }
}

class employee extends person {
  protected $fields = array( 'id', 'nome', 'mail', 'password', 'data_registrazione', 'data_assunzione', 'mansioni' );
  protected $table = 'impiegato';
  private $msg;

  //metodo specifico
  public function fetchMansioni( $id ) {
    $selectQuery = "SELECT mansioni FROM $this->table WHERE id = :id LIMIT 0,1";
    $stmt = $this->pdo->prepare( $selectQuery );
    // ect ect

    return $mansioni;
  }

  public function closeOrder( $oid ) {
    $query = "UPDATE orders SET closed = 1 WHERE id = :id";
    if ( $this->pdo->execute( $query ) ) {
      $this->msg = "ordine chiuso";
    }
  }

  public function getMsg() {
    return $this->msg;
  }
} 

Come vedi in questo modo puoi distinguere nettamente le due persone e fargli compiere funzioni diverse.. questo è solo uno dei tanti modi per risolvere il tuo problema..

[artex]

Leggendo la guida indicata da garakkio capisco che l'argomento è complesso ...
ringrazio tutti per la pazienza.
Se poi nel forum ci fosse qualcuno che ha già fatto una classe generica e vuole dirmi la strada da seguire per le classi derivate e il metodo che lui segue per gestire la persistenza dei dati gli sarei grato.

Grazie

[artex]

Grazie All_katraz984,
un chiarimento visto che non ho molta dimestichezza con la classe PDO. Come crei l'istanza di person?

[Al_katraz984]

person non è istanziabile, è una classe astratta.. serve solo per raggruppare le funzioni comuni a user e impiegato

$pdo = new PDO( $accessi );

$user = new user( $pdo );
var_dump( $user->fetchByName( 'paolo' ) ); 

[artex]

ha non avevo visto,
quindi i metodi CRUD della classe person sono astratti e vanno definiti nelle sottoclassi?

[Al_katraz984]

ha non avevo visto,
quindi i metodi CRUD della classe person sono astratti e vanno definiti nelle sottoclassi?

se fosse cosi la classe person non servirebbe a niente... i metodi nella classe person sono normali..

[artex]

Hai ragione, allora si può dire che person è astratta perchè non venga istanziata direttamente?
hai scelto molto bene lo smiley