タグ付けされた質問 「solid」

持つCircle拡張Ellipse休憩にリスコフSubstition原理、すなわち、あなたはXとYが独立して楕円を描くように設定することができますが、Xは、常に円のためにYに等しくなければなりません：それは事後条件を変更するため、。 しかし、ここでの問題は、Circleを楕円のサブタイプにすることによって引き起こされたのではないでしょうか？関係を逆転させることはできませんか？ ですから、Circleはスーパータイプです-メソッドは1つだけですsetRadius。 次に、setXとを追加して、楕円が円を拡張しsetYます。setRadiusEllipseを呼び出すと、XとYの両方が設定されます。つまり、setRadiusの事後条件は維持されますが、拡張インターフェースを使用してXとYを個別に設定できるようになりました。

13 object-oriented  solid  liskov-substitution 

例 データベースからデータをロードし、HTMLマークアップを表示し、ルーター/コントローラー/アクションとして機能する「すべて」を行うモノリシックコードに出会いました。データベースコードを独自のファイルに移動するSRPを適用し始め、物事の命名を改善しましたが、すべてが見栄えが良かったのですが、なぜこれを行っているのか疑問に思い始めました。 リファクタリングする理由 目的は何ですか？役に立たない？利点は何ですか？モノリシックファイルはほとんどそのままにしておきましたが、作業を行う必要がある領域に関連する小さな部分のみをリファクタリングしたことに注意してください。 元のコード： 具体的な例を挙げると、このコードスニペットに出会いました。既知の製品IDまたはユーザーが選択したバージョンIDのいずれかで製品仕様を読み込みます。 if ($verid) $sql1 = "SELECT * FROM product_spec WHERE id = " . clean_input($verid); else $sql1 = "SELECT * FROM product_spec WHERE product_id = " . clean_input($productid) ; $result1 = query($sql1); $row1 = fetch_array($result1); /* html markup follows */ リファクタリング： この特定のコード部分を変更する必要がある作業を行っているため、リポジトリパターンを使用するように変更し、オブジェクト指向のMySQL機能を使用するようにアップグレードしました。 //some implementation details …

12 php  refactoring  solid  single-responsibility 

Open Closed Principle（OCP）とDependency Inversion Princible（DIP）の違いを理解しようとしていました。 これまでにインターネットで行った調査に基づいて、「DIPはOCPを達成するための1つのオプション」という結論に達しました。 これでいいの？ DIPではなくOCPに従っている例を教えてください。

12 design-patterns  object-oriented  object-oriented-design  solid 

ウィキペディアによると 「ソフトウェアエンティティ（クラス、モジュール、関数など）は拡張のために開かれている必要がありますが、変更のために閉じられている必要があります」 関数という言葉が目を引きましたが、メソッドのオーバーロードを作成することは、オープン/クローズの原則の一例とみなすことができると思いますか？ 例を説明しましょう。サービスレイヤーにメソッドがあり、ほぼ1000か所で使用されていることを考慮してください。メソッドはuserIdを取得し、ユーザーが管理者であるかどうかを判断します。 bool IsAdmin(userId) ここで、userIdではなくユーザー名に基づいて、ユーザーが管理者であるかどうかを判断する必要があると考えてください。上記のメソッドのシグネチャを変更すると、1000箇所でコードが破損します（関数は修正のために閉じる必要があります）。したがって、ユーザー名を取得するオーバーロードを作成し、ユーザー名に基づいてuserIdを見つけ、元のメソッドを見つけることができます。 public bool IsAdmin(string username) { int userId = UserManager.GetUser(username).Id; return IsAdmin(userId); } このように、オーバーロードを作成して機能を拡張しました（機能は拡張に対して開かれている必要があります）。 それはオープン/クローズド原則の例ですか？

12 solid  design-patterns  open-close 

