design-patterns - 設計パターンがソフトウェアを悪化させるのはいつですか?

Question

設計パターンがソフトウェアを悪化させるのはいつですか?

GUI とロジックの間でファサードパターンを使用するプログラムを見たことがあります。彼らは、これを介してオブジェクトを転送することはできないと考えていたため、コーディングが困難なプリミティブ型のみが使用されました。

score 21 · Accepted Answer

それを誤用したり、場合によってはさらに悪いことに、パターンを不必要に使用したりします。コードを分析するとき、当然のことながら、最初はそこにあるすべてのものには理由があると思い込み、何かの理由がわからない場合、最も安全なデフォルトの仮定は、何かが欠けているということです。そして、未知の方法や予測不可能な方法でコードを壊す危険を冒したくないので、コードをいじる前に、コードがそこにある理由を理解しようとして時間を無駄にしています.

score 17 · Accepted Answer

何十年もの間、プログラマーはしばしば、そのプラクティスが優れている理由を学ぶよりも、理解していないプラクティスを適用することによってソフトウェアを悪化させることに時間を費やしてきました。特定のツール/キーワード/フレームワークを使用すると、プログラマーが物事を台無しにしているときに、洗練されたように感じることがあります。一般的な例:

多くの try/catch/finally ブロックを投入すると、実際にはそうではないのに、プログラマーはエラー処理スキームを持っているように感じることがあります。
SQL をストアドプロシージャに置き換えると、プログラマーは、実際にはそうでない場合でも、魔法のように効率性、再利用性、カプセル化を提供するデータアクセス層を持っているように感じることができます。
クラスを使用することで、多くのプログラマーはオブジェクト指向プログラミングに取り組んでいると思い込んでいますが、実際にはそうではありません (またはオブジェクト指向の表面をなぞっているだけです)。

このリストは永遠に続く可能性があります。私たち人間は常に近道を探すため、この傾向は常にあり、今後も続くでしょう。パターンは現在人気があるため、これはパターンでよく見られます。根本的な問題は同じです。開発者は、ソフトウェア開発がいかに複雑であるかを尊重しておらず、やみくもに実装されたパターンやプラクティスを学習と謙虚さの代用として考えています。

ソリューション？言うのは難しい。後輩の開発者にCode Completeなどを渡して、これは特定の状況に原則を適用することであり、優れた開発者はそれをシンプルに保つことであるということを理解するのに役立ちますが、間違いはありません。

score 4 · Accepted Answer

4

名前がシングルトンの場合

于 2009-11-30T14:36:01.737 に答える

score 3 · Accepted Answer

設計パターンを誤って使用し、間違った状況で適用すると、ソフトウェアが悪化する可能性があります。常識は、デザインパターンの完璧なパートナーであるべきです。

パターンの誤用は、問題に関連する力と、その問題に対するパターン提案された解決策の理解の欠如に関連している場合があります。また、パターンの意図が誤解されて誤用される可能性もあります。

パターンをよりよく理解するには、アンチパターンの概念について学び、GOF の本よりも多くを読む必要があります。1 つの提案は、パターンハッチングを読んでGOF の概念を補足することです。

score 3 · Accepted Answer

デザインパターンは、共通のコード構造に名前を付けて文書化する方法にすぎません。そのため、すべてのパターンが優れていると結論付けるべきではありません。設計パターンの文書化に優れた仕事をしている人々 (GoF など) は、常に、パターンの説明にパターンを使用する必要がある場合と使用しない場合を説明するセクションを含めています。そのため、ほとんどのデザインパターンの本の要点の半分は、「デザインパターンがソフトウェアを悪化させるのはいつですか?」という質問に答えることです。

多くの経験の浅い開発者は、適切な使用セクションをわざわざ学ぼうとせず、不適切なパターンを適用してしまいます。これが、デザインパターンを取り巻く多くの否定的な原因だと思います。

結論として、この質問に対する答えは次のようになります。設計パターンを読んでみればわかるはずです。

score 2 · Accepted Answer

過去 1 年間、私がかなりの時間を費やしてデザインパターンとその実装を学んできたことは興味深いことです。ちょうどデザインパターンに対する反発が強まっているようです。デザインパターンは、公正かどうかにかかわらず、ソフトウェアを定量化可能なスキルにするはずのプロセスや方法論の仲間入りをしました。デザインパターンの問題は、スキルの低いプログラマーがそれらを「ゴールデンハンマー」として使用していることだと思います。彼らは戦略パターンを学びますが、これは価値のあることですが、コードを過度に複雑にし、不要な機能と「拡張性」を追加して、どこでもそれを使用します。

