Se una classe utente contiene solo attributi e nessun metodo oltre a getter / setter?

Quello che stai facendo è mettere insieme un meccanismo per il controllo degli accessi (liste) o ACL. In generale, come dice Ritesh , è una cattiva idea eseguirlo tutto in una classe.

Questa risposta su SO ha un modo migliore di gestire il controllo degli accessi.

Invece di estendere la tua classe User , devi avvolgere la tua classe User in SecureContainer . Vedi la risposta collegata per i dettagli, ma la chiamata generale sarebbe:

// assuming that you have two objects already: $currentUser and $controller
$acl = new AccessControlList( $currentUser );

$controller = new SecureContainer( $controller, $acl );
// you can execute all the methods you had in previous controller 
// only now they will be checked against ACL
$controller->actionIndex();

Ciò consente alla classe User di concentrarsi su ciò che deve fare e consente alla classe AccessControlList di concentrarsi su ciò che esso deve fare.

Una classe dovrebbe avere un solo scopo di esistere.

I metodi canRead, canUpdate, canWrite, canDelete possono essere spostati in un'altra classe (UserAccessCheck o qualcosa del genere ...)?

Sì, questi metodi dovrebbero essere messi in classi separate.

• se l'autorizzazione è in qualche modo una proprietà dell'utente, è il posto naturale in cui memorizzare i dati
• se il permesso è una proprietà dell'elenco, questo è il luogo naturale in cui archiviarlo
• se il test per il permesso è naturalmente un azione sull'utente (cioè, quella sintassi si adatta meglio al tuo schema di utilizzo), questo è il posto naturale in cui inserire il metodo
• se l'elenco non dovrebbe conoscere l'utente e l'utente non dovrebbe conoscere l'elenco, ma alcuni ACL separati dovrebbero conoscere sia le che loro relazioni, forse che è dove devono andare i dati e / o il metodo
• ecc. ecc.

In generale, sembrano tre preoccupazioni distinte (o separabili): descrivere un utente, archiviare un elenco e gestire l'accesso di uno all'altro.

Se scegli di combinare due di questi problemi nella stessa classe (e se sì, quali), dovrebbe essere perché questa disposizione emerge naturalmente dal tuo modello ( ... è una proprietà di ... ), o perché è più conveniente o efficiente. Non ci hai detto abbastanza per fare quella scelta per te.

Mi piace l'idea di mettere la logica aziendale in classi modello come Utente. In effetti, l'ho fatto esattamente prima con metodi privilegiati come canDoBlah ().

Rende il codice di facile lettura quando si utilizza l'oggetto nel livello dell'interfaccia utente:

public void processList(User user, List list) {
    if (user.canReadList(list)) {
        // do some work
    }
}

Suppongo che potresti inserire la logica nella classe List come hai suggerito con listCanBeReadByUser (), che a tutti gli effetti è uguale, ma penso che sia più facile leggere sull'oggetto User.

L'unico suggerimento che vorrei fare è evitare di inserire SQL nella classe del modello. Questo appartiene al livello di persistenza, forse in un DAO .

L'astrazione è l'idea.

Mappare tutte le azioni che si desidera raggiungere nella classe utente

Qualsiasi azione non pertinente a quell'oggetto dovrebbe essere rimossa.

L'astrazione è uno dei principi fondamentali di OOP

la corretta mappatura degli oggetti fisici a quelli astratti che sono programmati è la chiave.

Aiuta a determinare come vuoi rappresentare questi oggetti.