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

アプリケーションをMVCにリファクタリングしようとしていますが、Mの部分にこだわっています。 データベース対応のアプリでは、モデルはアプリのコードに実装されますよね？ しかし、その後、データベースには何がありますか？それはモデルではありませんか？ （データベースを単純なオブジェクトストアとして使用していません。DB内のデータはエンタープライズ資産です）。

14 design-patterns  mvc 

設計パターンが必要になる前に実装することにより、時期尚早に複雑さを導入することは良い習慣ではありません。 しかし、すべての（またはほとんどの）SOLIDの原則に従い、共通の設計パターンを使用すると、機能と要件が追加または変更され、設計が必要に応じて保守可能かつ柔軟に維持されるため、多少の複雑さが生じます。 しかし、その複雑さが導入され、チャンピオンのように機能するようになったら、いつそれを削除しますか？ 例。クライアント用に作成されたアプリケーションがあります。元々従業員に昇給を与えるいくつかの方法がある場所で作成されたとき。戦略パターンとファクトリーを使用して、プロセス全体をきれいに保ちました。時間が経つにつれて、アプリケーション所有者によって追加または削除される特定のraiseメソッド。 時間が経ち、新しい所有者が引き継ぎます。この新しい所有者は頑固で、すべてをシンプルに保ち、昇給する方法は1つしかありません。 戦略パターンに必要な複雑さはもはや必要ありません。現在の要件からこれをコーディングする場合、この余分な複雑さは導入しません（ただし、必要に応じてほとんど、またはまったく作業をせずに導入できることを確認してください）。 戦略の実装を今すぐ削除しますか？この新しい所有者が昇給の方法を変えることはないと思います。しかし、アプリケーション自体は、これが起こる可能性があることを実証しています。 もちろん、これは新しい所有者が引き継ぎ、多くのプロセスを簡素化したアプリケーションのほんの一例です。数十のクラス、インターフェース、ファクトリーを削除し、アプリケーション全体をよりシンプルにすることができました。現在の実装は正常に機能し、所有者はそれで満足していることに注意してください（そして、議論された複雑さのために、私は彼女の変更を非常に迅速に実装できたことに驚き、そしてさらに幸せです）。 この疑いのほんの一部は、新しい所有者が私をもう使用しない可能性が高いためです。大きな収入源ではないので、他の誰かがこれを引き継ぐことを本当に気にしません。 しかし、私は2つの（関連する）ことを気にします コードを理解しようとするとき、新しいメンテナーが少し難しく考える必要があることに少し気を配ります。複雑さは複雑さであり、私に続く心理マニアを怒らせたくありません。 しかし、競合他社がこの複雑さを認識し、仕事に時間を費やすためにデザインパターンを実装するだけだと考えていることをさらに心配しています。次に、この噂を広めて、他のビジネスを傷つけました。（私はこれが言及されたと聞いています。） そう... 一般に、以前は必要だった複雑さは、それが機能し、複雑さに対する歴史的に実証された必要性があったとしても削除されるべきですが、将来必要になるという兆候はありませんか？ 上記の質問が一般的に「いいえ」と回答されたとしても、プロジェクトを競合他社（または見知らぬ人）に引き渡す場合、この「不要な」複雑さを取り除くことは賢明でしょうか？

14 design-patterns  complexity  customer-relations 

プログラムの設計に「マネージャー」クラスが多すぎるとコードの匂いがして、不要な複雑なレイヤーが追加されると聞きます。私にとって、人々が意味のあるコンテキストからオブジェクトを操作および制御するためにマネージャークラスを使用したいのは理にかなっていますが、ソリューションをそれらなしで機能させる方法を理解することは混乱する可能性があります。 マネージャークラスを可能な限り避けるべきですか？また、これらのマネージャーを削除できる一般的な/一般的なケースの代替回避策を実装する方法について、どの記事/論文を読むべきですか？

14 object-oriented  design-patterns  coding 

