問題タブ [solid-principles]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
asp.net-mvc-3 - DbContextのインスタンスを1つだけ使用しながら、さまざまな責任を処理する方法
私は自分の質問に対する答えを探していましたが、それを見つけることができませんでした。主な理由は、それを表現する方法が本当にわからないためです。
私は最初にEFコードで遊んでいて、依存性注入を使用しながら、ある種のリポジトリパターンを実装しようとしています(Unityのおかげで)。私はまた、基本的なメソッドを提供するインターフェースを持っIStaffRepository
ているという点で、SOLID(少なくともSRPの部分)を維持しようとしています。IDepartmentRepository
IRepository<TEntity>
CRUD
私の質問は、スタッフの部門を更新する必要がある場合、どうすればSRPを維持できますか?
DbContext
メモリリークの可能性があるため、すべてのリポジトリに単一のインスタンスを使用することは悪い習慣であると読みました。そのため、を呼び出しIDepartmentRepository
て新しい部門を取得することはできません。これは、の別のインスタンスを使用するためDbContext
です。
私にとって明らかな解決策は、次のようなものを含めることです...
内IStaffRepository
-しかし、これはSRPを壊しませんか?
私のコントローラーにあるコードは...
そしてStaffMember
モデルには...
そして、StaffViewModel
このように見えます...
データベースにはint Department_ID
、Departmentテーブルに接続するフィールドがあります。
ビューにドロップダウンがあります...
この質問の長さについてお詫びします!
c# - シンプルで効率的なバリュータイプを作るためのパターン
動機:
Code Smell: Automatic Propertyに関する Mark Seemann のブログを読んで、彼は最後の方で次のように述べています。
肝心なのは、自動プロパティが適切であることはめったにないということです。実際、プロパティの型が値型であり、考えられるすべての値が許可されている場合にのみ適切です。
彼はint Temperature
悪臭の例を挙げ、摂氏のような単位固有の値のタイプが最善の解決策であることを示唆しています。そこで、よりSOLIDになるための演習として、すべての境界チェックと型変換ロジックをカプセル化するカスタム摂氏値型を作成してみることにしました。
基本要件:
- 無効な値を持つことはできません
- 変換操作をカプセル化します
- 効率的な対処 (int を置き換えることと同等)
- 可能な限り直観的に使用する (int のセマンティクスを試す)
実装:
テスト:
質問:
- 読み取り専用の代わりに MinValue/MaxValue を const にする方法はありますか? BCL を見ると、 intのメタデータ定義でMaxValue と MinValue がコンパイル時の定数として明確に示されているのが気に入っています。どうすればそれを模倣できますか?コンストラクターを呼び出すか、摂氏が int に格納する実装の詳細を公開せずに摂氏オブジェクトを作成する方法がわかりません。
- ユーザビリティ機能が不足していませんか?
- カスタム単一フィールド値タイプを作成するためのより良いパターンはありますか?
design-patterns - インターフェイス分離の原則は、単一責任の原則の代わりにすぎませんか?
インターフェイス分離の原則は、単一責任の原則の代わりにすぎませんか?
クラスが SRP を満たす場合、複数のインターフェイスを抽出する必要はないと思います。
したがって、ISP は、何らかの理由で SRP を壊さなければならない場合の解決策のように見えます。
私は正しいですか?
ruby - SOLID の原則とデザイン パターンを念頭に置いてアプリケーションを設計する方法
起動時に ruby のアプリケーションには、コマンドライン モードとファイルモードの 2 つのモードがあるとします。
パラメータruby myprogram input.txt output.txtを指定すると、入力ファイル内のいくつかのコマンドに基づいて出力が生成されます。また、パラメーターが指定されていない場合は、コマンド プロンプトが表示されます。次のコマンドで。
RSpec、TDD、Cucumber、SOLID、およびパターンを念頭に置いて、そのようなアプリケーションを設計する方法。私が直接尋ねているのは、該当する場合はモジュールであるべきものを設計するために、ここでオブジェクトであるべきものは何ですか..? そして、ここでテストする必要があるものとそうでないものをどのように判断するのですか? オブジェクト指向設計の観点から最も適切なメカニズムを設計します。
また、この種のオブジェクト指向設計の原則と ruby の実践については、本やブログを参照してください。
oop - 「オープン/クローズの原則」と「依存性逆転の原則」の違いは何ですか?
SOLID に関する記事を読みましたが、OCP と DIP の違いはわかりません。この OCP の例を見てください。
OCP を保持するコードは、DIP も満たします。DIPではなくOCPを保持するコードの例を誰か教えてもらえますか?
oop - インターフェイス分離の原則が適用されないのはいつですか? SOA?
インターフェイス分離原則 (SOLID から) を使用しないシナリオの例を探しています。
私が言及した (しかし説明されていない) 唯一のものは、SOA のコンテキストにおけるサービスのインターフェースの場合です。しかし、なぜ?この場合、インターフェースが設計上太っていることになっているからでしょうか? SOAの法令によって?
ISP が適切でない他の状況はありますか?
前もって感謝します。
design-patterns - 要件がこのように進化する場合、どのように責任を分離するのでしょうか?
最初に私の要件は
「アカウントを作成してお金を入れることができます。アイテムを購入すると、アカウントが減少します」
だから私の AccountController は次のようになりました
しかし、その後、「一部の人は無料アカウントを持つことができます(すべてのアイテムが無料になります)が、実際のアカウントを作成すると無料アカウントを削除します」という新しい要件があります。
だから私のcontroller.Createはなりました
しかし、私にとっては、これを別の場所に配置する必要があるように感じますが、データの保存を処理することを想定してRemoveFreeAccount
いるため、どこにあるのかわかりません。IAccountDataSource
oop - リスコフの置換原則を適用できますか(phpの例)?
「サブタイプは、基本タイプの代わりに使用できる必要があります」
私がすでにBirdクラスを持っているとしましょう、そして:
鳥は話すことができないので、オウムを鳥に置き換えることはできません。
これは単なる基本的な例ですが、通常、拡張クラスは基本クラスよりもはるかに多くのことを実行できます。私は何が欠けていますか?
objective-c - C#/Javaの世界から来たときのiOSデザインパターンの同等物?
だから、私は iOS 開発は初めてで、物事を行うための「最善の」方法を学ぶためにできる限りのことをしています。(はい、私はそれが相対的な用語であることを知っています)
私は、IOC コンテナーを介して依存関係を注入する、リポジトリ パターンを使用してデータ アクセスを抽象化する、ドメイン サービスとオブジェクトを使用してビジネス データと動作をカプセル化するなどのことを行う C# と Java の世界から来ました。 iOS開発ではまだ見ていません。(もしかしたら探しているところが悪いのかもしれません)
Objective-C は C のスーパーセットであり、動的/緩く型付けされた言語であり、優れた設計プラクティスに関しては、おそらくゲームをかなり変えるでしょう。デザインをしなやかに保ち、SOLID の原則を順守しながら、強く型付けされ管理された環境からこの新しい世界へと精神的に飛躍するのに役立つ本/ブログ/その他の方向性を教えてくれる人はいますか?
編集 - ここで明確にしたい。 Cocoa フレームワークや、言語としての Objective-C の内外を学ぶ方法を尋ねているのではありません。私はそれについてたくさんのリソースを見つけました。私はこれを次のレベルに引き上げ、TDD を開始し、構築中のプロジェクトの拡張と保守が容易であることを確認したいと考えています。
oop - インターフェイス分離の原則 - インターフェイスへのプログラム
SOLID やその他の設計原則について読んでいました。ISPは「実装ではなく、インターフェースへのプログラム」と同じだと思いました。しかし、これらは異なる原則のように見えますか?
違いはありますか?