次のインターフェースがあるとしましょう- interface IDatabase { string ConnectionString{get;set;} void ExecuteNoQuery(string sql); void ExecuteNoQuery(string[] sql); //Various other methods all requiring ConnectionString to be set } 前提条件は、いずれかのメソッドを実行する前にConnectionStringを設定/初期化する必要があることです。 IDatabaseが抽象クラスまたは具象クラスである場合、コンストラクターを介してconnectionStringを渡すことにより、この前提条件をある程度達成できます。 abstract class Database { public string ConnectionString{get;set;} public Database(string connectionString){ ConnectionString = connectionString;} public void ExecuteNoQuery(string sql); public void ExecuteNoQuery(string[] sql); //Various other methods all requiring …

11 c#  solid  liskov-substitution 

私がよく遭遇する問題は次のとおりです。Productクラスを持つWebショッププロジェクトがあるとします。ユーザーが製品にレビューを投稿できる機能を追加したい。そのため、製品を参照するレビュークラスがあります。次に、製品に対するすべてのレビューをリストする方法が必要です。2つの可能性があります。 （A） public class Product { ... public Collection<Review> getReviews() {...} } （B） public class Review { ... static public Collection<Review> forProduct( Product product ) {...} } コードを見て、（A）を選択します：静的ではなく、パラメーターを必要としません。ただし、（A）は単一責任原則（SRP）およびオープンクローズド原則（OCP）に違反しているのに対し、（B）はそうではないと感じています。 （SRP）製品のレビューの収集方法を変更する場合、製品クラスを変更する必要があります。ただし、Productクラスを変更する理由は1つだけです。そして、それは確かにレビューではありません。Productの製品と関係のあるすべての機能をパックすると、すぐに散らかってしまいます。 （OCP）Productクラスを変更して、この機能で拡張する必要があります。これは原則の「変更のために閉鎖」部分に違反すると思います。レビューを実施するという顧客の要求を得る前に、私は製品が完成したと考え、それを「クローズ」しました。 より重要なことは、SOLID原則に従うか、よりシンプルなインターフェイスを使用するかです。 それとも私はここで何か間違ったことをしていますか？ 結果 素晴らしい答えをありがとう 公式の回答として選ぶのは難しいです。 答えから主な議論を要約しましょう： pro（A）：OCPは法律ではなく、コードの可読性も重要です。 pro（A）：エンティティの関係はナビゲート可能でなければなりません。両方のクラスがこの関係について知っている場合があります。 pro（A）+（B）：両方を行い、（A）から（B）に委任するため、製品が再び変更される可能性は低くなります。 pro（C）：finderメソッドを静的でない第3クラス（サービス）に配置します。 コントラ（B）：テストのモックを妨げます。 私の職場の大学が貢献したいくつかの追加事項： pro（B）：ORMフレームワークは（B）のコードを自動的に生成できます。 pro（A）：ORMフレームワークの技術的な理由により、ファインダーの行き先とは無関係に、「閉じた」エンティティを変更する必要がある場合があります。とにかく、私は常に固執することができるとは限りません。 コントラ（C）：大騒ぎする;-) 結論 現在のプロジェクトでは、委任で（A）+（B）の両方を使用しています。ただし、サービス指向の環境では、（C）を使用します。

11 object-oriented-design  solid 

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

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

