Il problema è che il contesto di autorizzazione del sistema è la cosa giusta da associare alle attività di sistema, ma non è realmente un utente. Ma diffondere molte bandiere magiche "isSystem" dappertutto è solo una ricetta per sbagliare (seriamente, stai guardando qualcosa che tende a produrre errori e in modi che falliscono in modi che possono essere davvero imbarazzanti per te ). Abbiamo bisogno di un altro modo. Fortunatamente ce n'è uno; tutto dipende dal fatto che tu abbia la tua gerarchia di classe concettuale sbagliata.
Al momento, hai tutti gli utenti come istanze di UserObject e ne nominali uno speciale. Bene, vogliamo mettere la particolarità dell'identità di sistema nella gerarchia di classi (nominare istanze speciali è di per sé problematico). Lo facciamo definendo un SystemUser , che è diverso in quanto crei un'istanza (singleton?) E proibisci l'accesso. Sottoclassi da UserObject e hai catturato cosa sta succedendo ...
Tranne che ... non sembra davvero un utente, vero? Quindi cambiamo la gerarchia delle classi. Invece di avere SystemUser ereditare da UserObject , abbiamo una nuova superclasse / interfaccia, IdentityContext , e abbiamo SystemIdentityContext (nota la modifica del nome, non è necessario fingere che sia un utente ora) e UserObject entrambi ereditano da esso. È quindi possibile effettuare il login in una funzionalità aggiunta di UserObject , con la certezza che il sistema non potrà mai accedere senza eseguire l'abusare di quell'umile database di utenti, e tuttavia si ha una nozione univoca di identità che indica chiaramente quei compiti di sistema per quello che sono.
(Ogni volta che hai un problema in cui hai due alternative che sembrano entrambe ugualmente valide in qualche modo eppure nessuna è perfetta, prenditi un momento per fare un passo indietro e pensa "C'è un altro modo in cui io? non hai ancora individuato? "Di solito c'è ...)