タグ付けされた質問 「object-oriented」

質問の短い形式 エンティティメソッドの呼び出しにサービスを注入することは、DDDおよびOOPのベストプラクティスの範囲内ですか？ 長い形式の例 DDDに従来のOrder-LineItemsケースがあるとします。ここでは、Orderと呼ばれるドメインエンティティがあり、これは集約ルートとしても機能し、そのエンティティは値オブジェクトだけでなく、ラインアイテムのコレクションからも構成されます。エンティティ。 アプリケーションで流暢な構文を使用して、次のようなことができると仮定します（getLineItemsメソッドを呼び出す2行目の構文に注目してください）。 $order = $orderService->getOrderByID($orderID); foreach($order->getLineItems($orderService) as $lineItem) { ... } OrderEntityにLineItemRepositoryを挿入したくないのは、それが考えられるいくつかの原則に違反しているためです。しかし、構文の流暢さは私たちが本当に望んでいるものです。それは、テストだけでなく、読みやすく、保守しやすいからです。 のメソッドgetLineItemsに注意して、次のコードを検討してくださいOrderEntity。 interface IOrderService { public function getOrderByID($orderID) : OrderEntity; public function getLineItems(OrderEntity $orderEntity) : LineItemCollection; } class OrderService implements IOrderService { private $orderRepository; private $lineItemRepository; public function __construct(IOrderRepository $orderRepository, ILineItemRepository $lineItemRepository) { $this->orderRepository = $orderRepository; …

11 object-oriented  php  domain-driven-design  domain-model  lazy-initialization 

私はレイモンドヘッティンガーのPyconの講演「スーパー考慮スーパー」を見て、クラスの「親」クラスを決定論的な方法で線形化するPythonのMRO（メソッド解決順序）について少し学びました。これを使用して、以下のコードのように、依存性注入を行うことができます。だから今は当然、super何にでも使いたい！ 次の例では、Userクラスは、LoggingServiceとの両方から継承することで、依存関係を宣言していUserServiceます。これは特に特別なことではありません。興味深いのは、メソッド解決順序を使用して、単体テスト中に依存関係を模擬できることです。以下のコードは、モックしたいメソッドのMockUserService継承UserServiceと実装を提供するを作成します。以下の例では、の実装を提供していますvalidate_credentials。へのMockUserService呼び出しを処理validate_credentialsするにUserServiceは、MROの前に配置する必要があります。これは、User呼び出されるラッパークラスを作成し、MockUserそれをUserand から継承させることで行われMockUserServiceます。 これを実行するMockUser.authenticateと、次に、への呼び出しがメソッド解決順序のsuper().validate_credentials() MockUserService前UserServiceにあり、validate_credentialsこの実装の具体的な実装が提供されるため、これが使用されます。いいですね- UserService単体テストでうまく模倣しました。UserServiceコストのかかるネットワークやデータベースの呼び出しが発生する可能性があることを考慮してください。これにより、レイテンシ係数が削除されました。また、UserServiceライブ/製品データに触れるリスクもありません。 class LoggingService(object): """ Just a contrived logging class for demonstration purposes """ def log_error(self, error): pass class UserService(object): """ Provide a method to authenticate the user by performing some expensive DB or network operation. """ def validate_credentials(self, username, password): print('> UserService::validate_credentials') return username == …

11 object-oriented  python  dependency-injection  multiple-inheritance 

ではオブジェクト指向のアラン・ケイズ定義が部分的に私は理解していないことを、この定義は次のとおりです。 私にとってOOPとは、メッセージング、ローカルでの保持と状態プロセスの保護と非表示、およびすべてのものの極端なLateBindingのみを意味します。 しかし、「LateBinding」とはどういう意味ですか？これをC＃などの言語に適用するにはどうすればよいですか？そして、なぜこれがそれほど重要なのでしょうか？

11 object-oriented  object-oriented-design 

クラスが単一責任の原則に違反しているかどうかを確認するために人々が使用する実用的なテクニックは何ですか？ クラスには変更する理由が1つだけあるべきだと知っていますが、その文は実際にそれを実装する実用的な方法に少し欠けています。 私が見つけた唯一の方法は、「それは…………それ自体……」という文を使うことです。ここで、最初のスペースはクラス名で、後はメソッド（責任）名です。 ただし、責任が本当にSRPに違反しているかどうかを判断するのが難しい場合があります。 SRPを確認する方法は他にありますか？ 注意： 問題は、SRPの意味ではなく、SRPを確認して実装するための実際的な方法論または一連の手順です。 更新 SRPに明らかに違反するサンプルクラスを追加しました。単一の責任の原則にどのように取り組むかを説明するための例として、人々がそれを使用できれば素晴らしいと思います。 例はここからです。

11 design  design-patterns  object-oriented  refactoring  single-responsibility 

まず、この質問はゲーム開発のトピックに関連していることを認識していますが、実際にはより一般的なソフトウェア生成問題に帰着するので、ここで質問することにしました。 過去1か月間に、Entity-Component-Systemsについてたくさん読んだので、今はその概念にとても慣れています。ただし、明確な「定義」が欠落しているように見える側面が1つあり、記事によって根本的に異なる解決策が提案されています。 これは、ECSがカプセル化を解除する必要があるかどうかの問題です。つまり、そのOOPスタイルのECS（コンポーネントは、それらに固有のデータをカプセル化する状態と動作の両方を持つオブジェクト）と純粋なECS（コンポーネントは、パブリックデータのみを持ち、システムが機能を提供するcスタイルの構造体）です。 フレームワーク/ API /エンジンを開発していることに注意してください。したがって、目標は、それを使用している人なら誰でも簡単に拡張できることです。これには、新しいタイプのレンダリングまたは衝突コンポーネントの追加などが含まれます。 OOPアプローチの問題 コンポーネントは他のコンポーネントのデータにアクセスする必要があります。たとえば、renderコンポーネントのdrawメソッドは、transformコンポーネントの位置にアクセスする必要があります。これにより、コードに依存関係が作成されます。 コンポーネントはポリモーフィックになる可能性があり、さらに複雑さをもたらします。たとえば、レンダーコンポーネントの仮想描画メソッドをオーバーライドするスプライトレンダーコンポーネントがある場合があります。 純粋なアプローチの問題 ポリモーフィックな動作（レンダリングなど）はどこかに実装する必要があるため、システムに外部委託するだけです。（たとえば、スプライトレンダーシステムは、レンダーノードを継承するスプライトレンダーノードを作成し、それをレンダーエンジンに追加します） システム間の通信は避けるのが難しい場合があります。たとえば、衝突システムには、そこにある具体的なレンダリングコンポーネントから計算される境界ボックスが必要な場合があります。これは、データを介して通信させることで解決できます。ただし、レンダリングシステムがバウンディングボックスコンポーネントを更新し、衝突システムがそれを使用するため、これによりインスタント更新が削除されます。システムの更新関数を呼び出す順序が定義されていないと、問題が発生する可能性があります。他のシステムがハンドラーをサブスクライブできるイベントをシステムが発生できるようにするイベントシステムがあります。ただし、これはシステムに何をすべきか、つまりvoid関数を伝える場合にのみ機能します。 追加のフラグが必要です。たとえば、タイルマップコンポーネントを見てみましょう。サイズ、タイルサイズ、インデックスリストフィールドがあります。タイルマップシステムは、それぞれの頂点配列を処理し、コンポーネントのデータに基づいてテクスチャ座標を割り当てます。ただし、フレームごとにタイルマップ全体を再計算するにはコストがかかります。したがって、システムでそれらを更新するために行われたすべての変更を追跡するために、リストが必要になります。OOPの方法では、これはタイルマップコンポーネントによってカプセル化できます。たとえば、SetTile（）メソッドは、呼び出されるたびに頂点配列を更新します。 純粋なアプローチの美しさはわかりますが、従来のOOPよりも具体的にどのようなメリットがあるのか​​はよくわかりません。コンポーネント間の依存関係は、システムに隠されていますが、依然として存在しています。また、同じ目標を達成するには、さらに多くのクラスが必要になります。これは私には、決して良いことではない、やややりすぎたソリューションのように思えます。 さらに、私はパフォーマンスにそれほど関心がないので、データ指向の設計とキャッシュミスのこの全体的な考えは、私にはそれほど重要ではありません。素敵な建築物が欲しいだけです^^ それでも、私が読んだ記事や議論のほとんどは、2番目のアプローチを提案しています。どうして？ アニメーション 最後に、純粋なECSでアニメーションをどのように処理するかについて質問したいと思います。現在、私はアニメーションを、0と1の間の進行状況に基づいてエンティティを操作するファンクタとして定義しています。アニメーションコンポーネントには、アニメーションのリストを持つアニメーターのリストがあります。次に、更新機能で、現在アクティブなアニメーションをエンティティに適用します。 注意： 私はこの投稿を読んだばかりですが、エンティティコンポーネントシステムアーキテクチャオブジェクトは定義によって指向されていますか？これは私よりも少し問題を説明します。基本的に同じトピックを扱っていますが、純粋なデータアプローチの方が優れている理由についてはまだ答えがありません。

11 design-patterns  object-oriented  game-development  entity-component-system 

たとえば、クラスには通常、クラスのメンバーとメソッドがあります。例： public class Cat{ private String name; private int weight; private Image image; public void printInfo(){ System.out.println("Name:"+this.name+",weight:"+this.weight); } public void draw(){ //some draw code which uses this.image } } しかし、単一責任の原則とオープンクローズの原則について読んだ後、クラスをDTOと静的メソッドのみのヘルパークラスに分離することを好みます。例： public class CatData{ public String name; public int weight; public Image image; } public class CatMethods{ public static void printInfo(Cat …

10 object-oriented  static-methods  dto 

私の質問は強く型付けされた言語に関係しますが、SwiftでUserオブジェクトを作成します。ユーザーは多数のリンク（FacebookProfile、InstagramProfileなど）を持つことができます。これに関するいくつかの質問。 リンクを独自のオブジェクトでラップすることは良い習慣ですか？ struct User { var firstName：文字列 var lastName：文字列 var email：string varリンク：リンク } 構造体リンク{ var facebook：string var instagram：文字列 var twitter：文字列 } それともルーズにすべきですか？技術的にはどちらの方法でも問題ないことはわかっていますが、一般的に、特に読みやすさのために、推奨されるアプローチがあるかどうか疑問に思います。 struct User { var firstName: string var lastName: string var email: string var facebookLink: string var twitterLink: string var instagramLink: string } このようなシナリオでは、リンクはコレクション/リストにする必要がありますか？利用可能なリンクオプションの数は決まっているため、リストの数にしないでください。数は増えていません。私の考えは正しいですか？ getUsers、getUser、updateUserなどのユーザーオブジェクト内にネットワークメソッドを配置することは良い習慣ですか？ これらは主観的である可能性があることは知っていますが、同様の状況でのベストプラクティスを理解しようとしています。任意のポインタをいただければ幸いです。

10 java  c#  object-oriented  data-structures  swift-language 

プロジェクトを構築する必要が生じたときはいつでも、事前に計画や設計を考案するのではなく、いつでもそれを構築することができましたが、最初に必要なクラスを書いた後、プロジェクト全体を具体化し、ボトムアップで構築しました。これはソフトウェアを作成する適切な方法ではないことはわかっていますが、オブジェクト指向分析とデザインと呼ばれるものに頭を悩ますことは簡単ではありません。トップダウンの手順設計をより簡単に理解できます。それは、タスクをサブタスクに分解することで構成されているためです。しかし、オブジェクト指向の分析と設計は簡単に理解できません。どのようにコード化するかを知らない限り、必要なクラスとそれらがどのように相互作用するかを知る方法がわかりません。 クラスとオブジェクトの概念を設計プロセスに導入すると、問題をプロシージャとして実装できるものに分解することがなくなるため、トップダウンで設計することができなくなります。代わりに、私が主題について読んだ内容に従って、必要なクラスを決定し、ソフトウェアを実装するときに使用できる統一モデリング言語でさまざまなアーティファクトを作成する必要があります。しかし、私はこの種の設計プロセスを理解していません。すでにシステム全体を考えていなければ、どのクラスが必要になるのか、そしてどのように相互作用するのかをどうやって知るのですか？ これが私の問題です。私はオブジェクト指向プログラミングの概念を理解していますが、オブジェクト指向システムの設計方法を理解していません。それらの概念は、私が知っている任意のオブジェクト指向プログラミング言語で使用できます。したがって、私には、私にとって意味のある方法でオブジェクト指向システムを設計するために使用できる単純なプロセスを説明してくれる人が必要です。

10 design  object-oriented 

インターフェース分離の原則は、クライアントが使用しないメソッドに依存することを強制されるべきではないことを示唆しているので、クライアントはそのインターフェースメソッドに空のメソッドを実装すべきではありません。 しかし、具体的な方法はどうですか？すべてのクライアントが使用するわけではない方法を分離する必要がありますか？次のクラスを考えてみましょう： 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 

私はオブジェクト指向プログラミングに不慣れで、メインの目的が何なのかわかりません。 はい、私はそれがプログラムの「入り口」であると読みましたが、私が理解していないことは、メインに何があるべきかです。そして、その責任は何ですか？ メインで記述された何かが別のオブジェクトにカプセル化される可能性がありますが、このアプローチをどの程度使用する必要がありますか？ これが私がJavaで書いた最初のメインです。非常にシンプルですが、私の疑問をよりよく理解してくれるかもしれません。「Cat」と「Dog」によって拡張された抽象クラスAnimalがあります。メインを使用してオブジェクトを作成し、ユーザーとの「インターフェース」としても使用しました。実際に、条件付きの指示を使用して、ユーザーが何をしたいかを「ユーザーに尋ねる」ことができます。 私の質問は、インターフェイスが別のオブジェクトにカプセル化され、メインにその責任を与えないという事実から生じました。 public static void main(String[] args) { Scanner input = new Scanner(System.in); System.out.println("What type of animal do you want to create? \n dog cat"); String type = input.nextLine(); if ( Objects.equals(type, "dog")){ System.out.println("Enter the animal's age: "); int age = input.nextInt(); // Scans the next token …

10 java  object-oriented  programming-practices  single-responsibility  entry-point 

Circleオブジェクトを作成できるライブラリを使用していて、円の半径と中心を指定してオブジェクトを定義できる状況を想像してみてください。ただし、何らかの理由で、必要なflavourパラメーターも受け取ります。ここCircleで、自分のアプリで本当に使用する必要があるとしましょう。ただし、アプリの目的で、フレーバーをFlavours.Cardboard毎回に設定できます。 この「解決」をするために、私は自分の作成Circleのみとり異なる名前空間でクラスをradiusし、centerパラメータとしてではなく、外部ライブラリのへの暗黙のコンバータがあるCircleだけで作成したクラスCircle(this.radius, this.center, Flavours.Cardboard)のオブジェクトを。したがって、他のタイプのが必要なすべての場所でCircle、自動変換を実行します。 そのようなクラスを作成するとどうなりますか？より良い解決策はありますか？私のアプリケーションが、この外部ライブラリの上に構築されたAPIであり、他のプログラマーが使用することを目的としていた場合、何か違いはありますか？

10 c#  object-oriented  constructors  parameters  type-conversion 

バックグラウンド 特定の種類のハードウェアデバイスの使用状況に依存するプロジェクトがありますが、必要なことを行うのであれば、誰がそのハードウェアデバイスを作成するかは重要ではありません。そうは言っても、同じことをするはずの2つのデバイスでも、同じ製造元以外のデバイスでは違いがあります。したがって、インターフェイスを使用して、関連するデバイスの特定のメーカー/モデルからアプリケーションを分離し、代わりに、インターフェイスに最高レベルの機能をカバーさせることを考えています。これが私のアーキテクチャが次のようになると私が考えているものです： 1つのC＃プロジェクトでインターフェイスを定義しますIDevice。 別のC＃プロジェクトで定義されたライブラリに、デバイスを表すために使用される具象があります。 具体的なデバイスにIDeviceインターフェースを実装してもらいます。 IDeviceインタフェースは次のような方法かもしれないGetMeasurementかをSetRange。 アプリケーションに具象に関する知識を持たせ、具象をデバイスを利用する（実装しない）アプリケーションコードに渡しIDeviceます。 アプリケーションに影響を与えずに、使用中のデバイスを変更できるため（これは時々発生するようです）、これが適切な方法であると確信しています。言い換えると、具象の実装方法GetMeasurementやSetRange具象を通して実際に機能する方法は重要ではありません（デバイスのメーカーによって異なる場合があります）。 私の心の中で唯一の疑問は、今やアプリケーションとデバイスの具象クラスの両方がIDeviceインターフェースを含むライブラリに依存しているということです。しかし、それは悪いことですか？ また、デバイスとIDevice同じ名前空間に属していない限り、アプリケーションがデバイスについて知る必要がない方法もわかりません。 質問 これは、アプリケーションとそれが使用するデバイスとの間の依存関係を切り離すためのインターフェースを実装するための正しいアプローチのように思えますか？

10 c#  design-patterns  object-oriented  interfaces  dependency-management 

おそらく多くの人と同じように、設計の問題が頭痛の種になっていることがよくあります。たとえば、問題に直感的に適合し、望ましい利点があるデザインパターン/アプローチがあります。多くの場合、何らかの回避策がないとパターン/アプローチを実装するのが困難になる警告があり、パターン/アプローチの利点が無効になります。多くのパターン/アプローチを繰り返し処理してしまう可能性があります。実際には、簡単な解決策がない実際の状況では、ほぼすべてのパターンに非常に大きな注意事項があるためです。 例： 最近遭遇した実際のものに大まかに基づいた架空の例を紹介します。継承階層が過去のコードのスケーラビリティを妨げていたため、継承ではなくコンポジションを使用したいとしましょう。私はコードをリファクタリングするかもしれませんが、スーパークラス/ベースクラスがサブクラスの機能を単に呼び出す必要があるにもかかわらず、それを回避しようとするいくつかのコンテキストがあることがわかりました。 次善のアプローチは、半分のデリゲート/オブザーバーパターンと半分の構成パターンを実装して、スーパークラスが動作を委任できるようにするか、サブクラスがスーパークラスのイベントを監視できるようにすることです。その場合、クラスを拡張する方法が不明確であるため、クラスの拡張性と保守性が低下します。また、既存のリスナー/デリゲートを拡張するのも難しいです。また、スーパークラスを拡張する方法を確認するために実装を知る必要があるため、情報は十分に隠されていません（コメントを非常に広範囲に使用しない限り）。 したがって、この後は、オブザーバーまたはデリゲートを完全に使用して、アプローチを過度に混同することに伴う欠点を回避することを選択する場合があります。ただし、これには独自の問題があります。たとえば、事実上すべての行動にオブザーバー/デリゲートが必要になるまで、行動の量を増やすためにオブザーバーまたはデリゲートが必要になることに気づく場合があります。1つのオプションは、すべての動作に対して1つの大きなリスナー/デリゲートを持つことですが、実装するクラスは多くの空のメソッドなどで終了します。 それから私は別のアプローチを試すかもしれませんが、それと同じくらい多くの問題があります。それから次のもの、そして次のものなど。 この反復プロセスは、各アプローチが他のアプローチと同じくらい多くの問題を抱えているように見え、一種の設計決定麻痺につながる場合、非常に難しくなります。また、使用する設計パターンやアプローチに関係なく、コードが同じように問題を抱えてしまうことを受け入れるのも困難です。このような状況になった場合、問題自体を再検討する必要があるということですか。この状況に遭遇したとき、他の人は何をしますか？ 編集： 私が明確にしたい質問のいくつかの解釈があるようです： OOPは実際にはOOPに固有のものではないことが判明したため、OOPについて質問から完全に除外しました。さらに、OOPについて渡した私のコメントの一部を誤解するのは簡単です。 反復的なアプローチでさまざまなパターンを試す必要があると主張したり、パターンが機能しなくなった場合は破棄したりする必要があると主張する人もいます。これは私が最初に参照するつもりだったプロセスです。これは例からは明らかだと思いましたが、もっと明確にすることができたので、そのために質問を編集しました。

10 design  design-patterns  object-oriented  refactoring  clean-code 

私には2つの基本クラスがOperationありTriggerます。それぞれに、特定のタイプの操作またはトリガーに特化したいくつかのサブクラスがあります。Aは、Trigger特定のトリガすることができますOperation。一方、Operation特定のによってトリガーできますTrigger。 特定のものOperationを特定のものにTrigger（またはその逆に）マップするコードを記述する必要がありますが、どこに配置するかわかりません。 この場合、コードは1つのクラスまたは他のクラスに明確に属していません。したがって、単一責任の原則に関しては、コードがどこに属すべきかわかりません。 私はすべてうまくいく3つのオプションを見ることができます。1と2は単なるセマンティクスの選択であるように見えますが、3は完全に異なるアプローチを表しています。 トリガー時、例えばbool Triggers(Operation o)。 操作について、例えばbool TriggeredBy(Trigger t)。 マッピングを管理するまったく新しいクラス、たとえばbool MappingExists(Trigger t, Operation o)。 単一の責任の原則に関して、共有マッピングコードを配置する場所をどのように決定すればよいですか？ 責任が共有されているときに単一の責任を管理するにはどうすればよいですか？ 編集1。 したがって、実際のコードは次のようになります。すべてのプロパティは、どちらかであるstring、Guid、collection<string>、またはenum。それらは基本的に小さなデータの一部を表すだけです。 編集2。 ブール型の戻り値の理由。別のクラスがのコレクションTriggerとのコレクションを使用しOperationます。との間のマッピングがどこにあるかを知る必要がTriggerありOperationます。その情報を使用してレポートを作成します。

10 object-oriented  single-responsibility 

Pythonが複数の継承を許可する場合、Pythonの慣用的な継承はどのように見えますか？ Javaのように単一継承の言語では、あるオブジェクトが別のオブジェクトの「is-a」であり、オブジェクト間でコードを共有したい場合（親オブジェクトから子オブジェクトまで）は、継承が使用されます。たとえば、それDogはAnimal： public class Animal {...} public class Dog extends Animal {...} しかし、Pythonは多重継承をサポートしているため、他の多くのオブジェクトを組み合わせてオブジェクトを作成できます。以下の例を検討してください。 class UserService(object): def validate_credentials(self, username, password): # validate the user credentials are correct pass class LoggingService(object): def log_error(self, error): # log an error pass class User(UserService, LoggingService): def __init__(self, username, password): self.username = username self.password = password …

10 object-oriented  python  inheritance  multiple-inheritance