問題タブ [object-oriented-analysis]

オブジェクト指向設計では、次のうちどれが優れていますか?

次のようなメソッドでパラメーターを送信します。

または次のようなプロパティを使用します。

OODについての提案が必要です。以下は私の状況です。

非同期操作を起動するクラスがあり、非同期操作が返された後、非同期操作が MinTimeToWait 未満で返されたかどうかを確認する必要があります。そうであれば、MinTimeToWait が完了するのを待ってから、他の操作に進みます。

今、時間をチェックして SomeOperationCallback で待機するロジックを含めることで正しいことを行っていますか、またはロジックと StopWatch をカプセル化する新しいクラスを作成し、そのクラスを使用してこのチェックと待機を行う必要がありますか?

返信ありがとうございます。

たとえば、DataObjectタイプのJsonパーサークラスを次のように使用します。

今、私はJsonを取得するためにサーバーに接続する必要があるので、これがあります：

問題は、メインクラスで次のようにコーディングする方が良いということです（メソッド-A）

または、DataRetrieverを変更して、次のようにJson解析をinside（Method-B）に含めます。

結果はどちらの場合も同じですが、概念的には、Method-AまたはMethod-Bを使用してコーディングする方がよいでしょうか。

私は通常、メソッドAに従うコントローラークラスを作成しますが、これが効率的かどうかはわかりません。

編集：
実際、私はJsonを解析するときにGenericTypeとInterfaceを使用することを考えています。だから私は以下を用意しました：

次に、次のようにDataRetrieverのコンストラクターに追加します。

最終的には、複数のタイプのパーサーを許可して、毎回独自のパーサーを提供して柔軟性を追加できるようにすることを考えていました。これはある種の不正行為と見なされますか？

カプセル化されたクラスから、ラベルのように、カプセル化されたクラスがコンテキストを取得しようとしています。これを行う 1 つの方法は、以下に示すようにインスタンス化中のように、ラベルを渡すことです。

ロギング モジュールを使用すると、get_logger 関数を使用してサブログをサブスクライブできることを確認しましたが、get_context() 関数が必要です。これを行う方法はありますか？

このラベルの受け渡しが、下の YetAnotherClass のように 1 レベルになると、許容できるように見えますが、3 つまたは 4 つのレベルに渡す必要がある場合は、別のソリューションでこのラベルを渡したいと思っています。

これを別の方法で考えるべきでしょうか？コード例を次に示します。

クラスを持つと書かれている本があり、それから を継承PhoneNumberするクラスを定義します。私はかつて、アドレスは電話番号ではないため、継承することはできないと言いました。それは「である」関係でなければなりません。たとえば、犬は動物であり、から継承させることができます。AddressPhoneNumberDogAnimal

しかし、LSP -- Liskov Substitution Principleに従わなければならないので、正方形は "is a" 長方形 (幅 == 高さ) であるため、"is a" ルールは実際には決定要因ではありませんが、LSP はできると言います。クラスを定義し、そのSquareクラスから継承しRectangleます。aRect英語での簡単な説明は、オブジェクトはメッセージsetWidthAndHeight(w, h)に応答できますが、aSquare正しく応答できず、プログラム全体が正しく実行できないということだと思います。

驚くべきことに、Addressクラスを継承するPhoneNumberクラスは「is a」の関係に違反していますが、LSP には違反していません。正式には、どの OOP 原則に違反していますか?

私は新しいアプリケーションを構築していますが、この質問のどちらに進むべきか判断できません。

データベースのデータ指向クラスは、次のようなメソッドを使用してデータベースから構築する必要があります。

または、次のように、すべての SQL を処理してオブジェクトを構築するデータベース管理クラス / ファクトリを構築する必要があります。

私は以前に両方の方法でプロジェクトに取り組んだことがありますが、この新しいプロジェクトでどちらの方法を取るべきかを本当に決めることができず、今日の一般的なコンセンサスは何ですか?

どちらの方法にも長所と短所があることを意味しますが、これに関してより一般的に採用されているアプローチは何ですか? あなたが私に指摘できる確立されたパターンはありますか？

