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

システムを、モジュール方式で制御および操作できるオブジェクトのセットとしてモデル化できるようにする方法論

3
多くの引数を持つコンストラクターの回避
だから私は異なるクラスのオブジェクトを作成するファクトリーを持っています。可能なクラスはすべて抽象祖先から派生しています。ファクトリーには構成ファイル（JSON構文）があり、ユーザーの構成に応じて、作成するクラスを決定します。 これを実現するために、ファクトリはJSON解析にboost :: property_treeを使用します。彼はptreeをウォークスルーし、どの具象オブジェクトを作成するかを決定します。 ただし、製品オブジェクトには多くのフィールド（属性）があります。具体的なクラスにもよりますが、オブジェクトには約5〜10個の属性があり、将来的にはさらに増える可能性があります。 そのため、オブジェクトのコンストラクターがどのように見えるかわかりません。私は2つの解決策を考えることができます： 1）製品のコンストラクターはすべての属性をパラメーターとして想定しているため、コンストラクターは最終的に10個以上のパラメーターになります。これは醜く、長くて読めないコード行につながります。ただし、利点は、ファクトリーがJSONを解析し、正しいパラメーターでコンストラクターを呼び出すことができることです。製品クラスは、JSON構成のために作成されたことを知る必要はありません。JSONや設定が含まれていることを知る必要はありません。 2）製品のコンストラクターは、property_treeオブジェクトという1つの引数のみを想定しています。次に、必要な情報を解析できます。構成内の情報が欠落しているか範囲外の場合、各製品クラスは適切に対応できます。ファクトリは、いくつかの製品に必要な引数を知る必要はありません。ファクトリーは、誤った構成の場合の対応方法を知る必要もありません。また、コンストラクターインターフェイスは統一されており、小さいです。ただし、デメリットとして、製品は必要な情報をJSONから抽出する必要があるため、JSONがどのように構成されているかを認識しています。 私は解決策2）を好む傾向があります。ただし、これが適切なファクトリパターンであるかどうかはわかりません。JSON構成で作成されていることを製品に通知するのは、どういうわけか間違っていると感じます。一方、新製品は非常に簡単に導入できます。 それについての意見はありますか？
2
Javaで入力を取得するためにスキャナークラスのインスタンスが必要なのはなぜですか？
Javaはオブジェクト指向ですが、入力を得るためにスキャナークラスからオブジェクトを作成する必要があるのはなぜですか？next()たとえば、メソッドを静的にすることはできませんか？ Cは、あなたがscanf()、gets()またはを使用するだけなので、かなりシンプルに見えますfgets()。Java開発者がScannerクラスを作成する理由は確かにありますが、通常の関数を使用するだけで作業を行うよりもどのように優れているのでしょうか。 同じ質問をしているように見えるかもしれないこのリンクを見つけましたが、答えはちょうど約です 「静的ではないため、オブジェクトを作成する必要があります」... 私の推測では、Javaはオブジェクト指向であるため、すべてのインプットメソッドをクラスに入れることにしました。それらは静的メソッドを実行しなかったので、さまざまなオブジェクトにあらゆる種類のさまざまなソース（キーボード入力、ファイル入力...）を含めることができますか？ 誰かが質問を編集して、より明確に聞こえるようにしていただければ幸いです！
3
継承：スーパークラスからのコードは実質的にサブクラスに「コピー」されますか、それともサブクラスによって参照されますか？
Class SubはclassのサブクラスですSup。それは実際にはどういう意味ですか？言い換えれば、「継承」の実際的な意味は何ですか？ オプション1： Supのコードが仮想的にSubにコピーされます。（ 'copy-paste'と同じですが、コピーされたコードがサブクラスで視覚的に表示されていません）。 例：methodA()はもともとSupにあったメソッドです。SubはSupを拡張するのでmethodA()、（事実上）Subにコピーペーストされます。これで、Subにはという名前のメソッドがありmethodA()ます。コードのすべての行でSupと同じですmethodA()が、完全にSubに属しており、Supに依存していないか、何らかの方法でSupに関連しています。 オプション2： Supからのコードは実際にはSub にコピーされません。それはまだスーパークラスだけにあります。ただし、そのコードはサブクラスを介してアクセスでき、サブクラスで使用できます。 例：methodA()は、Supのメソッドです。SubはSupを拡張するのでmethodA()、Subから次のようにアクセスできますsubInstance.methodA()。しかし、実際methodA()にはスーパークラスで呼び出されます。つまり、methodA（）は、サブクラスによって呼び出された場合でも、スーパークラスのコンテキストで動作します。 質問：2つのオプションのどちらが実際に機能するのですか？どれもない場合は、これらが実際にどのように機能するかを説明してください。
4
疎結合設計を作成するためにどれだけの労力を費やす必要がありますか？
現在、デザインパターンについて学習しています。 ほとんどの人はこれらのパターンが優れたツールであることに同意するだろうと思いますが、すべての答えとしてではなく、適度に使用する必要があります。これらを使いすぎると、アプリケーションが過度に複雑になり、ほとんどメリットがありません。パターンは、それらが最良のソリューションになるか、優れたソリューションの作成に役立つ場合にのみ使用する必要があります（同意しますか？）。 これを考慮して： 私が読んでいる本（Head First Design Patterns）は、疎結合の重要性を強調しています。この疎結合は、「実装ではなくインターフェイスへのプログラム」や「変化するものをカプセル化する」などの原則に従って達成されます。 基本的に、これまでに学んだほとんどのパターンは、デザインを疎結合にして、より柔軟にするために存在します。 疎結合の重要性と利点を理解しています。 しかし、私の質問は、疎結合で柔軟な設計を作成するために実際にどれだけの労力を費やすべきかということです。 設計パターンに反対する人々は、これらのパターンを使用するコストが利益を上回ることが多いと言います。いくつかのパターンを使用して疎結合設計を作成することに多くの時間を費やしますが、実際には、疎結合、「実装ではなくインターフェイスへのプログラミング」、およびこれらの原則のすべては、実際にはそれほど重要ではない可能性があります。 私が知りたいのは、抽象化とデザインの追加レベルを作成するために実際にどのくらいの努力を払うべきかということです。これは、アプリケーションが疎結合、インターフェイスへのプログラム機能などのオブジェクト指向の原則に従うことを許可するためだけです。それは本当に価値がありますかそれ？これにはどのくらいの努力が必要ですか？
12
「メソッドを変更せずに再利用する場合は、メソッドを基本クラスに配置し、それ以外の場合はインターフェースを作成する」というのは良い経験則ですか？
私の同僚は、基本クラスとインターフェイスのどちらを作成するかを選択するための経験則を考え出しました。 彼は言う： 実装しようとしているすべての新しいメソッドを想像してみてください。それらのそれぞれについて、このことを考慮してください。この方法は、内の複数のクラスによって実装されます正確にせずに、このフォームの任意の変化？答えが「はい」の場合は、基本クラスを作成します。他のすべての状況では、インターフェースを作成します。 例えば： クラスを検討catしてdogクラスを拡張し、mammal単一の方法を持っているがpet()。次に、alligator何も拡張せず、1つのメソッドを持つクラスを追加しslither()ます。 次に、eat()それらすべてにメソッドを追加します。 実装した場合eat()の方法は、のためにまったく同じになりcat、dogそしてalligator、私たちは、基本クラス（LETだと言う、作成する必要がありanimal、このメソッドを実装します）。 ただし、実装がalligator少しでも異なる場合は、IEatインターフェースを作成して作成mammalおよびalligator実装する必要があります。 彼はこの方法がすべてのケースをカバーすると主張しますが、私には過度に単純化しているようです。 この経験則に従う価値はありますか？
3
RubyおよびC ++のOOP用語
私は学校でC ++クラスを受講しています。Rubyでプログラミングしたので、いくつかのOOPのことを知っています。 しかし、C ++には、メンバー関数、メンバー変数、および静的関数があります。Rubyには、インスタンスメソッド、インスタンス変数、クラス変数があります。そして、もっとあります... それらが異なる理由は何ですか？それらはOOPのかなり異なるレベルですか？それとも、これらの生態系の伝統の違いだけですか？
4
応答を処理するためのデザインパターン
ほとんどの場合、特定の関数呼び出しの応答を処理するコードを書いているとき、次のコード構造が得られます。 例：これはログインシステムの認証を処理する関数です class Authentication{ function login(){ //This function is called from my Controller $result=$this->authenticate($username,$password); if($result=='wrong password'){ //increase the login trials counter //send mail to admin //store visitor ip }else if($result=='wrong username'){ //increase the login trials counter //do other stuff }else if($result=='login trials exceeded') //do some stuff }else if($result=='banned ip'){ //do …
2
PHPでクラスメンバーを初期化するためのベストプラクティス
私のコンストラクタには次のようなコードがたくさんあります：- function __construct($params) { $this->property = isset($params['property']) ? $params['property'] : default_val; } プロパティ定義でデフォルト値を指定するよりも、これを行う方が良いですか？すなわちpublic $property = default_val？時々、デフォルト値のロジックがあり、いくつかのデフォルト値は他のプロパティから取得されるため、コンストラクターでこれを行っていました。 デフォルト値のすべてのロジックが分離されるようにセッターを使用する必要がありますか？
3
メソッドのオーバーロードはいつ適切ですか？
既存のかなり大きなシステムで作業しているとしましょう。myObjectクラスのオブジェクトがありますMyClass（例として、Javaで作業しているとします）。myObjectはCollection、たとえばa Listと、（私が思うに）無関係な他のオブジェクトを含むコンポジションです。これには、Listそれが構成されているメソッドを呼び出す役割を果たしているデリゲートメソッドが含まれていますList。 これListがaであるとしましょう。List<String>何らかの理由で、メインのアクセスメソッドはclassのマスクメソッドですSomeOtherClass。新しい値のペアをmyに挿入しListたい場合は、SomeOtherClass呼び出されたオブジェクトがありますsomeObject。私が呼び出すmyObject.insert(someObject)と、insertメソッド内にを取得してStringに入れる魔法がいくつかありますList<String>。 今、String値しか持っておらずSomeOtherClass、挿入するオブジェクトがないとします。insertこのシステムのすべてを破壊するため、メソッドを変更できないと仮定します。次に、insertメソッドをオーバーロードする必要がありますか？またはSomeOtherClass呼び出すたびに新しいオブジェクトを作成する必要がありますinsertか？ オーバーロードするとこんな感じになりますね… public void insert(String s) { ... } public void insert(SomeOtherObject obj) { this.insert(obj.magicStringMethod()); } （この例は、昨日発生したオーバーロードに関する同様の（やや複雑な）状況に基づいた不自然なパズルです。不明な点がある場合は展開します） これはメソッドをオーバーロードするのに適切な場所でしょうか？そうでない場合、いつメソッドをオーバーロードする必要がありますか？
3
重複したコードを削除する方法（一般的に）？
オブジェクト指向言語（たとえば、Javaに限定されません）では、発生の範囲に応じて重複コードをどのように修正しますか？（例えば）から始めます 同じクラス（スコープ）でExtractメソッドのリファクタリングを実行（修正） 同じ階層のクラス（スコープ）でメソッドの抽出とプルアップを実行（修正） ...
4
オブジェクトの境界を越えて流出する情報
多くの場合、私のビジネスオブジェクトは、情報がオブジェクトの境界を頻繁に越える必要がある状況にあります。オブジェクト指向を実行するときは、情報を1つのオブジェクトに入れ、その情報を処理するすべてのコードをできるだけそのオブジェクトに含める必要があります。ただし、ビジネスルールはこの原則に従っていないため、問題が発生します。 例として、価格を持つInventoryItemを参照するOrderItemの数を持つOrderがあるとします。数量をInventoryItem.GetPrice（）で乗算するOrderItem.GetPrice（）の結果を合計するOrder.GetTotal（）を呼び出します。ここまでは順調ですね。 しかし、その後、一部の商品が2対1で販売されていることがわかりました。OrderItem.GetPrice（）にInventoryItem.GetPrice（quantity）のような処理を行わせ、InventoryItemにこれを処理させることで、これを処理できます。 ただし、2対1の取引は特定の期間のみ続くことがわかります。この期間は、注文の日付に基づく必要があります。次にOrderItem.GetPrice（）をInventoryItem.GetPrice（quatity、order.GetDate（））に変更します。 ただし、お客様がシステムに滞在している期間に応じて、さまざまな価格をサポートする必要があります。 しかし、2対1の取引は、同じ在庫アイテムを複数購入するだけでなく、InventoryCategory内のアイテムの複数購入にも適用されることがわかります。この時点で、私たちは手を挙げて、InventoryItemに注文アイテムを与え、それがアクセサーを介してオブジェクト参照グラフ上を移動できるようにし、必要な情報を取得します：InventoryItem.GetPrice（this） TL; DRオブジェクトの結合を低くしたいのですが、ビジネスルールでは、特定の決定を行うために、多くの場合、どこからでも情報にアクセスする必要があります。 これに対処するための良いテクニックはありますか？他の人が同じ問題を見つけますか？
4
ドメイン駆動設計でのリファクタリング[終了]
休業。この質問には詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善してみませんか？詳細を追加し、この投稿を編集して問題を明確にしてください。 6年前休業。 私はプロジェクトに取り組み始めたばかりであり、ドメイン駆動設計（Eric Evansが定義するDomain-Driven Design：Tackling Complexity in the Heart of Software）を使用しています。私たちのプロジェクトは確かにこの設計の候補だと思いますエヴァンスが彼の本でそれを説明するパターン。 私は絶えずリファクタリングするという考えに苦労しています。 私は、どのプロジェクトでもリファクタリングが必要であり、ソフトウェアの変更に伴って必然的に起こることを知っています。ただし、私の経験では、リファクタリングは、ドメイン変更の理解としてではなく、開発チームのニーズが変化したときに発生します（Evansが言うように、「より深い洞察へのリファクタリング」）。私は、ドメインモデルの理解におけるブレークスルーに最も関心があります。小さな変更を加えることは理解していますが、モデルに大きな変更が必要な場合はどうなりますか？ より明確なドメインモデルを取得した後、リファクタリングする必要がある自分（および他の人）を説得する効果的な方法は何ですか？結局のところ、コードの編成またはパフォーマンスを改善するためのリファクタリングは、ユビキタス言語コードの観点から表現力を高めることとはまったく別のものである可能性があります。時々、リファクタリングするのに十分な時間がないように思えます。 幸いにも、SCRUMはそれをリファクタリングに役立てます。SCRUMの反復的な性質により、小さなピースを作成し、それを変更することが容易になります。しかし、時間の経過とともにそのピースは大きくなり、そのピースが大きくなりすぎて変更が困難になるとしたらどうでしょうか。 ドメイン駆動設計を採用するプロジェクトに取り組んだ人はいますか？もしそうなら、これについていくつかの洞察を得ることは素晴らしいでしょう。DDDを正しく理解するのは非常に難しいため、私は特にいくつかの成功事例を聞きたいと思います。 ありがとう！
4
大きなテンプレートの実装を処理するC ++推奨の方法
通常、C ++クラスを宣言する場合は、宣言のみをヘッダーファイルに配置し、実装をソースファイルに配置することをお勧めします。ただし、このデザインモデルはテンプレートクラスでは機能しないようです。 オンラインで見ると、テンプレートクラスを管理する最良の方法について2つの意見があるようです。 1.宣言とヘッダーの実装全体。 これはかなり簡単ですが、私の意見では、テンプレートが大きくなるとコードファイルを保守および編集することが困難になります。 2.最後にインクルードするテンプレートインクルードファイル（.tpp）に実装を記述します。 これは私にはより良い解決策のようですが、広く適用されているようには見えません。このアプローチが劣っている理由はありますか？ 多くの場合、コードのスタイルは個人の好みやレガシースタイルによって決定されます。私は新しいプロジェクト（古いCプロジェクトをC ++に移植）を開始しており、OO設計は比較的初心者なので、最初からベストプラクティスに従いたいと考えています。
5
実世界の値を表す定数を更新することは、開閉原理の違反ですか？
私は労働者の純年収を計算するクラスを持っています。税率を表す定数があります。しかし、ある日、税率が変更されたため、コードを修正する必要があります。 この定数を修正する行為は、クラスを変更して閉じる必要があると仮定しているため、Open-Closed Principleの違反を示していますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.