パターンへのリファクタリングには計り知れない価値があると私は信じています。なぜなら、既存のコードをクリーンアップするからです。パターンは貴重なコミュニケーションツールでもあり、コードをより高度な用語で記述できます。しかし、クールで市場性のあるデザインパターンをソフトウェアに詰め込む (別名「レジューム駆動型開発」) ことは、悪い考えです。

score 1 · Accepted Answer

1

問題のパターンが間違っている場合。

于 2009-11-30T14:56:15.160 に答える

score 1 · Accepted Answer

コーディングの問題を解決するための青写真としてではなく、設計パターンを絶対的な構成要素として使用すると、ソフトウェアは悪化します。

それらは、問題が組み立てられるブロックになることを意図していませんでした。それらは、オブジェクトの命名規則に表示されるべきではありません。オブジェクトを *Factory や *Singleton、またはその他のパターン名で呼ぶべきではありません。特定のパターンにロックされるべきではありません。

それらは、複雑なコードをより迅速に構築するのに役立つ、本当に良い「出発点」です。必要に応じてアイデアを組み合わせることができます (またそうすべきです)。ドキュメンテーション？オブジェクト名前空間ではなく、それがコメントの目的です...

ポール。

score 1 · Accepted Answer

これはアンチパターンと呼ばれ、例については AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis 本を参照してください。

score 1 · Accepted Answer

1

たとえば、ここでアンチパターンについて読むことができます。

于 2010-03-30T12:15:10.487 に答える

score 1 · Accepted Answer

一般に、コード作成者が、パターンはソフトウェアを構築するためのレゴのようなブロックであるという態度をとると、非常に奇妙なコードが得られます。

score 1 · Accepted Answer

1

簡単なことを難しくするもの (EJB)

于 2009-11-30T14:48:06.580 に答える

score 0 · Accepted Answer

戦略パターンは、必要がなければソフトウェアを悪化させる可能性があると思います。戦略パターンは基本的に機能の一部を「プラグイン可能」にします。つまり、さまざまな実装をその場で切り替えることができます。ただし、このプラグイン可能な機能は、構成に多くの複雑さ（場合によっては余分なオーバーヘッド）を追加することが多く、不要な場合は無駄になります。このパターンは頻繁に悪用されています。

score 0 · Accepted Answer

Levi さん、特定のパターンを使用するのは、それによって私の生活 (およびコードの保守を担当する人々) が楽になる場合だけです。適切なデザインパターンを選択することは、コメントと同じくらい重要だと思います。コメントの方が重要なのではないでしょうか? デザインパターンの大部分は、私たちが開発者として何年も使用してきた手法を正式に記述したものであることがわかります。

エルダイト・トログロダイト

score 0 · Accepted Answer

誤解されたり誤って適用されたりしたパターンは、コードを改善するどころか悪化させる傾向があります。また、パターンのためだけに適用される任意のパターン (たとえば、「私たちは SOA になりました!」など)。一般に、パターンが「コード臭」を導入する場合、その使用は疑わしいはずです。

score 0 · Accepted Answer

人々がコードを分析し、ビジネスロジックよりもパターンの理解に多くの時間を費やす場合。パターンは良いものですが、関係者全員がパターンの読み方を知っている必要があります。

score 0 · Accepted Answer

ソフトウェアが解決しようとしているすべての問題ではなく、1 つの問題を解決することに基づいてパターンを選択するときはいつでもそうです。

逆に、考えられるすべての最終的なユースケースに合わせてソリューションを過度に設計しようとすると、大部分のユースケースに適合するには大きすぎるデザインパターンを使用することになります。

したがって、理想的なパターン/そのパターンへの準拠のレベルは、両極端の間にあるものになります。

score 0 · Accepted Answer

デザインパターンがうまくいかない方法はたくさん考えられます。GoF ブックは、それが言及するすべてのパターンの問題、解決策、および欠点を説明しています。- パターンは問題の解決策です。その問題があなたの問題ではない場合、おそらくそれはアンチパターンになるでしょう。- パターンには欠点があり、それらに注意する必要があります。- いらない時。パターンは多くのクラスを暗示している可能性があり、将来発生する可能性があるがまだ発生していない問題を解決しようとしています。- 仕組みを理解せず、間違った実装をすると、アンチパターンにもなります。役に立たないクラスやコードがたくさんできてしまいます。・ハマり始めた時。深すぎる階層、ポリモーフィズムやシングルトンの不適切な使用などが問題を引き起こす可能性があります。

他にも理由がありそうですね…

design-patterns - 設計パターンがソフトウェアを悪化させるのはいつですか?

18 に答える 18

Related

Reference