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

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

2
ゲッターのみのインターフェースはコードの匂いですか？
（私はこの質問を見ましたが、最初の答えはデザインよりも自動プロパティに関するもので、2番目の答えは、データストレージコードをコンシューマから隠すことです。これは、自分のコードが何をしたいのかわからないのですが、他の意見も聞きたいです） 私には2つの非常に類似したエンティティがHolidayDiscountありRentalDiscount、「それが少なくとも続く場合numberOfDays、percent割引が適用される」として長さ割引を表します。テーブルにはさまざまな親エンティティへのアクセス権があり、さまざまな場所で使用されますが、それらが使用される場所には、適用可能な最大の割引を取得するための共通のロジックがあります。たとえば、aにHolidayOfferはの数がありHolidayDiscounts、そのコストを計算するときは、該当する割引を計算する必要があります。レンタルと同じですRentalDiscounts。 ロジックは同じなので一箇所に留めておきたい。これが、次のメソッド、述語、およびコンパレータが行うことです。 Optional<LengthDiscount> getMaxApplicableLengthDiscount(List<LengthDiscount> discounts, int daysToStay) { if (discounts.isEmpty()) { return Optional.empty(); } return discounts.stream() .filter(new DiscountIsApplicablePredicate(daysToStay)) .max(new DiscountMinDaysComparator()); } public class DiscountIsApplicablePredicate implements Predicate<LengthDiscount> { private final long daysToStay; public DiscountIsApplicablePredicate(long daysToStay) { this.daysToStay = daysToStay; } @Override public boolean test(LengthDiscount discount) { return daysToStay >= discount.getNumberOfDays(); …
3
オブジェクト初期化子でビルダーと流体インターフェースを使用することに意味がありますか？
JavaおよびC＃では、パラメーターを使用してコンストラクターを定義するか、オブジェクトの作成後に各プロパティを定義するか、ビルダー/流体インターフェイスパターンを使用して、初期化時に設定できるプロパティを持つオブジェクトを作成できます。ただし、C＃3ではオブジェクトとコレクションの初期化子が導入されたため、ビルダーパターンはほとんど役に立たなかった。イニシャライザのない言語では、ビルダーを実装して次のように使用できます。 Vehicle v = new Vehicle.Builder() .manufacturer("Toyota") .model("Camry") .year(1997) .colour(CarColours.Red) .addSpecialFeature(new Feature.CDPlayer()) .addSpecialFeature(new Feature.SeatWarmer(4)) .build(); 逆に、C＃では次のように記述できます。 var vehicle = new Vehicle { Manufacturer = "Toyota", Model = "Camry", Year = 1997, Colour = CarColours.Red, SpecialFeatures = new List<SpecialFeature> { new Feature.CDPlayer(), new Feature.SeatWarmer { Seats = 4 } } } …
4
抽象クラスの一般的な名前を避ける方法は？
一般に、ファイルハンドルやUNIXプロセスなどを扱っていない限り、ルーチン名やクラス名の一部として「ハンドル」や「プロセス」などの単語を使用しないことをお勧めします。しかし、抽象クラスは、処理などの他に何かをどうしようとしているのか、実際には分からないことがよくあります。私の現在の状況では、ユーザーの受信ボックスにログインして、そこからのメッセージを処理する「EmailProcessor」があります。次のスタイルの問題が発生することに気づきましたが、これをより正確な名前にする方法は本当にわかりません。 派生クラスをクライアントとして扱い、実装する機能の一部によって基本クラスに名前を付けた方が良いですか？より意味を与えますが、is-aに違反します。たとえば、EmailAcquirerは、派生クラスのために取得しているため、適切な名前になりますが、派生クラスは誰のためにも取得しません。 あるいは、派生クラスが何をするのか誰が知っているので、本当にあいまいな名前です。ただし、「Processor」は、ログインやIMAPの使用など、関連する多くの操作を実行しているため、まだ一般的すぎます。 このジレンマから抜け出す方法はありますか？ 問題は、「これは何をするのか」という質問に実際に答えることができない抽象メソッドの場合により明白になります。答えは単に「クライアントが望むものは何でも」だからです。
9
グローバルが理にかなっているとしたら？
多くのオブジェクトに必要な値を持っています。たとえば、オブジェクトとしてさまざまな投資を行う金融アプリケーションで、それらのほとんどは現在の金利を必要とします。 金利をプロパティとして、「金融環境」をオブジェクトとしてカプセル化したいと思っていました。しかし、その値を必要とする兄弟オブジェクトはそれに到達できません。 では、デザインを過度に結合せずに、多くのオブジェクト間で値を共有するにはどうすればよいですか？明らかに、これは間違っていると考えています。
9
オブジェクトをコンストラクターに渡すか、クラスでインスタンス化する必要がありますか？
次の2つの例を検討してください。 オブジェクトをコンストラクターに渡す class ExampleA { private $config; public function __construct($config) { $this->config = $config; } } $config = new Config; $exampleA = new ExampleA($config); クラスのインスタンス化 class ExampleB { private $config; public function __construct() { $this->config = new Config; } } $exampleA = new ExampleA(); プロパティとしてのオブジェクトの追加を処理する正しい方法はどれですか？いつどちらを使用すればよいですか？単体テストは私が使用するべきものに影響しますか？
2
単一の関数を再利用するためだけにクラスを拡張するのは合理的な方法ですか？
私はワードプレスサイト用にさまざまな投稿フィルターを開発しており、最初の4つを単一のクラスで構築しました。 最後の2つはスコープが十分に異なるため、クラス内で1つの関数（最終リンクを生成するための関数）のみを共有します。 このインスタンスまたはいくつかの類似の仮想インスタンスのいずれかで、その機能を実現するために元のクラスを拡張することは合理的ですか、それともより良い方法がありますか？
12
オブジェクト指向プログラミングを学ぶ前に、手続き型プログラミングを学ぶ必要があるのはなぜですか？[終了]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 私は現在、IT大学で4年生です。このトピックについて教授と話すと、彼は私の意見を拒否し、非常に厳しい批判を与えます（私の大学では、C（ANSI）（Proceduralプログラミングクラス-大学1年目）C ++の前（2年目のOOPクラス）など... しかし、13歳のとき、私の弟はJavaを最初に教えられ、他には何も教えられませんでした。現在、彼は通常の2年生がJavaでできることのほとんどすべてを行うことができます。 プロの皆さんには、手続き型プログラミングを最初に教えるべきだと思う理由を教えてください。
12
OOPの概念を非技術者に説明する方法は？
ロックされています。この質問とトピックへの回答はロックされています。質問はトピックから外れていますが、歴史的に重要です。現在、新しい回答や相互作用を受け入れていません。 たいていの場合、プログラマーであることを他人に言わないようにします。ほとんどの場合、最終的にそれが何を意味するのかを説明してしまうからです。私がJavaでプログラミングをしていると彼らに話すと、彼らは言語に関する一般的な質問をし、それがxやyとどのように異なるかをよく尋ねます。私はまた、1）現場での経験があまりなく、2）技術者以外の人に説明するのが本当に嫌なので、説明が得意ではありません。 他の人に説明したら、本当に理解していると彼らは言っています。この場合、OOPの用語と概念を非技術者にどのように説明しますか？
3
合計タイプとポリモーフィズム
昨年、私は飛躍して関数型プログラミング言語（F＃）を学びました。私が発見した興味深い点の1つは、OOソフトウェアの設計方法にどのように影響するかです。私がオブジェクト指向言語で最も欠けていると思うのは、パターンマッチングと合計タイプの2つです。どこを見ても、差別的な組合で簡単にモデル化される状況が見られますが、パラダイムに不自然に感じられる一部のOO DU実装でバールを表示することに抵抗があります。 これにより、通常or、合計タイプが処理する関係を処理する中間タイプを作成するようになります。また、かなりの分岐につながるようです。Misko Heveryのような人を読んだ場合、優れたOOデザインは多態性による分岐を最小限に抑えることができると彼は示唆しています。 OOコードでできる限り避けたいことの1つは、null値を持つ型です。明らかに、or関係は1つのnull値と1つの非null値を持つタイプによってモデル化できますが、これはnullあらゆる場所でのテストを意味します。異種であるが論理的に関連付けられた型を多態的にモデル化する方法はありますか？設計戦略やパターンは非常に役立つでしょう。あるいは、一般的にオブジェクト指向のパラダイムで、異種の関連タイプについて考える方法です。
1
クラスへのデータ処理ロジックの注入
よりエレガントで、プロセッサをCommandProcessorDispatcherクラスに注入する方法を見つけたいです。または、別のソリューションにすることもできます（目標は、各コマンド処理ロジックを独立したクラスに分離することです）。たぶん、ここでいくつかのデザインパターンが役立ちます。 public interface ICommand { } public class StartCommand : ICommand { } public class StopCommand : ICommand { } public interface ICommandProcessor<in T> where T : ICommand { void Process(T command); } public class StartCommandProcessor : ICommandProcessor<StartCommand> { public void Process(StartCommand command) { } } public class StopCommandProcessor : …
2
依存関係の逆転の原則：低レベルコンポーネントと高レベルコンポーネントの両方が抽象化にどのように依存するかを理解する
依存関係の逆転の原理について学習しています。それはそれを述べています： 高レベルのモジュールは、低レベルのモジュールに依存するべきではありません。どちらも抽象化に依存する必要があります。 しばらく、私はそれが高レベルのコンポーネントと低レベルのコンポーネントの両方が抽象に依存し、それらに依存していることの意味を理解しようとしました。 どちらも同じ抽象化に何らかの形で依存する必要があると思います。これが間違っている場合は修正してください。 私はこれが何を意味するかについていくつかの結論に達しています。これが正しいかどうか確認してください。 「高レベルのコンポーネントは抽象化に依存しています」-意味： 高レベルコンポーネントは、具体的な低レベルコンポーネントと直接通信するのではなく、低レベルコンポーネントと通信するためにインターフェースと通信します。低レベルのコンポーネントはこのインターフェースを実装します。 「低レベルのコンポーネントは抽象化に依存しています」-意味： 低レベルのコンポーネントは、インターフェースの観点から定義および設計されています。それらはインターフェイスに合うように設計されています。それらは、インターフェースがそれらの設計方法を定義する方法で、インターフェースに依存しています。（多くの場合、低レベルのクラスがそのインターフェースを実装しています）。 このように、高レベルのコンポーネントと低レベルのコンポーネントはどちらも「抽象化に依存」していますが、方法は異なります。 これはよく理解していますか？
4
メソッドの名前を変更してもカプセル化を維持できますか？
ゲッター/セッターが正当化される時期についてこのページを読んでいましたが、OPは次のコードサンプルを提供しました。 class Fridge { int cheese; void set_cheese(int _cheese) { cheese = _cheese; } int get_cheese() { return cheese; } } void go_shopping(Fridge fridge) { fridge.set_cheese(fridge.get_cheese() + 5); } 受け入れ答えの状態： ちなみに、あなたの例ではFridge、putCheese()andのtakeCheese()代わりに、クラスに and メソッドを指定get_cheese() しset_cheese()ます。その後、まだカプセル化されています。 カプセル化は、名前をget / setからputCheese()/に変更することによってどのように保持さtakeCheese()れますか？ 同じ答えでそれはまた述べています： ゲッターとセッターを使用しても、カプセル化が壊れることはありません。カプセル化を解除するのは、何も考えずに、すべてのデータメンバー（Java lingoのすべてのフィールド）にゲッターとセッターを自動的に追加することです。 この場合、変数は1つだけなのでcheese、チーズを取り出して冷蔵庫に戻したい場合があるため、この場合の取得/設定ペアは正当化されます。
6
オブジェクトが可変である場合、関数型プログラミングのコンテキストで何が問題になる可能性がありますか？
不変オブジェクトのような可変オブジェクトと不変オブジェクトの利点は、共有および書き込み可能な状態が原因で、マルチスレッドプログラミングの問題のトラブルシューティングが非常に困難になることを理解できます。逆に、変更可能なオブジェクトは、毎回新しいコピーを作成するのではなく、オブジェクトのIDを処理するのに役立ちます。そのため、特に大きなオブジェクトのパフォーマンスとメモリ使用量も向上します。 私が理解しようとしていることの1つは、関数型プログラミングのコンテキストで可変オブジェクトを使用すると何が問題になるのかということです。私に言われたポイントの1つのように、異なる順序で関数を呼び出した結果は確定的ではありません。 関数プログラミングで可変オブジェクトを使用すると何がうまくいかないかが非常に明白な実際の具体例を探しています。基本的にそれが悪いのであれば、オブジェクト指向や関数型プログラミングのパラダイムに関係なく悪いのですよね？ 私自身の声明自体がこの質問に答えると思います。それでももっと自然に感じられるように、いくつかの例が必要です。 OOは、カプセル化、ポリモーフィズムなどのツールを使用して、依存関係を管理し、より簡単で保守可能なプログラムを作成するのに役立ちます。 関数型プログラミングも、保守可能なコードを促進する同じ動機がありますが、OOツールとテクニックを使用する必要性を排除するスタイルを使用しています。
7
ウィザードとウォリアーのルールを回避する
でブログ記事のこのシリーズ、エリックリッペルトは、ウィザードとの例として、戦士を使用して、オブジェクト指向設計における問題点を説明します。 abstract class Weapon { } sealed class Staff : Weapon { } sealed class Sword : Weapon { } abstract class Player { public Weapon Weapon { get; set; } } sealed class Wizard : Player { } sealed class Warrior : Player { } 次に、いくつかのルールを追加します。 戦士は剣しか使用できません。 ウィザードはスタッフのみを使用できます。 次に、C＃型システムを使用してこれらのルールを適用しようとすると発生する問題（たとえばWizard、ウィザードがスタッフのみを使用できることをクラスに責任を持たせるなど）を示します。Liskov置換原則に違反したり、ランタイム例外のリスクを冒したり、拡張が困難なコードを作成したりする。 …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.