ソフトウェアデザインパターンを使用しない場合はどうなりますか？[閉まっている]

ソフトウェアデザインパターンを使用しない場合、どのような問題に直面する可能性がありますか？標準のオブジェクト指向技術を使用して設計にアプローチする際の問題について教えてください。

ポイントがありません。

世界に構造パターンが存在するように、ソフトウェアデザインを行う場合、デザインパターンは本質的に存在します。物の名前を知らなくても、最終的には特定の物理構造が特定の問題に適していることがわかります。木材/金属棒などの三角形は、非常に安定した構造ですが、平面上にあることがわかります。正方形のレンガには、丸いレンガよりも特定の利点があることがわかります...

同様に、特定のソフトウェア構造は何らかの方法で一意または最適です。最終的にそれらを見つけ、それらの名前を知っているかどうかに関係なくそれらを使用します。それが設計パターンの核心です-これらは、経験豊富なプログラマーがとにかく知っていて使用しているこれらの構造の名前です。これにより、プログラマーはより均一かつ簡潔にコミュニケーションを行うことができます。また、プログラマはパターンの概念をより意識的に考えることができます。

だから私が作ろうとしている2つの重要なポイント：

1. デザインパターンを使用することはできません。
2. 使用しているものの名​​前がわからないため、チームでの作業が困難になります。

過去を思い出せない人は、過去を繰り返すと非難されます。

設計によって引き起こされた問題以外の特定の問題に直面することはありません。そして、気づかずにパターンを使用することになり、自分でパターンを理解するのに時間を費やしただけです。事前にパターンを知っておくことで、デザインでそれらを見つけやすくなり、多くの個人によって証明されているという大きな利点が得られます。

今日開発されているものはすべて以前の知識に基づいているため、無視しても意味がありません。数百年前に大聖堂を建てた人々が直面している問題を知らずに、今日の超高層ビルを想像してみてください。

ソフトウェアデザインパターンを使用しない場合、どのような問題に直面する可能性がありますか？

ソフトウェアを作成できないという問題が発生します。

変数は設計パターンです。

メソッドは設計パターンです。

演算子（加算、減算など）は設計パターンです。

ステートメントはデザインパターンです。

値は設計パターンです。

参照はデザインパターンです。

式はデザインパターンです。

クラスはデザインパターンです。

...

プログラミングで常に行うことはすべて設計パターンです。ほとんどの場合、パターンは思考に深く染み込んでおり、「デザインパターン」と考えるのをやめています。「シングルトンパターン」などのように学習しなければならないことは、使用している言語に（まだ）焼き付けられていない単なるパターンです。

標準のオブジェクト指向技術を使用して設計にアプローチする際の問題について教えてください。

いいえ。この質問の意味がわかりません。デザインパターンは「標準的なオブジェクト指向技術」です。これがデザインパターンです。設計パターンは、特定の問題、特に（必ずしもではないが）オブジェクト指向言語の問題を解決するための標準的な手法です。

デザインパターンのポイントを理解することは、レターに使用するよりも重要です。少なくとも私が慣れ親しんでいる言語パラダイムでは、いくつかのパターンは馬鹿げています。IMOは、デザインパターンを盲目的に単純に使用し、実際にそれらを理解せずに単純に使用するプログラマーです。しかし、アイデアに慣れて、価値があるかどうかを自分で決める人は、どちらよりもはるかに強力なプログラマになる可能性があります。

とは言っても、フライウェイトのポイントが何なのか、私には！@＃$ ingのアイデアはありません。（多くの助けになった別のウィキペディアのエントリのコメントを参照してください）

ウィキペディアのデザインパターンに関するエントリをお勧めします。非常に簡潔かつ明確に書かれています。与えられたデザインパターンに悩まされるかもしれない理由を知るのに非常に役立ちます。私は個人的には最も単純なものが最も有用であると思う傾向があり、自分のニーズに合わせてパターンの特定の実装を変更することを二度と考えません。

それらは青写真ではなくアイデアです。一部の言語では、まったく良いアイデアではありません。他の人では、それらは、言語の設計上の弱点を克服するための手掛かりであると正しく見られています。とにかく、あなた自身の好ましい解決策を決定する前に、それらを調べて、彼らが克服しようとしている課題を理解しようとすることは害になりません。

どのような問題に直面しますか？あなたがすでにすべてを理解しているプログラミングの天才でない限り、機会を逃し、必要以上に問題に時間を費やすかもしれません。人気のあるプログラミングアイデアの批判的な目を維持することは重要ですが、人々が解決しようとしていることを理解することは決して害になりません。

あなたが直面する主な問題は、あなたが車輪を再発明することです。それらは、頻繁に、予測可能な方法で表示されるため、パターンと呼ばれます。

設計パターンに従ったとしても、最終的に悪い設計になる可能性があります。デザインパターンは自然なものであり、最終的にデザインでそのフレーバーを使用することになります。どのパターンも使用しないように、一生懸命努力する必要があります。デザインパターンを非難する理由はありません。より重要なことは、ニーズに合った適切なパターンを選択することです。

あなたはそれを気付かずに常にデザインパターンを使用しています。一般的な言語の標準ライブラリの多くは、設計パターンを考慮して設計されています。例はFileReader、デコレータデザインパターンを使用して設計されたJavaのライブラリです。自分のコードについて話すと、（ほとんどの場合）デザインパターンを使用する必要はありません。デザインパターンは「よく発生する問題に対する再利用可能なソリューション」です。つまり、よりクリーンで保守性の高いコードを書くのに役立ちます。したがって、スパゲッティコードで終わることを避けたいというのはあなた次第です。