Domanda

Sto studiando modelli e anti-pattern.Ho una chiara idea circa i modelli, ma non riesco a capire anti-pattern.Definizioni di web e Wikipedia mi confondono un sacco.

Qualcuno può spiegarmi in parole semplici cosa sia un anti-pattern è?Qual è lo scopo?Cosa fanno?E ' una cosa negativa o positiva?

È stato utile?

Soluzione

anti-pattern sono certi schemi nello sviluppo di software che sono considerate pratiche di programmazione cattive.

Al contrario di che sono approcci comuni a problemi comuni che sono stati formalizzata e sono generalmente considerati una buona pratica di sviluppo, anti-pattern sono l'opposto e sono indesiderabili.

Per esempio, nella programmazione orientata agli oggetti, l'idea è di separare il software in piccoli pezzi chiamati oggetti. Un anti-modello in programmazione orientata agli oggetti è un Dio oggetto che svolge molte funzioni che sarebbero essere meglio separati in diversi oggetti.

Ad esempio:

class GodObject {
    function PerformInitialization() {}
    function ReadFromFile() {}
    function WriteToFile() {}
    function DisplayToScreen() {}
    function PerformCalculation() {}
    function ValidateInput() {}
    // and so on... //
}

L'esempio di cui sopra 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 il software con i modelli comunemente usati ( modelli di progettazione ), ma ci sono anche modi software è sviluppato e implementato, che possono portare a problemi. I modelli che sono considerati pratiche di sviluppo software cattivo sono anti-pattern.

Altri suggerimenti

Ogni volta che sento parlare di Anti-pattern, mi ricordo un altro termine viz.Design odore.

"Design odori sono alcune strutture nel design che indicano violazione di fondamentali principi di progettazione e può influenzare negativamente la qualità del design”.(Da "Refactoring per la Progettazione di Software di Odori:La gestione tecnica di debito")

Ci sono molti odori classificati in base a violare i principi di progettazione:

Astrazione odori

Mancanti Astrazione: Questo profumo nasce quando i ciuffi dei dati o delle stringhe codificate sono utilizzati invece di creare una classe o un'interfaccia.

Imperativo Astrazione: Questo profumo nasce quando un'operazione è trasformato in una classe.

Incompleta Astrazione: Questo profumo nasce quando un'astrazione non supporta complementari o correlati metodi completamente.

Multiforme Astrazione: Questo profumo nasce quando un'astrazione ha più di una responsabilità assegnate.

Inutile Astrazione: Questo odore si verifica quando un'astrazione che in realtà non è necessario (e, quindi, avrebbe potuto essere evitato) viene introdotto in un software di progettazione.

Inutilizzato Astrazione: Questo profumo nasce quando un'astrazione è lasciato inutilizzato (non direttamente utilizzati o non raggiungibile).

Duplicato Di Astrazione: Questo odore si verifica quando due o più astrazioni hanno nomi identici o identici di attuazione o di entrambi.

Incapsulamento odori

Carenti Di Incapsulamento: Questo odore si verifica quando l'accessibilità dichiarata di uno o più membri di un'astrazione è più permissive di quelle effettivamente necessarie.

Perde Incapsulamento: Questo profumo nasce quando un'astrazione “espone” o “perdite” dettagli di implementazione attraverso la sua interfaccia pubblica.

Mancanti Incapsulamento: Questo odore si verifica quando attuazione variazioni non sono incapsulati all'interno di un'astrazione o una gerarchia.

Sfruttate Incapsulamento: Questo profumo nasce quando il codice del client utilizza esplicito il tipo di verifica, mediante incatenato if-else o passare le istruzioni che controllano il tipo di oggetto) invece di sfruttare la variazione dei tipi già incapsulato all'interno di una gerarchia.

La modularizzazione odori

Rotto Modularizzazione: Questo profumo nasce quando i dati e/o metodi che idealmente dovrebbe sono stati localizzati in un unico astrazione sono separati e distribuiti in più astrazioni.

Insufficiente Modularizzazione: Questo profumo nasce quando un'astrazione esiste che non è stato completamente decomposto, e un ulteriore decomposizione di ridurre la sua dimensione, la complessità di implementazione, o entrambi.

Ciclico-Dipendente Modularizzazione: Questo odore si verifica quando due o più astrazioni dipendono l'uno dall'altro, direttamente o indirettamente (con la creazione di un accoppiamento stretto tra le astrazioni).

Hub-Come Modularizzazione: Questo profumo nasce quando un'astrazione ha dipendenze (sia in entrata che in uscita) con un gran numero di altre astrazioni.

Gerarchia odori

Gerarchia Mancante: Questo profumo nasce quando un segmento di codice utilizza la logica condizionale (in genere in concomitanza con “tagged tipi”) in modo esplicito gestire variazione nel comportamento, dove una gerarchia possa essere stato creato e utilizzato per incapsulare queste variazioni.

