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

Javascriptはプロトタイプベースのオブジェクト指向言語ですが、次のいずれかの方法により、さまざまな方法でクラスベースになります。 自分でクラスとして使用する関数を書く フレームワークで気の利いたクラスシステムを使用する（mootools Class.Classなど） Coffeescriptから生成する 最初はJavascriptでクラスベースのコードを書く傾向があり、それに大きく依存していました。しかし最近、私はJavascriptフレームワークとNodeJSを使用していますが、これらはクラスの概念から離れ、次のようなコードの動的な性質により依存しています。 非同期プログラミング、コールバック/イベントを使用するコードの作成と使用 RequireJSを使用したモジュールのロード（グローバルネームスペースにリークしないようにするため） リスト内包表記（マップ、フィルターなど）などの関数型プログラミングの概念 とりわけ これまでに収集したことは、私が読んだほとんどのオブジェクト指向の原則とパターン（SOLIDやGoFパターンなど）は、SmalltalkやC ++のようなクラスベースのオブジェクト指向言語向けに書かれたものです。しかし、Javascriptなどのプロトタイプベースの言語に適用可能なものはありますか？ Javascriptに固有の原則やパターンはありますか？コールバックの地獄、悪の評価、またはその他のアンチパターンなどを避けるための原則

79 design-patterns  javascript  object-oriented  patterns-and-practices  design-principles 

私は、リスコフ代替原理の違反の可能性について、この非常に投票された質問に従っていました。Liskov Substitutionの原則が何であるかは知っていますが、開発者としてオブジェクト指向コードを書いている間にこの原則を考えないと、何が間違っているのかが私の心ではまだはっきりしていません。

27 object-oriented  object-oriented-design  solid  design-principles  liskov-substitution 

LSPは、クラスがその基本クラスの代わりになるべきであると述べています。つまり、派生クラスと基本クラスは意味的に同等でなければなりません。 しかし、LSPはインターフェイスを実装するクラスにも適用されますか？言い換えると、クラスによって実装されたインターフェイスメソッドが、ユーザーが期待するものと意味的に異なる場合、これはLSPの違反と見なされますか？

17 design-patterns  design-principles  liskov-substitution 

私はGRASPを学ぼうとしていますが、これは低結合について説明されています（ここ3ページにあります）。 クラスのメソッドaddTrackについて考えてみましょうAlbum。2つの可能なメソッドは次のとおりです。 addTrack( Track t ) そして addTrack( int no, String title, double duration ) どの方法で結合が減少しますか？Albumクラスを使用するクラスはTrackクラスを知る必要がないので、2番目のものはそうします。一般に、メソッドへのパラメーターは、java。*パッケージの基本型（int、char ...）およびクラスを使用する必要があります。 私はこれに反対する傾向があります。私はさまざまな理由addTrack(Track t)よりも優れていると信じていますaddTrack(int no, String title, double duration)： メソッドのパラメーターはできるだけ少ないほうが常に良いです（Uncle BobのClean Codeによれば、なしまたは1つ、できれば2、場合によっては3、特別な場合は3、3つ以上はリファクタリングが必要です-これらはもちろん推奨ルールではありません） 。 場合addTrackのインタフェースの方法であり、要件がいることを必要とするTrackより多くの情報（たとえば年またはジャンル）を持っている必要があり、インターフェイスを変更する必要があるので、この方法は、別のパラメータがサポートする必要があること。 カプセル化が壊れています。addTrackがインターフェイス内にある場合、の内部を知らないはずTrackです。 実際には、多くのパラメーターを使用して、2番目の方法でより結合されています。仮定noから変更するパラメータニーズをintへlong以上があるのでMAX_INT、トラック（または何らかの理由で）。Trackメソッドとメソッドの両方を変更する必要がありますが、メソッドaddTrack(Track track)のみTrackが変更される場合は変更します。 4つの引数はすべて実際には相互に関連しており、それらの一部は他からの結果です。 どのアプローチが良いですか？

16 design  object-oriented-design  coupling  design-principles 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 デメテルの法則は、結合と結合を備えたオブジェクト指向システムにどのように適用されますか？ 私は「ソフトウェア開発と専門的実践」という本を読んでいて、LoDに関する章に出くわし、その原理がオブジェクト指向システムにどのように適用されるのか興味がありました。

15 object-oriented  design-principles 

