Lettura consigliata per l'architettura di progettazione dell'applicazione (orientata agli oggetti)? [duplicare]

Naviga le tue risposte
10

Nella vita non importa se fai una cosa per 15 anni. finirai per svegliarsi un giorno e chiedere cose equivalenti a "come faccio a camminare?" :)

La mia domanda specifica è che come nuovo concorrente di C # e OOP sto entrando in molti piccoli "dettagli" che devono essere affrontati.

Scritto molto codice in VB.NET / cobol / semplice php e.t.c sicuramente non aiuta molto nel mondo OOP ...

Quindi, anche dopo aver letto libri di livello base per C # e aver guardato alcuni video, ho scoperto recentemente il "modello di fabbrica" per le applicazioni.

Gradirei se qualcuno di voi suggerisse qualche lettura sull'architettura di progettazione dell'applicazione per ulteriori letture ...

    
posta e4rthdog 07.04.2012 - 13:41
fonte

2 risposte

12
risposta data 07.04.2012 - 15:56
fonte
21

SOLID è un ottimo punto di partenza. Questi sono i 5 principi di base del design orientato agli oggetti, che indicano quanto segue:

  1. Principio di responsabilità singola : i tuoi oggetti (classi) dovrebbero avere responsabilità singola . In altre parole, dovrebbe esserci una sola ragione per cambiare data entità / classe.
  2. Principio aperto / chiuso : le classi devono essere aperte per estensione, chiuse per modifica . Le classi stesse non dovrebbero cambiare molto, tuttavia dovrebbero fornire punti di estensione in modo che il loro comportamento possa essere modificato / ampliato dai futuri implementatori.
  3. Principio di sostituzione di Liskov : ogni oggetto dovrebbe essere sostituibile dal sottotipo più specifico senza alterare la correttezza del programma. Ad esempio, se qualcosa funziona con il tipo Mammal , dovrebbe funzionare altrettanto bene con Tiger e Panda types.
  4. Principio di segregazione dell'interfaccia : per Wiki "molte interfacce specifiche per il cliente sono migliori di un'interfaccia generica". Questo va in coppia con SRP e design disaccoppiato - dovresti preferire più entità specifiche invece di singolo generico .
  5. Principio di inversione delle dipendenze : dovresti progettare per contratto, non con un'implementazione concreta. Che spesso si restringe ad avere contratti (interfacce) passati arround come dipendenze invece delle loro implementazioni (classi).

La lettura di questi argomenti dovrebbe probabilmente generare nuove domande e portarti a ulteriori ricerche. Che dovrebbe probabilmente includere (tra gli altri) seguendo concetti importanti:

risposta data 07.04.2012 - 16:23
fonte

Leggi altre domande sui tag

Perché i conteggi delle visualizzazioni dei messaggi sono in ritardo sulla maggior parte dei siti Web? Cosa fare quando uno sprint è terminato in anticipo?