インターフェース分離の原則は、クライアントが使用しないメソッドに依存することを強制されるべきではないことを示唆しているので、クライアントはそのインターフェースメソッドに空のメソッドを実装すべきではありません。 しかし、具体的な方法はどうですか？すべてのクライアントが使用するわけではない方法を分離する必要がありますか？次のクラスを考えてみましょう： public class Car{ .... public boolean isQualityPass(){ ... } public int getTax(){ ... } public int getCost(){ ... } } public class CarShop{ ... public int getCarPrice(int carId){ Car car=carList[carId]; int price=car.getTax() + car.getCost()... (some formula); return price; } } 上記のコードでは、CarShopはisQualityPass（）を新しいクラスに分離する必要がある場合、CarでisQualityPass（）メソッドをまったく使用しません。 public class CheckCarQualityPass{ public boolean isQualityPass(Car car){ …

10 object-oriented  solid 

他のすべての開発者が基本的なCRUDアプリを実行することに慣れているか、かわいらしい/機能的なインターフェイスを作成することに専念している基幹業務アプリを実行しており、次のことをたくさん得ています。 「私たちがそれを行うために使用する方法で、従業員はあなたが従業員に対しておそらくできるすべてのことをするでしょう。」そしてそれは本当でした。その1つの「クラス」には数千行のコードがあり、従業員に対して実行できることは何でもありました。または、さらに悪いことに、従業員データのテーブルがあり、各開発者がイベントハンドラーで実行したいことを実行する方法を見つけました。 そのアプローチのすべての悪い点は真実でしたが、少なくとも従業員を使用する開発者は、他のドキュメントに行かなくても、従業員をヘルスプランに登録し、昇給、解雇、雇用、異動などを行う方法を見つけることができました。マネージャーと他のすべての主要なアイデア。または、従業員が他の必要なデータテーブルを使用している場合は、必要なことを実行できます。 はい、多くの重複したコードがありました。はい、それは非常に壊れやすいコードでした。はい、テストは必要以上に困難でした。はい、機能の変更は恐怖を誘発するものであり、コピーペーストはそのアプローチにより当然のことでした。 しかし、少なくとも1つのクラスを作成することで何が利用可能であるかを発見したり、インターフェイス、抽象クラス、具象クラスなどの違いを理解しなくても、必要なことを実行したりできます。 intellisenseによって返されるメソッド、またはデータが存在するテーブルを知っているメソッド。 googled / bingedやyahoo！dも行っていますが、この問題の確認はありません。 だから問題はないかもしれないし、何か足りないだけなのかもしれない。実際の動作やデザインに対応していない開発者が、外部ドキュメントを参照したり、さまざまなコンポーネントのクラス名をスキャンしたりせずに、何かを行う方法を簡単に発見できるソリューションを理解しようと頭を悩ませました/それが動作するように聞こえるものを見つけるためのプロジェクト。 私が思いつくことができた唯一のものは、より良い名前がないために、これらを持っていることです、「Table of Content Class」は実際のクラスを返すだけで何もしません（そして実際にそれらのほとんどはインターフェースですがそれらは他の開発者が希望する実際のタスクを実行するために使用できる違いまたは注意さえも知っています。まだ本当に大きなクラスになってしまいますが、それらにはほとんど振る舞いがありません。 SOLIDの実際の実装が行われる中間層の詳細な知識を必要としないより良い方法はありますか？ 基本的に私が求めているのは、CRUDタイプの開発者が非常に複雑なシステムのCRUD開発者であり続けることを可能にする方法があるかどうかです。

10 solid  crud 

私は最近、クリーンコードやSOLIDに関するさまざまなオンライン記事を読んでいますが、それについて読むほど、何も知らないように感じます。 ASP.NET MVC 3を使用してWebアプリケーションを構築しているUsersControllerとしましょう。たとえば、次のCreateようなアクションがあるとします。 public class UsersController : Controller { public ActionResult Create(CreateUserViewModel viewModel) { } } そのアクションメソッドでは、入力したデータが有効な場合、ユーザーをデータベースに保存します。 さて、単一の責任の原則に従って、オブジェクトは単一の責任を持つべきであり、その責任はクラスによって完全にカプセル化されるべきです。そのすべてのサービスは、その責任と厳密に一致している必要があります。検証とデータベースへの保存は2つの別々の責任であるため、次のようにそれらを処理するために別々のクラスを作成する必要があると思います。 public class UsersController : Controller { private ICreateUserValidator validator; private IUserService service; public UsersController(ICreateUserValidator validator, IUserService service) { this.validator = validator; this.service= service; } public ActionResult Create(CreateUserViewModel viewModel) { ValidationResult result …

10 object-oriented-design  solid  single-responsibility 

私は労働者の純年収を計算するクラスを持っています。税率を表す定数があります。しかし、ある日、税率が変更されたため、コードを修正する必要があります。 この定数を修正する行為は、クラスを変更して閉じる必要があると仮定しているため、Open-Closed Principleの違反を示していますか？

10 object-oriented  object-oriented-design  solid 

でブログ記事のこのシリーズ、エリックリッペルトは、ウィザードとの例として、戦士を使用して、オブジェクト指向設計における問題点を説明します。 abstract class Weapon { } sealed class Staff : Weapon { } sealed class Sword : Weapon { } abstract class Player { public Weapon Weapon { get; set; } } sealed class Wizard : Player { } sealed class Warrior : Player { } 次に、いくつかのルールを追加します。 戦士は剣しか使用できません。 ウィザードはスタッフのみを使用できます。 次に、C＃型システムを使用してこれらのルールを適用しようとすると発生する問題（たとえばWizard、ウィザードがスタッフのみを使用できることをクラスに責任を持たせるなど）を示します。Liskov置換原則に違反したり、ランタイム例外のリスクを冒したり、拡張が困難なコードを作成したりする。 …

9 c#  design-patterns  object-oriented  solid 

アジャイルソフトウェア開発、原則、パターン、およびプラクティス：ピアソン新国際版： 場合によっては、クライアントの異なるグループによって呼び出されるメソッドが重複することがあります。オーバーラップが小さい場合、グループのインターフェースは分離したままにする必要があります。共通の関数は、オーバーラップするすべてのインターフェースで宣言する必要があります。サーバークラスは、これらの各インターフェイスから共通の機能を継承しますが、実装するのは1回だけです。 ボブおじさんは、少しの重複がある場合について話します。 大きな重複がある場合はどうすればよいですか？ 私たちは持っていると言います Class UiInterface1; Class UiInterface2; Class UiInterface3; Class UiIterface : public UiInterface1, public UiInterface2, public UiInterface3{}; 間にかなりの重複がある場合、我々は何をすべきUiInterface1とはUiInterface2？

9 design  object-oriented  c++  interfaces  solid 

基本的に「必要なものだけを尋ねる」というインターフェースの設計と消費の原則を使用するようになりました。 たとえば、削除できるタイプがたくさんある場合は、Deletableインターフェイスを作成します。 interface Deletable { void delete(); } 次に、ジェネリッククラスを記述できます。 class Deleter<T extends Deletable> { void delete(T t) { t.delete(); } } コードの他の場所では、クライアントコードのニーズを満たすために可能な限り小さな責任を常に求めます。したがって、を削除するだけでよい場合Fileでも、Deletableではなくを要求しますFile。 この原則は常識であり、すでに受け入れられている名前ですか？物議を醸していますか？それは教科書で議論されていますか？

9 object-oriented  interfaces  solid  single-responsibility 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 6年前休業。 そのため、私は最近、GoogleとAmazonへのオンサイトインタビューを行い、自分が近いことを通知する丁寧な拒否通知を受け取りましたが、彼らが求めていたスキルにはあま​​り適していませんでした。 私はこれまでに行ったすべてのインタビューの最終ラウンドに行きました（ただし、練習のためにインタビューした小さな興味のないポジションからのオファーは除きます）、これまでのところ、1日あたり5〜8回のインタビューを行うことで、私のミスが足りないので、実行から外してください。 私は少なくともコーディングの質問と他の一般的な技術的な質問でうまくやったことを知っていますが、カードゲームや駐車場などのOOPの設計は得意ではないようです（1つのオブジェクトに深く入りすぎて、すべての時間を使い果たしました。より広い）と私のコーディングの回答は全体的に機能しますが、私が見逃したいくつかのバグ/エッジケースはありませんでした（入力ノードを実際に区別する必要がなく、回答である場合など）。そして、「わからない」と言っても問題はありませんが、多分ちょっと迷っていて、答えられると思う質問に答える必要があるかもしれませんが、明確な答えを出すことはできません... では、あなたが上手くなったからといって、それでも「雇う」には至らない理由は何ですか。 あなたが何を探しているのか、またはあなたにその少しの追加のブーストを与えたあなたが知っている何かについて何かアドバイスはありますか？

9 interview  solid