Esiste un antipattern per descrivere questo metodo di codifica? [chiuso]

Vale solo la pena di chiamare qualche cattiva abitudine di codifica per un Antipattern se è ragionevolmente diffuso.

Il resto chiamiamo semplicemente "codice spazzatura" ...

Se dovessi suggerire un nome per questa particolare cattiva abitudine, sarebbe "Disturbo dell'astrazione ossessiva": -)

No, non è un pattern anti ma vorrei sollevare i seguenti problemi.

Violazione del principio di responsabilità singola

SRP dice che una classe dovrebbe avere una ragione per cambiare. L'aggiunta di un metodo logger significa che anche la classe deve essere modificata se la logica di registrazione deve essere modificata.

Violazione di una relazione is-a

Le classi base non sono toolbox in cui è possibile aggiungere diversi metodi di convenienza.

Facendo in modo efficace accoppia tutte le classi ereditate con le implementazioni della classe base.

Confrontalo con la composizione.

Non che ciò renda accettabile, ma potrebbe essere solo un refactoring incompiuto. Forse il SomeClass.log () ha la sua logica e è stato implementato per primo. E in seguito si sono resi conto che dovevano usare ErrorLog.Log (). Quindi, piuttosto che modificare 100 posizioni in cui viene chiamato SomeClass.Log (), sono state delegate solo a ErrorLog.Log (). Personalmente cambierei tutti i riferimenti a ErrorLog.Log () o commenterei almeno SomeClass.log () per dire perché delega il modo in cui lo fa.

Solo qualcosa da considerare.

Mi viene in mente il termine "Codice di Lasagna", anche se a quanto pare significa cose diverse per persone diverse . La mia interpretazione è sempre stata "stratificata per il gusto di essere stratificata".

Non sono sicuro di descriverlo come un'offesa al principio di responsabilità singola, perché se c'è una modifica alla firma del metodo ErrorLog (il metodo chiamato da SomeClass), ogni codice client che chiama questo metodo fallirà .

Esiste ovviamente un modo per utilizzare l'ereditarietà (o creare classi che richiedono la registrazione che implementa un'interfaccia di registrazione).

Oppure potremmo considerare questo come un "momento insegnabile":)

Il tuo sviluppatore potrebbe essere a metà strada con una buona idea. Supponiamo che tu voglia avere il requisito che tutti i tuoi oggetti di business siano in grado di registrare in modo intelligente. Potresti definire:

   public interface IBusinessObjectLogger
   {
       void Log(Exception ex, string logMessage)
   }

Ora interno agli oggetti è possibile utilizzare l'oggetto ErrorLog per eseguire effettivamente la registrazione mentre il codice SomeClass aggiunge un valore specifico dell'oggetto al messaggio di log. È quindi possibile estendere ulteriormente le API di registrazione per implementare la funzionalità di registrazione basata su file, db o basata sui messaggi senza toccare gli oggetti di business.

Non sono sicuro che sia automaticamente malvagio.

Se chiami SomeClass.Log è sicuramente malvagio, ma se Log viene utilizzato solo da WITHIN SomeClass, riduce l'accoppiamento e lo chiamerei accettabile.

Questo è in realtà abbastanza comune in alcuni stili di codifica e le basi della linea di pensiero non sono, di per sé, un anti-modello.

Probabilmente è il risultato di qualcuno che codifica per necessità senza la conoscenza della più ampia base di codice: "OK, questo codice deve registrare un errore, ma quella funzione non è lo scopo principale del codice. Pertanto, ho bisogno di un metodo / classe che lo farò per me ". Questo è un buon modo di pensare; ma, senza conoscere ErrorLog, hanno creato SomeClass. Hanno poi trovato ErrorLog in un secondo momento, e invece di sostituire tutti gli usi del metodo che hanno inserito, hanno fatto il loro metodo chiamata ErrorLog. Che è dove questo diventa un problema.

La complessità accidentale è la complessità che emerge nei programmi per computer o nel loro processo di sviluppo che non è essenziale per il problema da risolvere. Mentre la complessità essenziale è intrinseca e inevitabile, la complessità accidentale è causata dall'approccio scelto per risolvere il problema.

link

Potrebbe trattarsi di un abuso / incomprensione del Pattern di facciata . Ho visto cose simili in una base di codice con cui ho lavorato. Gli sviluppatori hanno attraversato una fase in cui erano pazzi per i modelli di progettazione senza comprendere i principi generali del design OO.

Un uso improprio del modello di facciata produce una sfocatura dei livelli di astrazione attraverso i livelli dell'applicazione.

Ciò che questo programmatore sta facendo è il wrapping di un codice, in modo che non abbia una dipendenza diretta dal modulo di registrazione. Senza informazioni più specifiche, non è possibile dare uno schema più specifico. (Che questi involucri non siano utili è la tua opinione che è impossibile essere d'accordo o in disaccordo senza molte più informazioni.)

I pattern che potrebbero rientrare sono Proxy , Delegato , Decoratore , Composito o alcuni di questi che hanno fare con il wrapping, nascondere o distribuire le chiamate. Può una di queste cose in uno stato di sviluppo incompleto.

Potrei immaginare che sia una differenza culturale. Forse c'è una buona ragione per avere funzionalità duplicate in questo particolare codice di base. Potrei immaginare che la facilità di scrittura sia una tale ragione. Il programmatore Python in me direbbe ancora che è sbagliato, dal momento che " dovrebbe essercene uno - e preferibilmente solo uno - - modo ovvio per farlo. ", ma alcuni Perl potrebbero essere abituati al fatto che" C'è più di un modo per farlo ".