作業中のレガシーシステムでこれをよく見ました。次のような機能があります。 bool todo = false; if(cond1) { ... // lots of code here if(cond2) todo = true; ... // some other code here } if(todo) { ... } つまり、関数には2つの部分があります。最初の部分は何らかの処理（ループ、副作用などを含む可能性があります）を実行し、その途中で「todo」フラグを設定します。2番目の部分は、「todo」フラグが設定されている場合にのみ実行されます。 物事を行うのはかなりlyい方法のように思えます。実際に時間をかけて理解したほとんどのケースは、フラグの使用を避けるためにリファクタリングできると思います。しかし、これは実際のアンチパターンであるか、悪いアイデアであるか、それとも完全に受け入れられるものですか？ 最初の明らかなリファクタリングは、2つの方法に分割することです。ただし、私の質問は、ローカルフラグ変数を作成し、複数の場所に潜在的に設定し、後でそれを使用して次のコードブロックを実行するかどうかを決定する必要があるかどうか（現代のOO言語）についてです。

14 design-patterns  anti-patterns  patterns-and-practices 

C＃プロジェクトのクラス階層を設計する必要があります。基本的に、クラスの機能はWinFormsクラスに似ているため、WinFormsツールキットを例に取りましょう。（ただし、WinFormsやWPFは使用できません。） すべてのクラスが提供する必要があるいくつかのコアプロパティと機能があります。寸法、位置、色、可視性（true / false）、Drawメソッドなど。 設計上のアドバイスが必要です。抽象ベースクラスと実際には型ではなく、動作に似たインターフェイスを持つ設計を使用しました。これは良いデザインですか？そうでない場合、より良いデザインになります。 コードは次のようになります。 abstract class Control { public int Width { get; set; } public int Height { get; set; } public int BackColor { get; set; } public int X { get; set; } public int Y { get; set; } public int BorderWidth { get; …

14 c#  object-oriented  design-patterns  class-design 

割り当てのために、私は4デザインパターンのギャングのどのクラスを見つけるために持っているjava.io.Readerとそのサブクラスをjava.io.PushbackReader、java.io.BufferedReaderとjava.io.FilterReaderして建設されました。 この投稿によると、デザインパターンはデコレータパターンになります。これは場合にのみ、私には理にかなってPushbackReader、BufferedReaderそしてFilterReader効果的に作成し、同時に使用されるように装飾することができますBufferedPushbackFilterReader。それはアイデアですか？

14 java  design-patterns 

私は過去にMVPとMVCを使用しましたが、MVPのほうが実行の流れを非常によく制御できるので、私の意見ではMVPを好んでいます。 インフラストラクチャ（データストア/リポジトリクラス）を作成し、サンプルデータをハードコーディングするときに問題なく使用できるので、GUIに移行してMVPを準備しています。 セクションA エントリポイントとしてビューを使用するMVPを見ました。つまり、ビューコンストラクターメソッドでプレゼンターを作成し、次にプレゼンターがモデルを作成し、必要に応じてイベントを関連付けます。 プレゼンターは、ビュー、モデル、プレゼンターが作成されるエントリポイントとしても見てきました。このプレゼンターには、コンストラクターでビューとモデルオブジェクトが与えられ、イベントを結び付けます。 2と同じですが、モデルはプレゼンターに渡されません。代わりに、モデルはメソッドが呼び出され、応答が直接返される静的クラスです。 セクションB 私が見たビューとモデルの同期を保つという点で。 ビューの値が変更されたとき、つまりTextChanged.Net / C＃のイベントが発生したとき。これDataChangedEventにより、モデルに渡されるa が起動され、常に同期が保たれます。そして、モデルが変化する場所、つまり、モデルがリッスンするバックグラウンドイベントの場合、ビューはを上げるという同じアイデアによって更新されDataChangedEventます。ユーザーが変更をコミットSaveEventしようとすると、モデルが起動して保存されます。この場合、モデルはビューのデータを模倣し、アクションを処理します。 ＃b1と同様ですが、ビューは常にモデルと同期しません。代わりに、ユーザーが変更をコミットしたい場合に起動SaveEventされ、プレゼンターは最新の詳細を取得してモデルに渡します。この場合、モデルは、それに基づいて行動する必要があるまでビューデータを認識しません。その場合、必要なすべての詳細が渡されます。 セクションC ビュー内のビジネスオブジェクト、つまりプリミティブデータ（int、double）ではなくオブジェクト（MyClass）の表示 ビューには、ドメイン/ビジネスオブジェクトとして表示されるすべてのデータのプロパティフィールドがあります。ビューはこれらをTreeViewのノードに処理しますが、プロパティをview.Animals公開するなどIEnumerable<IAnimal>。次に、選択した動物について、プロパティSelectedAnimalとして公開しIAnimalます。 ビューはドメインオブジェクトの知識を持たず、プリミティブ/フレームワーク（.Net / Java）に含まれるオブジェクトタイプのみのプロパティを公開します。この場合、プレゼンターはアダプターオブジェクトにドメインオブジェクトを渡し、アダプターは特定のビジネスオブジェクトをビューに表示されるコントロールに変換します。この場合、アダプターは、ビューだけでなく、ビューの実際のコントロールにアクセスできる必要があるため、より緊密に結合されます。 セクションD 単一のコントロールを作成するために使用される複数のビュー。つまり、さまざまなタイプのオブジェクトを保存するような単純なモデルを持つ複雑なビューがあります。適切なコントロールが表示される項目をクリックするたびに、メニューシステムを横に配置できます。 ビューインターフェイスを介して公開される個々のコントロールすべてを含む1つの巨大なビューを作成します。 いくつかのビューがあります。メニュー用のビューとブランクパネルが1つあります。このビューは、必要な他のビューを作成しますが、表示しません（visible = false）。このビューは、含まれる各ビュー（子ビュー）のインターフェイスも実装するため、1人のプレゼンターに公開できます。空白のパネルには、他のビュー（Controls.Add(myview)）および（(myview.visible = true）が表示されます。これらの「子」ビューで発生したイベントは、親ビューによって処理されます。親ビューは、イベントをプレゼンターに渡し、逆もまた同様です。 メインビューであれ小さなビューであれ、それぞれのビューは、それぞれ独自のプレゼンターとモデルに配線されます。ビューコントロールを既存のフォームに文字通りドロップするだけで、機能の準備が整い、舞台裏でプレゼンターに配線するだけで済みます。 セクションE すべてにインターフェースがある場合、上記の例でMVPがどのように行われるかに基づいて、相互互換性がない可能性があるため、この回答に影響します。 すべてには、View、Presenter、Modelというインターフェースがあります。これらのそれぞれは、明らかに具体的な実装を持っています。具体的なビューが1つしかない場合でも、モデルとプレゼンター。 ビューとモデルにはインターフェースがあります。これにより、ビューとモデルが異なります。プレゼンターは、ビューおよびモデルオブジェクトを作成/指定され、それらの間でメッセージを渡すだけです。 ビューのみにインターフェースがあります。モデルには静的メソッドがあり、作成されないため、インターフェースは不要です。別のモデルが必要な場合、プレゼンターは静的クラスメソッドの別のセットを呼び出します。モデルは静的であるため、プレゼンターへのリンクはありません。 個人的な考え 私が提示したすべての異なるバリエーション（ほとんどはおそらく何らかの形で使用しました）から、さらに多くのバリエーションがあると確信しています。A3は、MVPの外でビジネスロジックを再利用可能に保つこと、A2はデータの重複を減らし、発生するイベントを減らすことを好みます。C1は別のクラスに追加しないため、少量のユニットテスト不可能なロジックをビューに入れます（ドメインオブジェクトの視覚化方法）が、これはコードレビューするか、アプリケーションで単に表示することができます。ロジックが複雑な場合、アダプタークラスに同意しますが、すべての場合に同意するわけではありません。セクションDの場合、D1はメニューの例としては大きすぎるビューを作成すると感じています。以前にD2とD3を使用しました。D2の問題は、イベントをプレゼンターとの間で適切な子ビューにルーティングするために大量のコードを記述する必要があり、ドラッグ/ドロップ互換性がないことです。新しいコントロールごとに、単一のプレゼンターをサポートするためにより多くの配線が必要です。D3は私の好みの選択肢ですが、ビューが非常に単純であるか、再利用する必要がない場合でも、ビューを処理するプレゼンターおよびモデルとしてさらに多くのクラスを追加します。D2とD3の混合物は、状況に基づいて最適だと思います。セクションEに関しては、インターフェースを持つものはすべてやりすぎだと思うので、ドメイン/ビジネスオブジェクトに対しては既にそれを行っており、そうすることで「デザイン」に利点がないことがよくありますが、テストでオブジェクトをモックするのに役立ちます。個人的には、E2を古典的なソリューションと考えていますが、E3は以前に取り組んだ2つのプロジェクトで使用されています。D2とD3の混合物は、状況に基づいて最適だと思います。セクションEに関しては、インターフェースを持つものはすべてやりすぎだと思うので、ドメイン/ビジネスオブジェクトに対しては既にそれを行っており、そうすることで「デザイン」に利点がないことがよくありますが、テストでオブジェクトをモックするのに役立ちます。個人的には、E2を古典的なソリューションと考えていますが、E3は以前に取り組んだ2つのプロジェクトで使用されています。D2とD3の混合物は、状況に基づいて最適だと思います。セクションEに関しては、インターフェースを持つものはすべてやりすぎだと思うので、ドメイン/ビジネスオブジェクトに対しては既にそれを行っており、そうすることで「デザイン」に利点がないことがよくありますが、テストでオブジェクトをモックするのに役立ちます。個人的には、E2を古典的なソリューションと考えていますが、E3は以前に取り組んだ2つのプロジェクトで使用されています。 質問 MVPを正しく実装していますか？適切な方法はありますか？ バリエーションのあるマーティン・ファウラーの作品を読んだことがあり、MVCを始めたとき、コンセプトを理解していましたが、エントリポイントがどこにあるのか、すべてが独自の機能を持っていますが、オリジナルを制御して作成するものは元々理解できませんでしたMVCオブジェクトのセット。

14 c#  design  design-patterns  winforms 

「関数の理想的な引数の数はゼロです」は明らかに間違っています。引数の理想的な数は、関数に副作用がないようにするために必要な数です。それよりも少ないと、機能が不必要に不必要になり、成功の穴から離れて痛みの勾配を登らざるを得なくなります。時々、「ボブおじさん」が彼のアドバイスにスポットを当てています。時々彼は見事に間違っています。彼のゼロ引数アドバイスは後者の例です （ソース：このサイトの別の質問の下での@David Arnoによるコメント） コメントには133の賛成票があります。そのため、そのメリットにもっと注意を払いたいと思います。 私が知っている限りでは、プログラミングには2つの別々の方法があります：純粋な関数型プログラミング（このコメントが奨励するもの）と伝える、尋ねない（このWebサイトでも時々推奨されています）。私の知る限り、これらの2つの原則は基本的に互換性がなく、互いに反対に近いものです。副作用しかありません」。また、純粋なファンシトンが機能的パラダイムのコアと考えられているのに、聞かないで、OOパラダイムのコアと考えられていると思ったので、私はちょっと困惑しています。 開発者はおそらくこれらのパラダイムのいずれかを選択し、それに固執すべきでしょうか？まあ、私は自分を決して従わせることができなかったことを認めなければなりません。多くの場合、値を返すのが便利だと思われ、副作用でのみ達成したいことをどのように達成できるか本当にわかりません。多くの場合、副作用があると便利に思えますが、値を返すだけで達成したいことをどのように達成できるか本当にわかりません。また、しばしば（これは恐ろしいことだと思います）両方を行うメソッドがあります。 しかし、これらの133の賛成票から、私は現在純粋な関数型プログラミングが「勝っている」と推論しています。これは正しいです？ したがって、このアンチパターンに乗ったゲームの例で私が作ろうとしているのは、純粋に機能的なパラダイムに準拠させるためにそれを実現したい場合、どうすればいいのでしょうか？！ 戦闘状態にあることは私にとって理にかなっているようです。これはターンベースのゲームであるため、私は辞書に戦闘状態を保持します（マルチプレイヤー-同時に多くのプレイヤーがプレイする多くの戦闘があるかもしれません）。プレーヤーが順番を回すたびに、（a）状態を適宜変更し、（b）更新をプレーヤーに返します。これは、JSONにシリアル化され、基本的に、ボード。これは、両方の原則に同時に違反していると思われます。 OK-本当にやりたいなら、メソッドをその場で修正するのではなく、戦闘状態に戻すことができます。だが！それから、完全に新しい状態を変更するのではなく、単に戻すために、戦闘状態のすべてを不必要にコピーする必要がありますか？ おそらく、移動が攻撃である場合、HPが更新されたキャラクターを返すことができますか？問題は、それほど単純ではないことです。ゲームのルール、動きは、プレイヤーのHPの一部を削除するだけでなく、多くの場合、より多くの効果をもたらします。たとえば、キャラクター間の距離を広げたり、特殊効果を適用したりすることができます。 私はその場で状態を変更して更新を返す方がはるかに簡単に思えます... しかし、経験豊富なエンジニアはこれにどのように取り組むでしょうか？

14 design-patterns  pure-function 

私はオブジェクト指向とベクターベースのデザインの間で引き裂かれています。オブジェクトがアーキテクチャ全体に与える能力、構造、安全性が大好きです。しかし同時に、速度は私にとって非常に重要であり、配列に単純なフロート変数があると、MatlabやPythonのnumpyなどのベクトルベースの言語/ライブラリで非常に役立ちます。 これが私のポイントを説明するために書いたコードです 問題：トウのボラティリティ値を追加します。xとyが2つのボラティリティ数である場合、ボラティリティの合計は（x ^ 2 + y ^ 2）^ 0.5です（特定の数学的条件を仮定しますが、ここでは重要ではありません）。 この操作を非常に高速に実行すると同時に、人々がボラティリティを間違った方法（x + y）で追加しないようにする必要があります。これらは両方とも重要です。 オブジェクト指向ベースのデザインは次のようになります。 from datetime import datetime from pandas import * class Volatility: def __init__(self,value): self.value = value def __str__(self): return "Volatility: "+ str(self.value) def __add__(self,other): return Volatility(pow(self.value*self.value + other.value*other.value, 0.5)) （余談：Pythonを初めて使用する場合__add__は、単なる+演算子をオーバーライドする関数です） ボラティリティ値のトウリストを追加するとしましょう n = 1000000 vs1 = Series(map(lambda …

14 design-patterns  object-oriented  python  speed 

Controllerクラスから直接呼び出されるDAOに対するさまざまな引数と、ModelクラスからのDAOに対するさまざまな引数を見てきました。実際、MVCパターンに従っている場合、コントローラーはDAOと結合するべきではなく、Modelクラス内部からDAOを呼び出し、コントローラーがモデルクラスを呼び出す必要があるのは、なぜWebアプリケーションからモデルクラスを切り離し、RESTサービスがモデルクラスを使用するなどのさまざまな方法で機能を公開できるからです。 コントローラでDAO呼び出しを記述する場合、RESTサービスが機能を再利用することはできません。両方のアプローチを以下にまとめました。 アプローチ＃1 public class CustomerController extends HttpServlet { proctected void doPost(....) { Customer customer = new Customer("xxxxx","23",1); new CustomerDAO().save(customer); } } アプローチ＃2 public class CustomerController extends HttpServlet { proctected void doPost(....) { Customer customer = new Customer("xxxxx","23",1); customer.save(customer); } } public class Customer { ........... private void save(Customer customer){ …

14 java  mvc  design-patterns  dao 

RESTful APIを開発しており、リソースにDAOを使用すると便利だと思います。メモリを使用してそれらを格納するだけですが、使用することに決めた場合はライブラリを使用しているユーザーのドアを閉めたくないためです。 DAOのデータベース実装。 私の質問は、DAOがシングルトンであるかどうかです。そうでない場合、サービスにはDAOのインスタンスがあり、おおよそ次のようになります。 @Path("eventscheduler") public class EventSchedulerService { private IEventSchedulerDao dao = new EventSchedulerDao(); // in case a different implementation is to be used public void setEventSchedulerDao(IEventSchedulerDao dao) { this.dao = dao; } @Path("{uniqueName}") @GET @Produces(MediaType.APPLICATION_JSON) public Tournament getTournament(@PathParam("name") String uniqueName) { return dao.get(uniqueName); } @Path("create") @POST @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) …

14 java  design  design-patterns  singleton  dao 

閉じた。この質問には、詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善したいですか？詳細を追加し、この投稿を編集して問題を明確にします。 5年前に閉鎖されました。 最近、MVCのデザインパターンについて学びました。私はHead First Design Pattern本から学んでいます。 この本によると（私が正しく理解している場合）： モデルは、ほとんどのアプリケーションロジックとデータです。 ビューは、基本的にモデルをユーザーに視覚的に表すGUIです。 コントローラーは、ビューとモデルの間の「仲介」と「仲介者」としての役割を果たす責任があります。ビューは、ユーザーがアクションを実行したことをコントローラーに報告し、コントローラーはそれをモデルのメソッド呼び出しに変換します。 しかし、ウェブ上の多くの場所は、私がその本から理解していることと矛盾しています。彼らは一般的に、ユーザーがビューではなくコントローラーと対話することを主張しています。 どちらが本当ですか、それともより一般的ですか？ユーザーはコントローラーと直接対話しますか、それともビューと直接対話しますか？両方のアプローチは受け入れられますか？どちらがより一般的ですか？

14 design-patterns  mvc 

Strategyパターンは、巨大なif ... elseコンストラクトを回避し、機能の追加または置換を容易にするためにうまく機能します。しかし、それでも私の意見には1つの欠陥が残っています。どの実装でも、分岐構造が必要であるようです。ファクトリまたはデータファイルの可能性があります。例として、注文システムを取り上げます。 工場： // All of these classes implement OrderStrategy switch (orderType) { case NEW_ORDER: return new NewOrder(); case CANCELLATION: return new Cancellation(); case RETURN: return new Return(); } この後のコードは心配する必要はなく、新しい注文タイプを追加する場所は1つだけですが、このセクションのコードはまだ拡張できません。データファイルにそれを引き出すことは、読みやすさをいくらか助けます（議論の余地があります、私は知っています）： <strategies> <order type="NEW_ORDER">com.company.NewOrder</order> <order type="CANCELLATION">com.company.Cancellation</order> <order type="RETURN">com.company.Return</order> </strategies> しかし、これにより、データファイルを処理するための定型コードが追加されます。付与された、より簡単にユニットテスト可能で、比較的安定したコードですが、それでも複雑さが増します。 また、この種のコンストラクトは統合テストがうまくいきません。個々の戦略は今すぐテストする方が簡単かもしれませんが、追加するすべての新しい戦略はテストの複雑さを増すことになります。パターンを使用していなかった場合よりも少ないですが、それはまだあります。 この複雑さを緩和する戦略パターンを実装する方法はありますか？それとも、これはそれと同じくらい簡単で、さらに先へ進んでも、抽象化の別の層を追加するだけで、ほとんどまたはまったく利益がありませんか？

14 design  design-patterns  unit-testing  strategy 

どのデザインパターンがこの問題の解決に役立つかはわかりません。 使用するWorkerクラスを決定する「コーディネーター」クラスがあります-存在するすべての種類のWorkerについて知る必要はありませんが、WorkerFactoryを呼び出し、共通のIWorkerインターフェイスに基づいて動作します。 次に、適切なWorkerを動作するように設定し、 'DoWork'メソッドの結果を返します。 これまでは順調でした...今までは。新しいワーカークラス「WorkerB」の新しい要件があります。これは、作業を行うために追加の情報、つまり追加の入力パラメーターを必要とします。 余分な入力パラメーターを使用してオーバーロードされたDoWorkメソッドが必要なようですが、既存のすべてのワーカーはそのメソッドを実装する必要があります。これらのワーカーは本当にそのメソッドを必要としないので間違っているようです。 これをリファクタリングして、どのワーカーが使用されているかをコーディネーターに認識させずに、各ワーカーがジョブを実行するために必要な情報を取得できるようにしますが、不要な作業はワーカーに行わせませんか？ 既に多くの既存のワーカーがいます。 新しいWorkerBクラスの要件に対応するために、既存の具象ワーカーを変更する必要はありません。 ここではデコレータパターンが良いと思うかもしれませんが、デコレータが同じメソッドでオブジェクトを異なるパラメータで装飾するのを見たことはありません... コードの状況： public class Coordinator { public string GetWorkerResult(string workerName, int a, List<int> b, string c) { var workerFactor = new WorkerFactory(); var worker = workerFactor.GetWorker(workerName); if(worker!=null) return worker.DoWork(a, b); else return string.Empty; } } public class WorkerFactory { public IWorker …

14 c#  design-patterns 

デメテルの法則に関して3つの質問があります。 別に特にリターンオブジェクトに任命されたクラスから-などの工場やビルダークラスなど-それは、例えば、クラスのプロパティの1つが保持しているか、それが違反するオブジェクト、オブジェクトを返すメソッドのために大丈夫ですデメテルの法則（1） ？そして、それがデメテルの法則に違反する場合、返されるオブジェクトがデータの一部を表し、このデータのゲッターのみを含む不変オブジェクトであるかどうかは問題になりますか？または、そのようなValueObjectはそれ自体がアンチパターンですか？そのクラスのデータで行われていることはすべてクラスの外部で行われているためです（2b）？ 擬似コードで： class A {} class B { private A a; public A getA() { return this.a; } } class C { private B b; private X x; public void main() { // Is it okay for B.getA to exist? A a = this.b.getA(); a.doSomething(); x.doSomethingElse(a); } } …

13 design-patterns  law-of-demeter