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

私は.NET開発者で、今週末にRuby on Railsで遊ぶ機会がありました。 .NETでは、個別のクラスライブラリプロジェクトを作成することにより、アプリケーションのレイヤーを分離します。設計パターンの観点から、Railsでもそれを行う必要がありますか、それともすべてが含まれる1つのプロジェクトだけですか？

11 design-patterns  .net  ruby-on-rails 

コマンドパターンのこの古い実装があります。これは、すべてのDIOperation実装を通じてContextを渡すようなものですが、後で学習と学習のプロセス（決して停止しない）で最適ではないことに気付きました。また、ここでの「訪問」は実際には合わず、混乱するだけだと思います。 また、コマンドは他のことについて何も知らず、現時点ではすべてが同じキーと値のペアを共有するため、コードのリファクタリングを考えています。どのクラスがどのKey-Valueを所有しているかを維持するのは非常に難しく、変数の重複につながる場合があります。 ユースケースの例：CommandBがCommandAによって設定されるUserNameを必要とするとしましょう。CommandAはキーUserNameForCommandB = Johnを設定する必要がありますか？または、共通のUserName = John Key-Value を共有する必要がありますか？UserNameが3番目のコマンドで使用されるとどうなりますか？ この設計を改善するにはどうすればよいですか？ありがとう！ class DIParameters { public: /** * Parameter setter. */ virtual void setParameter(std::string key, std::string value) = 0; /** * Parameter getter. */ virtual std::string getParameter(std::string key) const = 0; virtual ~DIParameters() = 0; }; class DIOperation { public: /** * …

11 c++  design-patterns  design 

任意のタイプのファイルの解析を担当するモジュールを検討してください。ここですでに説明したように、この問題に取り組むために戦略パターンを使用することを考えています。この質問に進む前に、リンクされた投稿を参照してください。 product.xmlファイルのコンテンツを必要とするクラスBを検討してください。このクラスは、XMLファイルを解析するために、Parserインターフェースの適切な具象実装者をインスタンス化する必要があります。適切な具象実装者のインスタンス化をファクトリに委任して、クラスBが「has-a」ファクトリになるようにすることができます。ただし、クラスBは、具体的な実装者をインスタンス化するためにファクトリに「依存」します。これは、クラスBのコンストラクターまたはセッターメソッドをFactoryに渡す必要があることを意味します。 したがって、ファイルを解析する必要があるファクトリとクラスBは、互いに密接に結合されます。私はこれまで説明してきたことについて完全に間違っている可能性があることを理解しています。私は、注入される依存関係がファクトリであるシナリオで依存関係の注入を使用できるかどうか、そしてこれを実装する正しい方法は何であるかを知りたいので、ユニットテストでファクトリをモックするなどの領域を活用できます。

11 java  design-patterns  dependency-injection 

Web開発の分野では、フォーム送信のフィールドが無効な場合にもPOST / Redirect / GETを実行することをお勧めしますか？ 通常、この場合、機密性の高いトランザクションは発生しません。ただし、それにもかかわらず、POST / Redirect / GETパターンを利用することは依然として良い習慣であるという主張をすることができますか？

11 web-development  design-patterns  programming-practices 

今週はソフトウェアパターン試験があり、研究対象のトピックの1つは、遠心性カップリングと遠心性カップリングです。 パッケージが他の多くのタイプに依存する場合、そのパッケージのCe（遠心性結合）が高いことを理解しています。 例えば： class Car{ Engine engine; Wheel wheel; Body body; } このクラスは、エンジン、ホイール、およびボディのタイプに依存するため、遠心性の高いカップリングになります。 一方、他のいくつかのパッケージ（車、飛行機、自転車）に依存している場合、タイプ「ホイール」のCa（求心性結合）は高くなります。 私たちの試験で考えられる質問の1つは、Efferent / Afferentカップリングがいつ良いか悪いかです。論理的には、プログラムが高いEfferent / Afferentカップリングのパッケージ/クラスを必要とするため、これは私には奇妙に思えます。 誰かが、高遠心性または求心性結合がいつ/どこで良い/悪いかの例を持っていますか?? ありがとう！

11 design-patterns  patterns-and-practices  coupling 

bodyタグへのスタイルの適用はページ全体に適用されるため、 body { font-family: Verdana } ページ全体に適用されます。これは次の方法でも実行できます * {font-family: Verdana} これはすべての要素に適用されるため、同じ効果があるようです。 最初の例ではスタイルがページ全体の1つのタグに適用され、2番目の例では各HTML要素にフォントが適用されるという原則を理解しています。私が求めているのは、それを行う際の実際的な違いは何か、意味するものは何か、そして他のものを使用することにつながる理由、状況、またはベストプラクティスは何かということです。 副作用の1つは確かに速度（+1ロブ）です。機能の面でどちらかを選択する実際の理由に最も興味があります。

11 design-patterns  coding-style  html  css 

最近、同僚と話していて、彼の会社はMVCデザインパターンをPHP拡張機能として追加しようとしていると言いました。 彼は、Controllers, Models and Viewsパフォーマンスを向上させるために言語構成要素に追加するCコードを書いたと説明しました。 MVCはWebアプリケーションで広く使用されているアーキテクチャ設計パターンであることがわかりましたが、たとえばコントローラー用の言語構造を持つ言語に出くわす必要があります。 デザインパターンを言語に統合するIMHOは、優れたオブジェクト指向デザインの重要性を強調できます。 それでは、なぜ最もよく使用されるデザインパターン（MVC、ファクトリ、ストラテジーなど）が言語構成要素に追加されないのですか？ 質問が広すぎると思われる場合は、質問をPHPのみに制限できます。 編集： プロジェクトを開発するときにデザインパターンを使用する必要があることを意味するわけではありません。実際、私はそれが機能する限りシンプルに保つ方法論を推進しています。

11 programming-languages  design-patterns  language-design  language-features 

「バー/クラブ」（あなたが飲む/社交する場所）を表す2つのオブジェクトがあります。 あるシナリオでは、バーの名前、住所、距離、スローガンが必要です 別のシナリオでは、バー名、住所、ウェブサイトのURL、ロゴが必要です したがって、同じものを表すが異なるフィールドを持つ2つのオブジェクトがあります。 不変オブジェクトを使用するのが好きなので、すべてのフィールドはconstructorから設定されます。 1つのオプションは、2つのコンストラクターを持ち、他のフィールドをヌルにすることです。 class Bar { private final String name; private final Distance distance; private final Url url; public Bar(String name, Distance distance){ this.name = name; this.distance = distance; this.url = null; } public Bar(String name, Url url){ this.name = name; this.distance = null; this.url = url; …

11 java  design-patterns  object-oriented  interfaces  inheritance 

さまざまなプロジェクトのコードに、コードの臭いや悪いことのように見える何かに気づきましたが、対処できません。 「きれいなコード」を書き込もうとしている間、コードを読みやすくするためにプライベートメソッドを使いすぎる傾向があります。問題は、コードが確かにきれいであるが、テストするのが難しいことです（そう、私はプライベートメソッドをテストできることを知っています...）、一般的に私には悪い習慣のようです。 次に、.csvファイルからデータを読み取り、顧客のグループ（さまざまなフィールドと属性を持つ別のオブジェクト）を返すクラスの例を示します。 public class GroupOfCustomersImporter { //... Call fields .... public GroupOfCustomersImporter(String filePath) { this.filePath = filePath; customers = new HashSet<Customer>(); createCSVReader(); read(); constructTTRP_Instance(); } private void createCSVReader() { //.... } private void read() { //.... Reades the file and initializes the class attributes } private void readFirstLine(String[] inputLine) …

11 design-patterns  object-oriented-design  clean-code  encapsulation 

一般的に次の状態を経る自動化されたプロセスがあるとしましょう。スケジュール済み-開始済み-検証中-実行中-完了 その上、これらのプロセスは、エラーまたは明示的なユーザーのキャンセルにより、途中で終了する可能性があります。 私の最初の衝動は、単純にエラーを追加し、可能なステータス値のリストにキャンセルすることですが、結果をステータスから分離する（概念的な）利点について疑問に思っていました（エラーとキャンセルは完了状態とは単に異なる状態）。

11 design-patterns  database-design 

スタックやキューなどのカスタムデータ構造を設計しているとしましょう（たとえば、論理的に同等なメソッドpushやpop破壊的なアクセサーメソッドを持つ他の任意の順序付きコレクションなど）。 IEnumerable<T>各反復でポップされたこのコレクションに対して（具体的には.NETで）イテレータを実装している場合、それはブレークIEnumerable<T>の暗黙のコントラクトですか？ IEnumerable<T>この暗黙の契約を持っていますか？ 例えば： public IEnumerator<T> GetEnumerator() { if (this.list.Count > 0) yield return this.Pop(); else yield break; }

11 .net  design-patterns  iterator 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 不思議なことに繰り返し発生するテンプレートパターンについて考えています。 私はそれが非常に便利だと思うし、多くのタスクに対してかなりうまく調整できる。しかし、私は認めなければなりません、私は野生でCRTPコードの多くを見ません。 把握するのは難しいですか？仮想機能は全体的に簡単ですか？仮想キーワードが表示されるケースの90％で使用すべきではありませんか？

11 c++  design-patterns 

この例を考えてみましょう： ウェブサイトを持っています。これにより、ユーザーは投稿（何でも可能）を作成し、投稿を説明するタグを追加できます。コードには、投稿とタグを表す2つのクラスがあります。これらのクラスをPostおよびと呼びましょうTag。 Post投稿の作成、投稿の削除、投稿の更新など Tagを処理します。タグの作成、タグの削除、タグの更新などを処理します。 欠落している操作が1つあります。タグと投稿のリンク。私は誰がこの手術をすべきかと格闘しています。どちらのクラスにも等しく適合する可能性があります。 一方では、PostクラスにTagaをパラメーターとして受け取り、タグのリストに格納する関数を含めることができます。一方、Tagクラスが取る関数可能性がありPost、パラメータとして及びリンクTagにしますPost。 上記は私の問題の一例です。私は実際には、すべて類似した複数のクラスでこれに直面しています。それは両方に等しく適合する可能性があります。実際に両方のクラスに機能を配置するのではなく、この問題を解決するのに役立つ規則やデザインスタイルが存在します。私は1つを選ぶだけでは足りないものがあるはずだと思いますか？ たぶん両方のクラスに入れるのが正しい答えでしょうか？

11 design  design-patterns  coding-style  single-responsibility 

バックグラウンド 私はゲーム開発を趣味として行っており、それらを設計するより良い方法を探しています。現在、私は標準のOOPアプローチを使用しています（8年間エンタープライズ開発を行ってきたので、最終的には実現しています）。たとえば、「バディ」 public class Baddie:AnimatedSprite //(or StaticSprite if needed, which inherit Sprite) { //sprite base will have things like what texture to use, //what the current position is, the base Update/Draw/GetInput methods, etc.. //an AnimatedSprite contains helpers to animated the player while //a StaticSprite is just one that will draw …

11 design-patterns  game-development 

これらの線に沿ってすでにかなり役立つ質問があります（「非OOPデザインパターン？」）が、動的で型付けの弱い言語を始めたばかりの人の移行の観点について、私はもっと興味があります。 つまり、C ++、C＃、またはJavaで長年プログラミングしており、GoFデザインパターン、エンタープライズアプリケーションアーキテクチャのファウラーパターン、SOLID原則などに沿って多くの知恵を吸収したとしましょう。 m Ruby、Python、JavaScriptなどに手を出し、自分の知識がどのように適用されるのか疑問に思う。おそらく私は多くの場合に直接翻訳を行うことができますが、ほとんど確実にそれは私の新しい設定を十分に活用していないでしょう。アヒルのタイピングだけでも、私のインターフェースベースの考え方の多くが頭に浮かびます。 何が変わりませんか？何が変わりますか？動的言語初心者が知っておくべき、SOLIDや標準パターン（おそらくまったく新しいパターン）などの基本原則はありますか？

11 design-patterns  object-oriented  dynamic-typing  solid  weak-typing