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

設計パターンは、ソフトウェア設計で一般的に発生する問題に対する一般的な再利用可能なソリューションです。

8
リレーショナルデータベースでシングルトンをモデル化する最良の方法
Webアプリケーション用のリレーショナルデータベーススキーマを設計するとき、1つの行と1つの行のみを含むテーブルを作成する場合がよくあります。それはそれを設計する間違った方法のように感じますが、私は大幅に良いものを思い付くことができません、またはそれは明らかに「それを行うための正しい方法」です。 最近の例は、ユーザーがホームページのコンテンツを手動で制御できるサイトです。さて、ホームページは1つしかありません。説明テキストを含む領域のテキストフィールドなど、ホームページを作成するために必要なすべてのフィールドを持つテーブルを作成しました。大きな画像ファイルの名前を保存するフィールド。ホームページなどで紹介される記事を指すいくつかの外部キー。それは機能しますが、1行だけのテーブルがあるのは間違っているように感じます。 過去に、ホームページのテーブルで複数の行を許可したり、ランダムに1つの行を選択するなど、他の多くのデザインを試しました。「active」という名前のブールフィールドを追加して、アクティブなホームページの1つをランダムに選択しようとしました。アプリケーションロジックで、常に1行のみをアクティブにしようとしました。ホームページテーブルを作成せず、記事などの他のすべてのアイテムにfeatured_on_homepageのような名前のブールフィールドを持たせることさえしませんでした。 ほとんどの場合、設定ファイルに一連の定数を含むホームページを作成できます。設定ファイルの主な問題は、開発者が制御できることです。ホームページの内容のようなものはユーザーが編集するものなので、データベースに入れなければなりません。 多くのサイトでは、5つの最新記事を選択するなどのクエリを使用してホームページのようなものを作成できるため、この問題はありません。しかし、厳密な要件で手動でキュレーションされたページがある場合、データベースでモデル化するのは難しいです。しかし、写真の表と記事の表があるとします。要件は、ホームページにユーザーが手動で制御する写真を正確に5つ、記事を3つ、任意のテキストのブロックを2つ表示することです。データベースでそれを正しい方法でどのようにモデル化しますか? また、ホームページだけでなく、他の多くのケースでもこのモデリングの問題があります。これは、私が思いつく最も簡単で最も一般的に適用可能な例です。

4
並列階層-部分的に同じ、部分的に異なる
似たような質問がたくさんあります 1、2、3、4、ただし、この質問ではnonは当てはまらないようであり、解は最適とは思われません。 これは一般的なOOPの質問であり、多態性、ジェネリック、およびミックスインが利用可能であると仮定しています。実際に使用される言語はOOP Javascript(Typescript)ですが、JavaまたはC ++でも同じ問題です。 並列クラス階層があり、同じ動作(インターフェイスと実装)を共有することもありますが、それぞれに独自の「保護された」動作があります。次のように説明します。 これは、説明のみを目的としています。実際のクラス図ではありません。それを読むには: 共通階層(中心)のすべては、Canvas(左)階層とSVG(右)階層の両方で共有されます。シェアとは、インターフェースと実装の両方を意味します。 左または右の列にのみあるものは、その階層に固有の動作(メソッドとメンバー)を意味します。例えば: 左右の階層は、まったく同じ検証メカニズムを使用しViewee.validate()ます。これは、共通の階層で単一のメソッド()として示されています。 キャンバス階層のみにメソッドがありpaint()ます。このメソッドは、すべての子に対してpaintメソッドを呼び出します。 SVG階層はのaddChild()メソッドをオーバーライドする必要がありますCompositeが、キャンバス階層の場合はそうではありません。 両側の階層の構造を混在させることはできません。工場はそれを保証します。 解決策I-継承を離れる Fowler's Tease Apart Inheritanceは、2つの類似点の間に矛盾があるため、ここでは役に立たないようです。 解決策II-ミックスイン これは私が現在考えることができる唯一のものです。2つの階層は別々に開発されますが、各レベルでクラスはクラス階層の一部ではない共通クラスに混在します。structuralフォークを省略すると、次のようになります。 各列は独自の名前空間にあるため、クラス名は競合しません。 質問 誰でもこのアプローチで障害を見ることができますか?誰もがより良い解決策を考えることができますか? 補遺 これがどのように使用されるかを示すサンプルコードを次に示します。名前空間svgは次のように置き換えられますcanvas: var iView = document.getElementById( 'view' ), iKandinsky = new svg.Kandinsky(), iEpigone = new svg.Epigone(), iTonyBlair = new svg.TonyBlair( iView, iKandinsky ), iLayer = new svg.Layer(), …

