Sto studiando modelli e anti-modelli. Ho un'idea chiara dei modelli, ma non ho anti-schemi. Le definizioni dal web e Wikipedia mi confondono molto.Che cos'è un anti-pattern?
Qualcuno può spiegarmi in parole semplici che cos'è un anti-pattern? Qual è lo scopo? Cosa fanno? È una cosa brutta o buona cosa?
Anti-patterns sono determinati modelli nello sviluppo del software che sono considerati cattive pratiche di programmazione.
Al contrario di design patterns che sono approcci comuni a problemi comuni che sono stati formalizzati e sono generalmente considerati una buona pratica di sviluppo, gli anti-schemi sono l'opposto e sono indesiderabili.
Ad esempio, nella programmazione orientata agli oggetti, l'idea è quella di separare il software in piccoli pezzi chiamati oggetti. Un anti-pattern nella programmazione orientata agli oggetti è un God object che esegue molte funzioni che sarebbero meglio separate in oggetti diversi.
Ad esempio:
class GodObject {
function PerformInitialization() {}
function ReadFromFile() {}
function WriteToFile() {}
function DisplayToScreen() {}
function PerformCalculation() {}
function ValidateInput() {}
// and so on... //
}
L'esempio precedente ha un oggetto che fa tutto. Nella programmazione orientata agli oggetti, sarebbe preferibile avere responsabilità ben definiti per oggetti diversi per mantenere il codice meno accoppiato e in definitiva più gestibile:
class FileInputOutput {
function ReadFromFile() {}
function WriteToFile() {}
}
class UserInputOutput {
function DisplayToScreen() {}
function ValidateInput() {}
}
class Logic {
function PerformInitialization() {}
function PerformCalculation() {}
}
La linea di fondo è che ci sono buoni modi per sviluppare software comunemente modelli usati (design patterns), ma ci sono anche dei modi in cui il software è sviluppato e implementato e può portare a problemi. I pattern considerati come cattive pratiche di sviluppo del software sono anti-pattern.
qualche altro esempio di Anti-Pattern accanto a GodObject? – Tomasz
@Tomasz Programming Pasta serve è un esempio. È meglio generalizzato come incapsulamento scadente tra molti piccoli oggetti. Consideralo l'opposto dell'oggetto God https://en.wikipedia.org/wiki/Spaghetti_code – AWrightIV
@Tomasz tutto ciò che è male, ma è fatto da alcune persone, è un antipattern. Ad esempio, 'prova:
Un modello è un'idea di come risolvere un problema di qualche classe. Un anti-pattern è un'idea di come non risolverlo perché implementare quell'idea porterebbe a un cattivo design.
Un esempio: uno "schema" sarebbe utilizzare una funzione per il riutilizzo del codice, un "anti-pattern" sarebbe utilizzare copia-incolla per lo stesso. Entrambi risolvono lo stesso problema, ma l'uso di una funzione di solito porta a un codice più leggibile e gestibile rispetto al copia-incolla.
Un modo comune per fare un casino. Come la classe dio/kitchensink (fa tutto), per esempio.
Un anti-pattern è un modo per non risolvere un problema. Ma c'è dell'altro: è anche un modo che può essere visto frequentemente nei tentativi di risolvere il problema.
proprio come con un modello di progettazione , un anti-modello è anche un modello e un modo ripetibile di risolvere un certo problema, ma in modo non ottimale e inefficace.
Se si desidera veramente studiare AntiPatterns, ottenere il libro AntiPatterns (ISBN-13: 978-0471197133).
In esso, definiscono "Un AntiPattern è una forma letteraria che descrive una soluzione comune a un problema che genera conseguenze decisamente negative."
Quindi, se si tratta di una pratica di programmazione male, ma non un comune — limitato ad una sola applicazione, una società o un programmatore, non soddisfa la 'parte del modello' della definizione antipattern.
È interessante notare che un Singleton è il primo esempio di questo metodo: apparirà in entrambi i gruppi di letteratura:
Gli anti-pattern sono modi comuni in cui le persone tendono a programmare l'errore modo, o almeno il modo non così buono
Ogni volta che sento parlare di Anti- modelli, ricordo un altro termine viz. Odore di design. .
"odori di design sono alcune strutture nella progettazione che indicano violazione dei principi fondamentali di progettazione e avere un impatto negativo la qualità del design” (Da 'refactoring per Software Design Smells: La gestione del debito tecnica')
Ci sono molti odori di design classificate in base violare principi di progettazione:
astrazione odori
mancante astrazione: Questo odore si verifica quando ciuffi di dati o str codificati vengono utilizzati invece di creare una classe o un'interfaccia.
Astrazione imperativa: Questo odore si verifica quando un'operazione viene trasformata in una classe.
Astrazione incompleta: Questo odore si manifesta quando un'astrazione non supporta completamente i metodi complementari o interrelati.
Astrazione sfaccettata: Questo odore si manifesta quando un'astrazione ha più di una responsabilità assegnata.
Astrazione non necessaria: Questo odore si verifica quando un'astrazione che non è effettivamente necessaria (e quindi potrebbe essere stata evitata) viene introdotta in un progetto software.
Astrazione non utilizzata: Questo odore si manifesta quando un'astrazione non viene utilizzata (non utilizzata direttamente o non raggiungibile).
Estrazione duplicata: Questo odore si manifesta quando due o più astrazioni hanno nomi identici o un'implementazione identica o entrambe.
Encapsulation odori
Encapsulation deficiente: Questo odore si verifica quando l'accessibilità dichiarata di uno o più membri di un astrazione è più permissiva che effettivamente necessaria.
Incapsulamento a tenuta: Questo odore si manifesta quando un'astrazione "espone" o "perde" i dettagli di implementazione attraverso la sua interfaccia pubblica.
mancante Incapsulamento: Questo odore si verifica quando le variazioni di implementazione non sono incapsulati all'interno di un'astrazione o una gerarchia.
Encapsulation ancora sfruttato: Questo odore sorge quando il codice client utilizza controlli di tipo esplicite (usando incatenato if-else o switch istruzioni che controllano il tipo di oggetto) anziché sfruttare la variazione nei tipi già incapsulati all'interno di una gerarchia.
modularizzazione odori
rotto modularizzazione: Questo odore si pone quando i dati e/o metodi che idealmente avrebbe dovuto essere localizzati in un unico astrazione sono separati e distribuiti su più astrazioni.
Modularizzazione insufficiente: Questo odore si verifica quando esiste un'astrazione che non è stata completamente scomposta e un'ulteriore decomposizione potrebbe ridurne dimensioni, complessità di implementazione o entrambe.
Modularizzazione dipendente dal ciclo: Questo odore si verifica quando due o più astrazioni dipendono l'una dall'altra direttamente o indirettamente (creando un accoppiamento stretto tra le astrazioni).
Modularizzazione mozzo: Questo odore si verifica quando un'astrazione ha dipendenze (sia in entrata che in uscita) con un gran numero di altre astrazioni.
Gerarchia odori
Gerarchia mancante: Questo odore si pone quando un segmento di codice utilizza logica condizionale (in genere in concomitanza con “tag tipi”) per gestire in modo esplicito la variazione nel comportamento in cui potrebbe essere stato creato una gerarchia e usato per incapsulare quelle variazioni.
Gerarchia inutile: Questo odore sorge quando l'intera gerarchia di ereditarietà è inutile, che indica che l'ereditarietà è stata applicata inutilmente per il particolare contesto disegno.
Gerarchia non formattata: Questo odore si verifica quando c'è una duplicazione non necessaria tra i tipi in una gerarchia.
Gerarchia ampia: Questo odore si verifica quando una gerarchia di ereditarietà è "troppo" ampia e indica che potrebbero mancare tipi intermedi.
Gerarchia speculativa: Questo odore si manifesta quando uno o più tipi in una gerarchia vengono forniti in modo speculativo (vale a dire, in base a bisogni immaginati piuttosto che a requisiti reali).
Gerarchia profonda: Questo odore si manifesta quando una gerarchia dell'eredità è "eccessivamente" profonda.
Gerarchia ribelle: Questo odore si verifica quando un sottotipo rifiuta i metodi forniti dai suoi supertipi.
Gerarchia spezzata: Questo odore si verifica quando un supertipo e il suo sottotipo concettualmente non condividono una relazione "IS-A" con conseguente sostituibilità interrotta.
Gerarchia multipercorso: Questo odore si verifica quando un sottotipo eredita sia direttamente sia indirettamente da un supertipo che conduce a percorsi di ereditarietà non necessari nella gerarchia.
Gerarchia ciclica: Questo odore si verifica quando un supertipo in una gerarchia dipende da uno qualsiasi dei suoi sottotipi.
La definizione di cui sopra e la classificazione è descritto in "Refactoring for software design smells: Managing technical debt". Alcune risorse più rilevanti è stato trovato here.
Un anti-modello è il complemento di un modello di progettazione . Un anti modello è una soluzione modello che non si dovrebbe usare in una determinata situazione
Oggi, i ricercatori e i professionisti dell'ingegneria del software usano spesso i termini "anti-pattern" e "odore" in modo intercambiabile. , non sono concettualmente la stessa cosa. La voce di Wikipedia di anti-pattern afferma che un anti-pattern è diverso da una cattiva pratica o una cattiva idea di almeno due fattori. Un anti-pattern è
"Un processo comunemente utilizzato, struttura o modello di azione che nonostante inizialmente appare essere una risposta adeguata ed efficace ad un problema , ha tipicamente conseguenze più pertinenti che risultati positivi.”
indica chiaramente che un anti-modello viene scelto nella convinzione che si tratta di una buona soluzione (come un modello) al problema presentato;. tuttavia, porta più passività che benefici D'altra parte, un odore è semplicemente una cattiva pratica che influisce negativamente sulla qualità di un softwa re sistema. Ad esempio, Singleton è un anti-modello e la classe di Dio (o Modularizzazione insufficiente) è un odore di design.
https://sourcemaking.com/antipatterns – jaco0646
http://martinfowler.com/bliki/AntiPattern.html – jaco0646