タグ付けされた質問 「design-patterns」

C ++でPImplイディオムを使用する多くのソースコードが表示されます。その目的はプライベートデータ/タイプ/実装を非表示にすることであるため、依存関係を削除し、コンパイル時間とヘッダーインクルードの問題を減らすことができると思います。 しかし、C ++のインターフェイス/純粋な抽象クラスにもこの機能があり、データ/型/実装を隠すために使用することもできます。また、オブジェクトを作成するときに呼び出し元にインターフェイスを表示させるために、インターフェイスのヘッダーでファクトリメソッドを宣言できます。 比較は次のとおりです。 費用： パブリックラッパー関数の実装を繰り返す必要さえないため、インターフェイスの方法のコストは低くvoid Bar::doWork() { return m_impl->doWork(); }なります。インターフェイスで署名を定義するだけです。 よく理解された： インターフェイステクノロジーは、すべてのC ++開発者によく理解されています。 パフォーマンス： インターフェイス方法のパフォーマンスは、PImplイディオムよりも悪くありません。どちらも余分なメモリアクセスです。パフォーマンスは同じだと思います。 以下は私の質問を説明するための擬似コードです。 // Forward declaration can help you avoid include BarImpl header, and those included in BarImpl header. class BarImpl; class Bar { public: // public functions void doWork(); private: // You don't need …

49 design-patterns  implementations 

私はデザインパターンの学習に興味があり、この主題を学習する上で一流の本と見なされるものを知りたいと思っています。 ベストプラクティス、設計方法論、および設計パターンに関するその他の有用な情報を説明するための事実上の標準である本はありますか？その本はそれを特別なものにしていますか？

49 design-patterns  books 

Beanにチェーンを実装すると非常に便利です。コンストラクター、メガコンストラクター、ファクトリーをオーバーロードする必要がなく、読みやすさが向上します。オブジェクトを不変にしたい場合を除き、欠点は考えられません。その場合、とにかくセッターはありません。これがOOPの慣例ではない理由はありますか？ public class DTO { private String foo; private String bar; public String getFoo() { return foo; } public String getBar() { return bar; } public DTO setFoo(String foo) { this.foo = foo; return this; } public DTO setBar(String bar) { this.bar = bar; return this; } } //...// DTO …

46 design-patterns  object-oriented-design  setters 

Builderパターンを実装するとき、私はしばしば、ビルドを失敗させるタイミングに戸惑いを感じ、数日ごとにその問題について異なる立場を取ることさえできます。 最初にいくつかの説明： 初期の失敗私は、無効なパラメータが渡されるように、オブジェクトを構築するとすぐに失敗することを意味しています。だから、内側SomeObjectBuilder。 後半に失敗し、私は唯一のオブジェクトを構築する上で失敗する可能性があることを意味build()暗黙オブジェクトのコンストラクターを構築するために呼び出すコール。 次に、いくつかの引数： 失敗を遅らせるために：ビルダークラスは、単に値を保持するクラスにすぎないようにします。さらに、コードの重複が少なくなります。 早期の失敗を支持する：ソフトウェアプログラミングの一般的なアプローチは、できるだけ早く問題を検出することです。したがって、チェックする最も論理的な場所は、ビルダークラスのコンストラクター、「セッター」、最終的にはビルドメソッドです。 これについての一般的なコンセンサスは何ですか？

45 java  design-patterns 

MethodAはMethodBを呼び出し、MethodBはMethodCを呼び出します。 MethodBまたはMethodCには例外処理はありません。ただし、MethodAには例外処理があります。 MethodCでは、例外が発生します。 現在、この例外はMethodAにバブリングされており、適切に処理されます。 これの何が問題になっていますか？ 私の考えでは、ある時点で呼び出し元がMethodBまたはMethodCを実行し、それらのメソッドで例外が発生した場合、それらのメソッド内で例外を処理することで得られるものは、本質的にletではなくtry / catch / finallyブロックですそれらは呼び出し先までバブルアップしますか？ 例外処理に関するステートメントまたはコンセンサスは、それだけで実行が継続できない場合にスローすることです-例外。わかった。しかし、try / catchブロックを完全にダウンさせるのではなく、チェーンのさらに上で例外をキャッチしてください。 リソースを解放する必要があるときに理解しています。それはまったく別の問題です。

44 design-patterns  object-oriented-design  exceptions 

実行を停止してはならないいくつかのエラーを処理するためにerror、クライアントがチェックして例外をスローするために使用できる変数があります。これは反パターンですか？これを処理するより良い方法はありますか？この動作の例については、PHPのmysqli APIをご覧ください。可視性の問題（アクセサ、パブリックスコープとプライベートスコープ、クラス内の変数はグローバルですか？）が正しく処理されると仮定します。

