credo che santino intendesse la stessa cosa è che non mi ha letto nella mente, o io non ho letto nella sua e abbiamo scritto 2 nomi diversiHo capito male? O forse anche Santino intendeva la stessa cosa ma il nome della classe mi ha portato fuori strada facendomi pensare a un controller generico anzichè ad uno "dedicato" allo scopo dell'iscrizione dell'utente alla partita?
proviamo a mescolare le due soluzioni:Originariamente inviata da lordsabbath
Grazie ad entrambi per le risposte
Vedo che entrambi proponete una soluzione 3° classe, ma concettualmente parlando quello che proponete non è più un interfaccia o una classe astratta?
Si può applicare un interfaccia se vuoi, la classe astratta non centra niente peròCodice PHP:interface Registrable {
public function register( User $user );
}
class GameSubscriber {
public function __construct( User $user ) {
$this->user = $user;
}
public function iscriviUtenteAGame( Registrable $game ) {
return $game->register( $user );
}
}
classi piccole e che soddisfano 1 sola operazione, non sempre è il miglior approccio ma puoi trovare un giusto compromessoStudierò iper volentieri il SOLID, da una lettura della pagina wiki mi sembra un approccio che può aiutare molto a schiarirsi le idee.
Diciamo che per farla breve ho sviluppato delle macro classi ( tra l'altro enormi anche a livello di righe di codice ) senza sviluppare classi "ponte" che collegassero le macro..
ecco non esagerare troppoUsando dei controller non rischio però di trovarmi con la macro classe che nella pratica non fa quasi nulla?
Mi spiego:
Creo class PM, e definisco gli attributi necessari per esempio $sender, $recipier, $text etc...
Creo poi una class PMController, definendo i metodi send(); update(); delete(); read(); etc..
Che metodi potrei mai inserire all'interno della classe PM se è il controller che me li gestisce?
Al_katraz984 invece se non capisco male tu proponi una soluzione più "action" rispetto al controller, del tipo creare le classi:
class SendPM,
class UpdatePM,
etc etc etc
Rispondi quotando