ISPに関する記事を読むとき、ISPには2つの矛盾する定義があるようです。 最初の定義（参照によると1、2、3）、ISPは、インターフェイスを実装するクラスは、彼らが必要としない機能を実装することを強制されるべきではないと述べています。したがって、太いインターフェイスIFat interface IFat { void A(); void B(); void C(); void D(); } class MyClass: IFat { ... } より小さなインターフェースに分割しISmall_1、ISmall_2 interface ISmall_1 { void A(); void B(); } interface ISmall_2 { void C(); void D(); } class MyClass:ISmall_2 { ... } このよう以来、私のMyClass唯一の方法、それが必要とする（実装することが可能であるD()とのC()またのためのダミー実装を提供することを余儀なくされることなく、） A()、B()およびC()： しかし、2番目の定義に従った（参照1、 2は、ナザールMerzaによって答えは、ISPはと述べている）MyClient上のメソッドを呼び出しますMyService上の方法を知っておくべきではないMyService、それは必要としないこと。つまり、とMyClientの機能のみが必要な場合、代わりにC()D() class MyService { public …

14 solid  design-principles 

この答えに触発された： リスコフの代替原則では 、 サブタイプでは前提条件を強化できません。 サブタイプでは事後条件を弱めることはできません。 スーパータイプの不変式は、サブタイプに保存する必要があります。 履歴制約（「履歴ルール」）。オブジェクトは、そのメソッド（カプセル化）によってのみ変更可能と見なされます。サブタイプはスーパータイプには存在しないメソッドを導入する可能性があるため、これらのメソッドの導入により、スーパータイプでは許可されないサブタイプの状態変更が可能になります。これは履歴制約により禁止されています。 これらの4つのポイントに違反するクラス階層を誰かが投稿し、それに応じてそれらを解決する方法を誰かが投稿することを望んでいました。 階層内の4つのポイントのそれぞれを識別する方法と、それを修正する最良の方法について、教育目的で詳細な説明を探しています。 注： 私は人々が作業するためのコードサンプルを投稿したいと思っていましたが、問題自体は障害のある階層を特定する方法に関するものです:)

14 object-oriented  inheritance  solid  design-principles  liskov-substitution 

依存関係の逆転の原理について学習しています。それはそれを述べています： 高レベルのモジュールは、低レベルのモジュールに依存するべきではありません。どちらも抽象化に依存する必要があります。 しばらく、私はそれが高レベルのコンポーネントと低レベルのコンポーネントの両方が抽象に依存し、それらに依存していることの意味を理解しようとしました。 どちらも同じ抽象化に何らかの形で依存する必要があると思います。これが間違っている場合は修正してください。 私はこれが何を意味するかについていくつかの結論に達しています。これが正しいかどうか確認してください。 「高レベルのコンポーネントは抽象化に依存しています」-意味： 高レベルコンポーネントは、具体的な低レベルコンポーネントと直接通信するのではなく、低レベルコンポーネントと通信するためにインターフェースと通信します。低レベルのコンポーネントはこのインターフェースを実装します。 「低レベルのコンポーネントは抽象化に依存しています」-意味： 低レベルのコンポーネントは、インターフェースの観点から定義および設計されています。それらはインターフェイスに合うように設計されています。それらは、インターフェースがそれらの設計方法を定義する方法で、インターフェースに依存しています。（多くの場合、低レベルのクラスがそのインターフェースを実装しています）。 このように、高レベルのコンポーネントと低レベルのコンポーネントはどちらも「抽象化に依存」していますが、方法は異なります。 これはよく理解していますか？

10 design  object-oriented  design-principles 

私はこのウィキを安定した抽象化の原則（SAP）で読んでいました。 SAPは、パッケージの安定性が高いほど、抽象的である必要があると述べています。これは、パッケージの安定性が低い（変更される可能性が高い）場合、より具体的であることを意味します。私が本当に理解していないのは、これが事実であるべき理由です。確かにすべての場合において、安定性に関係なく、抽象化に依存し、具体的な実装を隠す必要がありますか？

9 design  design-patterns  architecture  object-oriented-design  design-principles 

むかしむかし、継承についてStack Overflowで質問しました。 私はチェスエンジンをOOPファッションで設計すると言った。だから私はピースの抽象クラスからすべてのピースを継承しますが、継承はまだ続きます。コードで表示させてください public abstract class Piece { public void MakeMove(); public void TakeBackMove(); } public abstract class Pawn: Piece {} public class WhitePawn :Pawn {} public class BlackPawn:Pawn {} プログラマーは私の設計を少しエンジニアリングよりも見つけており、色付きのピースのクラスを削除し、以下のようなプロパティメンバーとしてピースの色を保持することを提案しました。 public abstract class Piece { public Color Color { get; set; } public abstract void MakeMove(); public abstract void …

9 design-patterns  object-oriented  programming-practices  design-principles 

そのため、プログラミングコードインタビューに関するビデオシリーズを見て、単一の真の情報源という用語を見つけました。 私が理解したことから、それは真実の単一のソースが複数回使用される可能性のあるあらゆるタイプの操作/ロジックのカプセル化であることを意味しました。 SRPは、何度も使用される可能性のある特定の操作やロジックをカプセル化するという意味でほぼ同じものです。 ここで私が見逃している非常に微妙なものはありますか？ いつもありがとうございました。

9 single-responsibility  design-principles 

私は本当にOOPを学び始めたばかりです。私は約1年前に開始し、おそらく15,000行を書きました。しかし、他の人のOOPを見た経験はほとんどありませんでした。 ほとんどのクラス関数は値を返すか、クラスのプロパティを変更してtrue / falseを返します。値を返すものの一部は、その値をクラスプロパティに保存します（クラスプロパティが既に設定されているかどうかを最初に確認した後、データベースの呼び出しを回避できます）。 今私はMagento / Zendで多くの掘り下げを行っており、それらのクラスメソッドの多くが "$ this"を返すことに気づきました。私が理解しているように、通常の関数とは異なり、$ thisを返すクラスメソッドは値ではなく参照によって動作するため、コピーではなく、最初に開始したのと同じオブジェクトを取得できます。 $thisもっとやりたいことを返すのですか？コードの保守と使用が容易になりますか？$thisクラスメソッドをチェーンするために戻り値は必要ですか？

8 php  object-oriented  design-principles