44 design-patterns  object-oriented  exceptions  patterns-and-practices  anti-patterns 

21世紀Cを読んで、第6章の「例外的な数値をNaNでマークする」セクションに到着しました。ここでは、仮数部のビットを使用して任意のビットパターンを格納し、マーカーまたはポインターとして使用する方法について説明しています（本の言及そのWebKitはこの手法を使用しています）。 このテクニックの有用性を理解したかどうかはよくわかりませんが、ハック（NaNの仮数の値を気にせずハードウェアに依存している）に見えますが、私は慣れていないJavaのバックグラウンドから来ていますCの粗さ NaNのマーカーを設定および読み取るコードのスニペットを次に示します #include <stdio.h> #include <math.h> //isnan double ref; double set_na(){ if (!ref) { ref=0/0.; char *cr = (char *)(&ref); cr[2]='a'; } return ref; } int is_na(double in){ if (!ref) return 0; //set_na was never called==>no NAs yet. char *cc = (char *)(&in); char *cr = (char *)(&ref); for …

44 design-patterns  c 

ITの学生である私は、最近、教師の1人からデザインパターンに関する概要を説明されました。私はそれらが何のためにあるのかを理解しましたが、いくつかの側面はまだ私を悩ませ続けています。 大多数のプログラマーによって本当に使用されていますか？ 経験といえば、プログラミング中にいくつかの問題があり、しばらくは解決できませんでしたが、Googleと数時間の研究で問題を解決しました。Webのどこかで問題を解決する方法を見つけた場合、これは設計パターンですか？私はそれを使用していますか？ また、開発を開始するとき、あなた（プログラマー）はパターンを探していることに気づきます（ところで、私はどこを見るべきでしょうか？）。もしそうなら、これは確かに私が受け入れ始めなければならない習慣です。 更新：プログラマーがそれらを使用するかどうかを尋ねると、問題を解決するために「ああ、私はそのパターンを使用するべきだ」と思うかどうかを尋ねていると思います。

44 design-patterns 

数年前に実際にコードを整理し始めて以来、MVC / MV *を使用しています。私はそれを長い間使ってきたので、コードを構造化する他の方法を考えることすらできず、インターンになってからのすべての仕事はMVCベースでした。 私の質問は、MVCの没落は何ですか？どのような場合にMVCはプロジェクトにとって悪い選択であり、（より）正しい選択は何ですか？MVCの代替案を調べると、ほとんどすべての結果は異なるタイプのMVCにすぎません。 これが閉じられないように範囲を絞り込むには、Webアプリケーションの場合を考えてみましょう。私はさまざまなプロジェクトのバックエンドとフロントエンドで作業しているので、フロントエンドやバックエンドだけとは言えません。

43 design-patterns  mvc 

コントローラがサービスの代わりにリポジトリを呼び出すのは悪い習慣ですか？ さらに説明する： 優れた設計では、コントローラーがサービスを呼び出し、サービスがリポジトリを使用することがわかります。 ただし、コントローラーにはロジックがない場合や必要ない場合があり、dbからフェッチしてビューに渡すだけでよい場合があります。 そして、私はリポジトリを呼び出すだけでそれを行うことができます-サービスを呼び出す必要はありません-それは悪い習慣ですか？

43 design-patterns  object-oriented  mvc  repository 