これから説明することを達成するための最善のオブジェクト指向の方法について意見を求めています。ゲームなどのイベントシステムになるものを書いていますが、抽象クラスが多いので、できるだけ拡張できるようにしたいと思っています。これらのうちの 2 つは、1 つのイベントを監視するために割り当てられたモニターと、イベントが発生した場合に呼び出される関数ポインターをラップするコールバックです。コールバックが必要とするデータを送信したいときに問題が発生します。送信されるデータは、(関数シグネチャに応じて) サブクラス固有になり、サブクラス化されたモニターに格納されます。実行を呼び出す前に、このデータをコールバックに渡すことができるようにしたいのですが、モニターの観点からはすべてが抽象的であるため、これは困難です。私' 可能な限り最高のオブジェクト指向の方法でこれを行う方法についての提案を探していますが、まだ私が好きなものを思い付いていません。コールバックは実際にディスパッチされるために別のクラスに送信されるため、データはある時点でそれらの内部に到達する必要があります。

参考までに、モニター抽象クラス

そしてコールバック抽象クラス

あらゆる意見/提案を歓迎します。ありがとう！

Java インターフェイスのソース コードにコメントを含める必要がありますか、それともインターフェイスを実装するクラスだけに含める必要がありますか (またはその両方)?

例：

ありがとう。

I am writing a server to handle different types of messages from client to host. The messages are of varying content and length and will be preceded by an identifier to identify what type the message is. Some messages (of type A, B, and C for instance) should just be forwarded between machines. Others (of type D, E, and F for instance) require a specific action from the server: ie. they are not just forwarded.

(NOTE: The clients on either end need to differentiate between A, B, and C but the server only needs to know to forward those messages. Both the server AND the clients need to be able to differentiate between D, E, and F.)

What I am trying to find is a good Object Oriented paradigm for representing the idea of what "type" a message is. So to clarify, imagine the server receives a messaged labeled as "Type B", it needs to simply forward that to the appropriate client. However, if it receives a message labeled as "Type F" it will take different, specific, action. So how could I represent the "Type" in my code?

An ideal solution for what I want to implement would be something like this; and enumeration "Type" in which a certain subset of Commands are of the type "Forwardable". Obviously that isn't possible so I thought of a static class, Forwardable, that inherits from a base static class, Type. Again, impossible. Interfaces could be possible, but I would really rather not have to instantiate instances just to interpret a type.

The most straight forward way of having the server parse the message would be something like this:

So finally, what is the proper OO way of representing a set of Types in which a subset of those Types is a Subtype?

EDIT: In a way, I feel like this should be done by defining a static class of "Types" and defining another static class that inherits from "Types" called "Forwardable". I can then cast what my server receives as a "Type" and say if(header is Forwardable). But unfortunately, you cannot inherit from static classes . . .

次のようなクラスがあるとしましょう。

したがって、メソッドAccessはそれ自体の型を取り、定義により、継承している限り、それが何であるかをあまり気にしない実装になりFooます...しかし、このメソッドに、渡されたオブジェクトがその実装と同じ型。

そのようです：

現在、渡されたものが現在のものと同じNameかどうかを示すフィールドがあります。さらに、ジェネリックを使用することも考えましたが、それがこの問題に対する正しいアプローチだとは思いません。foo.NameName

編集：

私が使用している実際の構造について少し背景を説明します。

上記Fooで定義されたクラスは、一連のオブジェクトを作成するファクトリを表しています。List<X> objsこれらのオブジェクトは、実装されたFooオブジェクトのプロパティによって生成されます。現在、これらのファクトリを比較する別のクラスがありますが、ファクトリがすべて生成されることで肥大化することは望んでいません。したがって、ファクトリを肥大化させる代わりに、実装が同じかどうかをチェックするだけです。実装が同じである場合は、抽象比較子によって定義されたプロパティを比較し、そうでない場合は吹き飛ばします。後で時間があれば追加します。

もっといいタイトルがあれば、おすすめを教えてください。