3
グローバルリクエストコンテキスト-アンチパターン?
今日、私の同僚とPython Webフレームワークとそれらについての印象について話していました。私は、Flaskがグローバルなリクエストを持っているのはひどく臭いで、アンチパターンだと彼に言った。 ドキュメントは、要求コンテキストについて言います: 対照的に、リクエストの処理中には、他にもいくつかのルールがあります。 要求がアクティブな間、コンテキストローカルオブジェクト(flask.requestなど)は現在の要求を指します。 コードはいつでもこれらのオブジェクトを保持できます。 アプリケーションをよりシンプルにするという、この設計決定の背後にある考え方を理解していると思います。Thread Localsの場合のように、これは単なる妥協です。 はい、通常、スレッドローカルを使用することはそれほど賢明な考えではありません。これらは、スレッドの概念に基づいていないサーバーに問題を引き起こし、大規模なアプリケーションの保守を困難にします。ただし、Flaskは大規模なアプリケーションや非同期サーバー向けに設計されたものではありません。Flaskは、従来のWebアプリケーションをすばやく簡単に記述できるようにしたいと考えています。 グローバルオブジェクトに現在の要求情報をパッチすることはアンチパターンですか? 静的コードアナライザーの観点ではグローバルステートであるため、そうではないと考えています。そして、プログラマーとしての私は、ドキュメントを注意深く読むことなく、それがどのように機能するかを理解しません。そして、これはテストに結果をもたらします。 ビューへの引数としてリクエストを渡すことは良い習慣ではありませんか?読みやすく、明示的で、デバッグが簡単だと思います。そして、グローバルな状態を回避します。

