Che tipo di problemi posso affrontare, se non userò Modelli di progettazione software? Puoi parlarmi dei problemi di approccio al design usando tecniche standard orientate agli oggetti?
Ti manca il punto.
I design pattern esistono intrinsecamente quando si progetta il software, proprio come esistono schemi strutturali nel mondo. Anche se non conosci il nome delle cose, alla fine scoprirai che certe strutture fisiche sono adatte a certi problemi. Scoprirai che una forma triangolare di barre di legno / metallo / ecc. È una struttura molto stabile, ma solo su un piano. Scoprirai che i mattoni quadrati hanno alcuni vantaggi rispetto a quelli rotondi ...
Allo stesso modo, alcune strutture software sono in qualche modo uniche o ottimali. Alla fine li troverai e li userai a prescindere se conosci i nomi per loro. Questo è il nucleo di ciò che sono gli schemi di progettazione: sono nomi per queste strutture che i programmatori esperti conoscono e utilizzano comunque. Fornisce ai programmatori la possibilità di comunicare in modo molto più uniforme e conciso. Inoltre, consente ai programmatori di pensare più consapevolmente al concetto di pattern.
Quindi i due punti chiave che sto cercando di fare:
Coloro che non riescono a ricordare il passato sono condannati a ripeterlo.
Non dovrai affrontare problemi specifici se non quelli sollevati dal tuo progetto. E col tempo finirai per usare gli schemi senza essere consapevole, hai appena passato il tempo a pensarli da solo. Conoscere in anticipo i modelli li rende più facili da individuare nel design e portare il maggior vantaggio che sono provati da un numero di individui.
Tutto ciò che viene sviluppato oggi si basa in gran parte su conoscenze precedenti, non avrebbe senso ignorarlo. Immagina oggi di costruire un grattacielo senza conoscere i problemi affrontati dalle persone che hanno costruito cattedrali alcune centinaia di anni fa.
What kind of problems may I face, if I won't use Software Design Patterns?
Avrai il problema di non essere in grado di scrivere alcun software.
Le variabili sono un modello di progettazione.
I metodi sono uno schema di progettazione.
Gli operatori - addizione, sottrazione, ecc. - sono un modello di progettazione.
Le istruzioni sono un modello di progettazione.
I valori sono uno schema di progettazione.
I riferimenti sono uno schema di progettazione.
Le espressioni sono un modello di progettazione.
Le classi sono uno schema di progettazione.
...
Tutto ciò che fai nella programmazione in ogni momento è un modello di design . Il più delle volte il pattern è così radicato nel tuo pensiero che hai smesso di pensarlo come "un modello di progettazione". Le cose che devi imparare come "il modello singleton" e così via sono semplicemente modelli che non sono (ancora) stati cotti in qualunque lingua tu stia usando.
Can you tell me about the problems of approaching the design using standard object-oriented techniques?
No. Non ho idea di cosa significhi questa domanda. Modelli di design sono "tecniche standard orientate agli oggetti" - questo è ciò che li rende modelli di progettazione . Un modello di progettazione è una tecnica standard per risolvere un particolare problema, in particolare (anche se non necessariamente ) in un linguaggio orientato agli oggetti.
Capire il punto di un modello di progettazione è più importante che utilizzarlo per la lettera. Alcuni schemi sono, IMO, stupidi, almeno nei paradigmi linguistici a cui sono abituato. IMO, un programmatore che usa semplicemente schemi di progettazione alla cieca e senza capirli veramente è un programmatore peggiore di colui che vorrebbe pensare attraverso le cose da solo. Ma qualcuno che si familiarizza con le idee e poi decide da solo se valga la pena è probabile che sia un programmatore molto più strong di entrambi.
Detto questo, non ho idea di cosa sia il punto di peso reale e non mi vergogno di ammetterlo. (vedi i commenti per un'altra voce di wikipedia che ha aiutato molto)
Raccomando la voce di wikipedia sui modelli di design. È scritto in modo molto conciso e chiaro. Molto utile per avere un'idea del motivo per cui si potrebbe dare fastidio con un determinato modello di progettazione o no. Personalmente tendo a trovare quelli più semplici i più utili e non ci penserei due volte a modificare una determinata implementazione di qualsiasi pattern in base alle mie esigenze.
Sono idee, non progetti. In alcune lingue non sono affatto buone idee. In altri, sono giustamente considerati dei kludges per superare le debolezze del design di una lingua che potrebbero essere meglio compensate attraverso una minore complessità. Indipendentemente da ciò, non fa male esaminarli e cercare di capire le sfide che devono superare prima di decidere le tue soluzioni preferite.
Che tipo di problemi affronterai? Potresti perdere opportunità e dedicare più tempo ai problemi di quanti ne avresti bisogno, a meno che tu non sia un genio della programmazione che ha già capito tutto. È importante mantenere un occhio critico delle idee di programmazione popolari, ma non fa mai male capire che cosa pensano le persone che stanno risolvendo perché ciò darà maggiore chiarezza alle tue soluzioni / approcci preferiti.
Il problema principale che dovrai affrontare è che reinventerai la ruota . Sono chiamati modelli perché appaiono spesso e in modo prevedibile.
Anche se segui gli schemi di progettazione potresti finire con un cattivo design. I modelli di design sono naturali e finirai per usarne alcuni nel tuo design. Dovrai davvero impegnarti a non usare nessuno dei modelli. Non c'è motivo di condannare i modelli di progettazione, cosa più importante è scegliere i modelli giusti per le proprie esigenze
Stai utilizzando sempre schemi di progettazione senza rendertene conto. Molte librerie standard nelle lingue popolari sono progettate pensando ai modelli di progettazione. Un esempio è la libreria FileReader di Java che è progettata utilizzando il schema di progettazione di un decoratore . Ora parlando del tuo proprio codice, non sei obbligato a utilizzare modelli di progettazione (nella maggior parte dei casi). Un modello di design è un "soluzione riutilizzabile per un problema comune" , il che significa che ti aiuterà a scrivere un codice più pulito e più gestibile quindi dipende solo da te quanto vuoi evitare di finire con il codice spaghetti.
Leggi altre domande sui tag design-patterns