Inutile Gerarchia: Questo profumo nasce quando l'intera gerarchia di ereditarietà è inutile, il che indica che l'ereditarietà è stata applicata inutilmente per il design particolare contesto.

Unfactored Gerarchia: Questo odore si verifica quando non vi è una inutile duplicazione tra i tipi in una gerarchia.

Gerarchia: Questo profumo nasce quando una gerarchia di ereditarietà è “troppo” ampia che indica che intermedi, i tipi possono essere mancanti.

Speculativi Gerarchia: Questo profumo nasce quando uno o più tipi in una gerarchia sono forniti in modo speculativo (cioè, basato su immaginato, piuttosto che le reali esigenze).

Gerarchia: Questo profumo nasce quando una gerarchia di ereditarietà è “eccessivamente” in profondità.

Ribelle Gerarchia: Questo profumo nasce quando un sottotipo rifiuta le modalità previste dal suo supertipo(s).

Rotto Gerarchia: Questo profumo nasce quando un supertipo e il suo sottotipo concettualmente non condividere “È - UN” rapporto conseguente rotto sostituibilità.

Multipath Gerarchia: Questo profumo nasce quando un sottotipo eredita sia direttamente e indirettamente, da un supertipo leader inutili eredità percorsi nella gerarchia.

Ciclico Gerarchia: Questo profumo nasce quando un supertipo in una gerarchia dipende da uno qualsiasi dei sottotipi.


La definizione e la classificazione è descritta in "Refactoring per la progettazione di software di odori:La gestione tecnica di debito".Alcune più rilevanti risorse potrebbe essere trovato qui.

Un modello è un'idea di come risolvere un problema di una certa classe. Un anti-modello è un'idea di come non risolverlo perché attuazione di tale idea si tradurrebbe in cattiva progettazione.

Un esempio: un "modello" sarebbe quella di utilizzare una funzione per il riutilizzo del codice, un "anti-modello" sarebbe quello di utilizzare copia-incolla per lo stesso. Sia risolvere lo stesso problema, ma utilizzando una funzione di solito porta a codice più leggibile e gestibile rispetto copia-incolla.

Un anti-modello è un modo per non risolvere un problema. Ma c'è di più ad esso:. È anche un modo che può spesso essere visto nel tentativo di risolvere il problema

Se davvero si vuole studiare antipattern, ottenere il libro antipattern (ISBN-13: 978-0471197133).

In esso, si definiscono "An antipattern è una forma letteraria che descrive una soluzione che si verificano comunemente ad un problema che genera conseguenze decisamente negative."

Quindi, se si tratta di una pratica di programmazione male, ma non un comune limitato a una sola applicazione, una società o un programmatore, non soddisfa la parte "Pattern" della definizione antipattern.

Un modo comune di fare un pasticcio. Come la classe dio / kitchensink (fa tutto), per esempio.

Un anti-modello è il complemento di un modello di progettazione . Un anti-modello è una soluzione di modello non si dovrebbe usare in una certa situazione.

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 modo.

È interessante notare che un dato modo di risolvere un problema può essere sia un modello e un anti-modello. Singleton è il primo esempio di questo. Apparirà in entrambi i gruppi di letteratura.

Oggi, i ricercatori di ingegneria del software e professionisti usano spesso i termini “anti-modello” e “odore” in modo intercambiabile. Tuttavia, essi non sono concettualmente la stessa. La voce di Wikipedia di anti-modello afferma che un anti-modello è diverso da una cattiva pratica o una cattiva idea da almeno due fattori. Un anti-modello è

  

"A comunemente usata processo, struttura o modello di azione che, nonostante   inizialmente sembra essere una risposta adeguata ed efficace per un   problema, ha in genere conseguenze più male che i risultati positivi “.

Indica chiaramente che un anti-modello viene scelto nella convinzione che si tratta di una buona soluzione (come un modello) per il problema presentato; tuttavia, porta più passività che benefici. D'altra parte, un odore è semplicemente una cattiva pratica che influenza negativamente la qualità di un sistema software. Ad esempio, Singleton è un anti-modello e la classe Dio (o modularizzazione insufficiente) è un odore di design.

Anti-modelli sono modi comuni persone tendono a programmare nel modo sbagliato, o almeno non così buon modo.

Ogni modello di progettazione che sta facendo più male che bene al dato ambiente di sviluppo software sarebbe considerato come anti-modello.

Alcuni anti-modello sono evidenti, ma alcuni non lo sono. Per esempio Singleton, anche se molti lo considerano un buon modello di progettazione vecchio ma ci sono altri che non lo fanno.

È possibile controllare domanda Che cosa è così male per single? per meglio comprendere le diverse opinioni su di esso.

Come in Algoritmo è possibile ottenere la soluzione con la forza bruta, ma si deve pagare molto se la situazione diventare complessa.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top