1
大きなオブジェクト階層での訪問者パターンの使用
環境 オブジェクトの階層(式ツリー)で「疑似」ビジターパターン(二重ディスパッチを使用しないように疑似)を使用しています。 public interface MyInterface { void Accept(SomeClass operationClass); } public class MyImpl : MyInterface { public void Accept(SomeClass operationClass) { operationClass.DoSomething(); operationClass.DoSomethingElse(); // ... and so on ... } } ただし、MyInterfaceの実装の数は非常に多く(〜50以上)、余分な操作を追加する必要がないため、この設計は疑わしく、かなり快適でした。 各実装は一意であり(異なる式または演算子です)、一部は複合(つまり、他の演算子/リーフノードを含む演算子ノード)です。 トラバーサルは現在、ツリーのルートノードでAccept操作を呼び出すことによって実行され、その操作は、その子ノードのそれぞれでAcceptを呼び出します。 しかし、きれいな印刷などの新しい操作を追加する必要があるときが来ました。 public class MyImpl : MyInterface { // Property does not come from MyInterface public string …

3
OOPのクラス設計にどのように取り組みますか?
オブジェクト指向ソリューションを設計しようとすると、通常、CRCモデリングを使用して、クラス名(名詞)、それらが行うこと(動詞)、および他のクラスとのコラボレーション方法をリストします。 このブログには、この名詞動詞のアプローチについて以下のことを述べています ...This approach, which I will call “noun and verb,” is so limited I’ll dare to call it brain damaged.... 私の質問は、オブジェクト指向アプローチを使用するためのより良いモデリング手法が存在するかどうかです。

4
MVCおよびRESTful APIサービス
MVCは非常に単純です。モデル、コントローラー、ビューがあります。Webサイトを作成すると、クライアントがRESTキーワード要求をサーバーに送信するときにすべてがまとめられます->サーバーは要求されたURLをコントローラーアクションに一致させます->データ収集/処理のためにモデルを呼び出し、結果を取得します->そして、結果をHTMLページ(ビュー)としてクライアントに返します。 純粋なRESTful API Webサービスについて話している場合はどうなりますか?次に、クライアントはRESTキーワード要求をサーバーに送信します->サーバーは要求されたURLをコントローラーアクションに照合します->データ収集/処理のためにモデルを呼び出し、結果を取得して->戻ります結果をJSONでクライアントに返します。以前と同じですが、「ビュー」はありません...むしろ、生成されたJSONは「ビュー」と考えることができます。ある意味では、MVCのMC部分のみを使用しています。それはどのように行われるべきですか?または、MVCの代わりにAPIのみのサービスに適した他のパターンはありますか?

2
エンティティーコンポーネントシステムは、デカップリング/情報隠蔽のためにひどいものではありませんか?
タイトルは意図的に双曲線であり、それは単にパターンに不慣れなだけかもしれませんが、ここに私の推論があります: エンティティを実装する「通常の」またはほぼ間違いなく簡単な方法は、それらをオブジェクトとして実装し、共通の動作をサブクラス化することです。古典的な問題へのこのリードは、「あるEvilTreeのサブクラスTreeかEnemy?」。多重継承を許可すると、ダイヤモンドの問題が発生します。私たちは、代わりの複合機能を引く可能性TreeとEnemy、さらにその神クラスへのリード線の階層までを、あるいは我々は意図的に私たちの中での行動を残すことができますTreeし、Entityそのことをクラス(彼らは極端なケースではインターフェースを作る)EvilTree自体ことを実装することができます-どのリードにコードの重複がある場合SomewhatEvilTree。 Entity-Component Systemsは、TreeおよびEnemyオブジェクトを異なるコンポーネント(たとえばPosition、Healthおよび)に分割してこの問題を解決し、AIの決定に従ってEntitiyの位置を変更するAIシステムなどを実装しようとしますAISystem。これまでのところは良いですがEvilTree、パワーアップを獲得してダメージを与えることができたらどうでしょうか?まず、a CollisionSystemとa が必要ですDamageSystem(おそらくこれらはすでにあるでしょう)。CollisionSystem通信するために必要なDamageSystem二つのものが衝突するたび:CollisionSystemにメッセージを送信しDamageSystem、それが健康を引くことができるようにします。ダメージもパワーアップの影響を受けるため、どこかに保存する必要があります。PowerupComponentエンティティにアタッチする新しいものを作成しますか?しかし、その後DamageSystemむしろ何も知らない何かについて知る必要があります-結局のところ、パワーアップを拾えないダメージを与えるものもあります(aなどSpike)。この回答と同様のダメージ計算にも使用されるPowerupSystemを修正するStatComponentことはできますか?しかし、現在では2つのシステムが同じデータにアクセスしています。ゲームがより複雑になると、多くのシステム間でコンポーネントが共有される無形の依存関係グラフになります。その時点で、グローバルな静的変数を使用して、すべての定型文を取り除くことができます。 これを解決する効果的な方法はありますか?私が持っていた1つのアイデアは、コンポーネントに特定の機能を持たせることでした。たとえばStatComponent attack()、デフォルトでは整数を返すだけですが、パワーアップが発生したときに構成できます: attack = getAttack compose powerupBy(20) compose powerdownBy(40) これはattack、複数のシステムがアクセスするコンポーネントに保存しなければならない問題を解決しませんが、少なくともそれを十分にサポートする言語があれば、関数を適切に入力できます。 // In StatComponent type Strength = PrePowerup | PostPowerup type Damage = Int type PrePowerup = Int type PostPowerup = Int attack: Strength = getAttack //default value, can be changed by systems getAttack: PrePowerup …

5
メモリ管理言語の参照カウントパターン?
Javaと.NETには、メモリを管理するすばらしいガベージコレクターと、外部オブジェクト(Closeable、IDisposable)を迅速に解放する便利なパターンがありますが、それらは単一のオブジェクトによって所有されている場合のみです。一部のシステムでは、リソースは2つのコンポーネントによって個別に消費される必要があり、両方のコンポーネントがリソースを解放するときにのみ解放される場合があります。 最新のC ++ではshared_ptr、を使用してこの問題を解決しますshared_ptr。すべてのが破棄されると、リソースが確定的に解放されます。 オブジェクト指向の非決定論的にガベージコレクションされたシステムに単一の所有者がいない高価なリソースを管理およびリリースするための文書化された実証済みのパターンはありますか?

3
例外や冗長性なしに入力検証を実行する方法
特定のプログラム用のインターフェイスを作成しようとすると、通常、検証されていない入力に依存する例外をスローしないようにします。 よくあることは、次のようなコードを考えたことです(これは単なる例であり、実行する機能は気にしないでください(Javaの例))。 public static String padToEvenOriginal(int evenSize, String string) { if (evenSize % 2 == 1) { throw new IllegalArgumentException("evenSize argument is not even"); } if (string.length() >= evenSize) { return string; } StringBuilder sb = new StringBuilder(evenSize); sb.append(string); for (int i = string.length(); i < evenSize; i++) { sb.append(' …

2
トランザクションを使用したビジネスロジックとDBロジックの分離
アプリケーションには3つのレイヤーがあります。外部APIを提供するサービスレイヤー。ビジネスロジック用のBOレイヤー、およびデータベース接続用のDAOレイヤー。 ファイルを更新するたびに、フォルダ内の何か、たとえば「最終変更日」も変更したいとします。これは、トランザクションで実行する必要があります。成功し、ファイルとフォルダーの両方が編集されます。または、障害が発生し、トランザクションがロールバックされるため、両方のオブジェクトが以前の状態になります。 「ファイルが編集されたときにフォルダーを編集する」アクションは、純粋にビジネスロジックです。したがって、これはBOレイヤーに属していることを意味します。ただし、データベースにはObjectifyを使用しているため、トランザクションを開始するにはofy()。transact(...)を呼び出す必要があります。BOレイヤーでこの関数を呼び出すと、ビジネスレイヤーでデータベース固有の呼び出し(Objectify)が発生するため、デザインが破損します。 この問題のクリーンなソリューションは何でしょうか?

7
オブジェクト指向のオブジェクト指向言語での実装?
カーレースをシミュレートするJavaコードをいくつか見てきました。これには基本的なステートマシンの実装が含まれています。これは、古典的なコンピューターサイエンスステートマシンではなく、複数の状態を持つことができ、一連の計算に基づいて状態を切り替えることができるオブジェクトにすぎません。 問題だけを説明するために、Carの状態の定数(OFF、IDLE、DRIVE、REVERSEなど)を定義するネストされたenumクラスを持つCarクラスを取得しました。この同じCarクラス内には、更新機能があります。これは基本的に、現在の車の状態を切り替え、計算を行い、車の状態を変更する大きなswitchステートメントで構成されています。 私が見る限り、Cars状態は独自のクラス内でのみ使用されます。 私の質問は、これが上記の性質のステートマシンの実装を処理する最良の方法ですか?それは最も明白な解決策のように聞こえますが、過去には「switchステートメントが悪い」といつも聞いていました。 ここで見られる主な問題は、状態を追加すると(必要に応じて)switchステートメントが非常に大きくなり、コードが扱いにくくなり、保守が難しくなる可能性があることです。 この問題のより良い解決策は何ですか?

2
優れた実践における乾燥の原則?
私は、できる限り一生懸命プログラミングのDRY原則に従うようにしています。最近、私はOOPでデザインパターンを学んでいますが、結局、かなりの量を繰り返しています。 永続性を処理するために、FactoryパターンとGatewayパターンとともにRepositoryパターンを作成しました。私はアプリケーションでデータベースを使用していますが、ゲートウェイを交換して、必要に応じて別の種類の永続性に切り替えることができるはずなので、それは問題ではありません。 最終的に自分で作成した問題は、所有しているテーブルの数に対して同じオブジェクトを作成することです。たとえば、これらはテーブルを処理する必要があるオブジェクトになりますcomments。 class Comment extends Model { protected $id; protected $author; protected $text; protected $date; } class CommentFactory implements iFactory { public function createFrom(array $data) { return new Comment($data); } } class CommentGateway implements iGateway { protected $db; public function __construct(\Database $db) { $this->db = $db; } public function …

5
突然変異法のための独立したインターフェース
私はいくつかのコードのリファクタリングに取り組んできましたが、ウサギの穴を降りる最初の一歩を踏み出したのではないかと思います。私はJavaで例を書いていますが、それは不可知論的であると思われます。 次のようにFoo定義されたインターフェイスがあります public interface Foo { int getX(); int getY(); int getZ(); } そして、実装として public final class DefaultFoo implements Foo { public DefaultFoo(int x, int y, int z) { this.x = x; this.y = y; this.z = z; } public int getX() { return x; } public int getY() { …

2
パブリッシュ/サブスクライブパターンは、gotoとどのように異なりますか?
私の理解では、後藤声明は一般的に眉をひそめているということです。しかし、パブリッシュ/サブスクライブパターンは、コードの一部がメッセージをパブリッシュすると、一方向の制御の転送を実行するという点で概念的に類似しているようです。プログラマは、プログラムのどの部分がこのメッセージにサブスクライブしているかわからない場合があります。 イベントを使用してモジュール間を便利に「ホップ」するJavaScriptプログラムの多くで、似たようなものを見てきました。パブリッシュ/サブスクライブまたはイベント駆動型のパターンについて何かが欠けていますか?

1
MVC + 3層; ViewModelsが登場する場所
ASP.NET MVC 4を使用して3層アプリケーションを設計しています。次のリソースを参照として使用しました。 CodeProject:MVC + N層+エンティティフレームワーク ASP.NET MVCでのデータアクセスの分離 これまでに次のようなデザインがあります。 プレゼンテーション層(PL) (メインMVCプロジェクト、MのMVCは、データアクセス層に移動されました): MyProjectName.Main Views/ Controllers/ ... ビジネスロジックレイヤー(BLL): MyProjectName.BLL ViewModels/ ProjectServices/ ... データアクセス層(DAL): MyProjectName.DAL Models/ Repositories.EF/ Repositories.Dapper/ ... 現在、PLはBLLを参照し、BLLはDALを参照しています。このように、下層は上の層に依存しません。 この設計では、PLはBLLのサービスを呼び出します。PLはビューモデルをBLLに渡すことができ、BLLはビューモデルをPLに戻すことができます。 また、BLLはDALレイヤーを呼び出し、DALレイヤーはモデルをBLLに戻すことができます。BLLは、ビューモデルを作成してPLに返すことができます。 今まで、このパターンは私のために働いていました。ただし、ViewModelsのいくつかがいくつかのエンティティで結合する必要があるという問題に遭遇しました。プレーンMVCアプローチでは、コントローラーでjoinsを実行してからを実行するためにLINQクエリを使用しましたselect new MyViewModel(){ ... }。しかし今、DALでは、ViewModelが定義されている場所(BLL内)にアクセスできません。 これは、DALで参加してBLLに戻すことができないことを意味します。(1つのクエリでの結合の代わりに)DALで個別のクエリを実行する必要があり、BLLはこれらの結果を使用してViewModelを構築します。これは非常に不便ですが、DALをViewModelに公開する必要はないと思います。 このジレンマを解決する方法はありますか?ありがとう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.