私は以前SignalR、いくつかのプロジェクトでリアルタイムのメッセージング機能を実現していました。確実に機能するようで、使い方を学ぶのは非常に簡単です。 少なくとも私にとっての誘惑は、Web APIサービスの開発を放棄し、SignalRすべてに使用することです。 思いやりのある設計によってこれを達成できると思います。もしそうなら、必要なクライアントコードははるかに少なくなります。さらに重要なことは、分割されたインターフェースではなく、サービスへの単一のインターフェースがあることを意味し、最悪の場合、物事がいつレンダリングされるかなどを考えずにこれを接続できることを意味します。 だから、私は知りたい： パフォーマンス以外にすべてのWebサービスの代わりにSignalRを使用しない他の理由はありますか？ SignalRのパフォーマンスは、そうするのが理にかなわないということに関して十分ですか？ 馬鹿げたようなことをせずに、サーバー側のオブジェクトとサービスの定義をクライアント側のサービスアクセスコードに変換できることは、長い間私の夢でしたnode.js。たとえば、興味深いオブジェクトInterestingObjectとそのオブジェクトへのサービスを定義する場合、サービスへCRUDのInterestingObjectService標準のURLルートを定義できます-"/ {serviceName} / {methodName}"-しかし、アクセスするクライアントコードを記述する必要がありますサービス。オブジェクトは、サーバーとバックにクライアントから渡されようとしているので、する実際的な理由はありません持っているがクライアント側のコードでオブジェクトを明示的に定義します。また、CRUD操作を実行するルートを明示的に定義する必要はありません。このすべてを標準化する方法があるはずだと思うので、WinFormsまたはJavaを書いている場合と同じように、サービスへのアクセスがクライアントからサーバーへ、そして透過的に戻るという仮定の下でクライアントを書くことが可能ですアプレットまたはネイティブアプリ、またはあなたが持っているもの。 SignalRが従来のWebサービスの代わりに使用するのに十分であれば、これを実現するための実行可能な方法である可能性があります。SignalRには、既に説明したサービスのようにハブを機能させる機能が既に含まれているため、この機能すべてをすぐに反映できる共通ベース（CRUD）サービスを定義できます。そうすれば、ほとんどの場合、サービスへのアクセスを許可することができ、慣習によってアクセスできるものにアクセスするためにコードを書き直す煩わしさを省くことができます。 DOM。 私の編集を読んだ後、私はそれが少し無意味であるように感じるので、私が何を得ているかについて質問があるかどうか私に尋ねてください。基本的に、サービスへのアクセスは可能な限り透過的にする必要があります。

42 design-patterns  rest  web-api  websockets 

イベントのポーリングがオブザーバーパターンを使用するよりも優れているシナリオはありますか？私はポーリングを使用することを恐れており、誰かが良いシナリオをくれた場合にのみ使用を開始します。私が考えることができるのは、オブザーバーのパターンがポーリングよりも優れていることだけです。このシナリオを考慮してください： あなたは自動車シミュレーターをプログラミングしています。車はオブジェクトです。車の電源が入ったらすぐに、「vroom vroom」サウンドクリップを再生します。 これは2つの方法でモデル化できます。 ポーリング：車オブジェクトを毎秒ポーリングして、オンになっているかどうかを確認します。オンになったら、サウンドクリップを再生します。 オブザーバーパターン：車をオブザーバーパターンのサブジェクトにします。それがオンになったときに、すべてのオブザーバーに「オン」イベントを公開します。車をリッスンする新しいサウンドオブジェクトを作成します。サウンドクリップを再生する「on」コールバックを実装します。 この場合、オブザーバーパターンが勝つと思います。第一に、ポーリングはよりプロセッサを集中的に使用します。第二に、車がオンになったときにサウンドクリップがすぐに発射されない。ポーリング期間のため、最大1秒のギャップが生じる可能性があります。

41 design-patterns 

たぶん少し冗談かもしれませんが、Googleでどこにもこの答えが見つからないので、ソフトウェアエンジニアリングが答えを持っていることを確認します。 ヘルパーとは何ですか？ セマンティクスが深く意味のあるように、どこでも使用されている名前（モジュール名、クラス名、メソッド名）を見てきましたが、コンピューターサイエンスの文脈では（学位はありませんが）どこにも説明や定義を見たことがない！ デザインパターンですか？それはアルゴリズムですか？私はかつてモジュールとクラスの両方がsomethingthinghelper（somethingthingはかなり一般的でもある）と呼ばれるプログラムで働いていましたが、すぐにそれを私にとって意味のあるものに名前を変更しましたが、ここで何かを見逃しているように感じます！

40 design-patterns  algorithms  semantics 

最終的にいくつかの基本的なパターンを習おうと真剣に始めたので（キャリアの非常に遅いですが、それは別の話です）、私はファクトリーパターンとアブストラクトファクトリーの違いを理解しようとしています。 これら2つのパターンの主な違いは何ですか？ Factoryメソッドは継承を介してオブジェクトを作成し、Abstract Factoryはオブジェクトの構成を介してオブジェクトを作成することを理解していますが、実際的な観点からは、それぞれがどのように機能するかを正確に視覚化するのにまだ苦労しています。

40 design-patterns  factory-method 

ジェイム・ゴスリングは言った 「可能な限り、実装の継承を避ける必要があります。」 代わりに、インターフェイスの継承を使用します。 しかし、なぜ？キーワード "extends"を使用してオブジェクトの構造を継承しないようにし、同時にコードをオブジェクト指向にする方法はありますか？ 「書店で本を注文する」などのシナリオで、この概念を示すオブジェクト指向の例を教えてください。

40 java  design  object-oriented-design  design-patterns