So che questa sarà una domanda difficile a cui rispondere senza contesto, ma spero che ci siano almeno alcune buone linee guida da condividere su questo. Le domande sono in fondo se vuoi saltare i dettagli. La maggior parte riguarda OOP in generale.
Inizia il contesto. Sono un jr dev su un'applicazione PHP, e in generale gli sviluppatori con cui lavoro si considerano in grado di utilizzare molti più concetti OO rispetto alla maggior parte degli sviluppatori PHP. Tuttavia, nella mia ricerca sul codice pulito ho letto su tanti modi di utilizzare le funzionalità di OO per rendere il codice flessibile, potente, espressivo, testabile, ecc. Che è semplicemente non usato qui.
L'attuale OO strongmente OO che ho proposto viene chiamata troppo complessa, anche se è banale da implementare. Il problema che sto risolvendo è che i nostri controlli delle autorizzazioni vengono eseguiti tramite un oggetto messaggio (la mia API, volevano utilizzare matrici di costanti) e l'oggetto messaggio non mantiene l'oggetto di convalida responsabile per il controllo di tutti i dati forniti. Metaforicamente, se la tua perm contenente "ammissibile" e "raro ma non consentito" viene inviata a un validatore, il validatore potrebbe non sapere di cercare "raro ma non consentito", ma approvare "ammesso", che in realtà approverà l'intero controllo perm. Abbiamo 11 validatori, troppi per rintracciare facilmente dettagli così minuti.
Quindi ho proposto una classe AtomicPermission . Per correggere l'esempio precedente, la perm avrebbe invece contenere due permessi atomici, uno avvolgente 'permissibile' e l'altro involucro 'raro ma non consentito'. Dove in precedenza il validatore direbbe "il controllo è OK perché contiene consentito", ora direbbe invece che "" ammesso "è ok", a quel punto il controllo finisce ... e il controllo fallisce, perché "raro ma non consentito" non era specificamente adatto.
L'implementazione è costituita da soli 4 oggetti banali e riscrive una funzione a 10 linee in una funzione a 15 linee.
abstract class PermissionAtom {
public function allow(); // maybe deny() as well
public function wasAllowed();
}
class PermissionField extends PermissionAtom {
public function getName();
public function getValue();
}
class PermissionIdentifier extends PermissionAtom {
public function getIdentifier();
}
class PermissionAction extends PermissionAtom {
public function getType();
}
Dicono che questo "non ci porterà niente di importante" ed è "troppo complesso" e "sarà difficile per i nuovi sviluppatori". Sono rispettosamente in disaccordo, e qui termino il mio contesto per iniziare le domande più ampie.
Quindi la domanda riguarda la mia OOP, ci sono delle linee guida che dovrei sapere:
- è questo troppo complicato / troppo OOP? Non che mi aspetto di ottenere più di 'dipende, dovrei vedere se ...'
- quando l'astrazione OO è eccessiva?
- quando l'astrazione OO è troppo piccola?
- come posso determinare quando sto pensando troppo a un problema e a correggerne uno?
- come posso determinare quando aggiungo codice errato a un progetto non valido?
- come posso inserire queste API? Sento che gli altri sviluppatori preferirebbero semplicemente dire "è troppo complicato" piuttosto che chiedere "puoi spiegarlo?" ogni volta che suggerisco una nuova classe.