問題タブ [ooad]

ソフトウェア開発における抽象化と情報隠蔽の違いは何ですか?

私は混乱しています。抽象化は、詳細な実装を隠し、情報を隠して、何かの詳細全体を抽象化します。

更新:これら 3 つの概念に対する適切な答えを見つけました。そこから取られたいくつかの引用については、以下の別の回答を参照してください。

サーバー側コードへの大量の jQuery JSON 呼び出しを含むアプリケーションがあります。このため、応答を解析して適切な値をフォームにバインドするためのバインド コードが大量にあります。これは 2 つの部分からなる質問です。

1. すべてが異なるデータを持つ多数のフォームを処理するための推奨されるアプローチは何ですか。現在、init、wireClickEvents などを使用して、各ページの js「クラス」を設定する際に構造化されたアプローチを取り、すべてを準拠させようとしています。

2. js ファイルに一連の関数を投げるだけでなく、反復的な jQuery コードや推奨される構造を作成する際の「ベスト プラクティス」はありますか?

カップリングと結束の概念を簡潔な定義に要約しようとしています。誰かが私に短くてわかりやすい説明をしてもらえますか (ウィキペディアのこことここの定義よりも短い)? 彼らはどのように相互作用しますか？

ありがとう。

誰かが良い、短い例を持っていますか?

C++ でstructa と aを使用する方がよいシナリオはどれですか?class

私はこのオブジェクト指向の設計の質問についてしばらく考えていましたが、満足のいく解決策を思い付くことができなかったので、ここの群衆にいくつかの意見を公開したいと思いました。

ターン制のボードゲームを表すゲームクラスがあります。この質問の目的では、モノポリーに似ていると想定できます。私のデザインには、TakeTurnメソッドを含むPlayerクラスがあります。

ゲームはすべてのプレイヤーをループし、TakeTurnメソッドを呼び出して、ターンを完了するために必要なすべてのことを行います。n人のプレイヤーがいて、任意の人数をコンピュータープレイヤーに設定できるようにしたいと思っています。ですから、私の考えは、HumanPlayerクラスとComputerPlayerクラスがあり、どちらもPlayerから派生しているということでした。

ゲームはPlayerクラスのみを認識し、各PlayerでTakeTurnメソッドを順番に呼び出すだけです。私の問題は、ComputerPlayerオブジェクトを完全に自動化できるという事実にあります。つまり、独占の例を維持すると、ロジックの一部を使用してプロパティを購入することを決定できます。ここで、HumanPlayerオブジェクトを使用すると、たとえばプロパティを購入できるようにするために、実際のユーザーから入力を取得する必要があります。これは、異なるインターフェイスを意味し、派生してはならないことを意味する可能性があります。

GameクラスにさまざまなPlayerクラスの実際の実装を明示的に知らない限り、問題の適切な解決策を思いつくことはできませんでした。ゲームクラスでは、人間とコンピューターのプレーヤーだけが存在し、拡張のために効果的に閉じると常に想定できましたが、オブジェクト指向プログラミングとしては適切ではないようです。

これについてのご意見をいただければ幸いです。

私はいつも、人々が CRC (クラス責任コラボレーション) カードをどのように使用しているのか疑問に思っていました。私はそれらについて本で読んだり、インターネットで漠然とした情報を見つけたりしましたが、それを本当に理解したことはありませんでした. 私の本の 1 つで、CRC カードを使用したセッションを示す YouTube ビデオを作成する必要があると思います。私の本の 1 つで、テキストで定式化するのは非常に難しいと説明されているため、「すでにマスターしている誰かに教えてもらう」必要があります。悲しいことに、私はここで CRC カードを使用している人を誰も知らないので、もっと知りたいと思っています。

アップデート

この手法を詳しく説明している人々を示すビデオへのリンクを歓迎します。

ILogin と呼ばれる汎用インターフェイスから始めました。インターフェイスでは、UserID と Password の 2 つのプロパティを実装する必要があります。このインターフェースを実装するログインタイプのクラスが多数あります。私のプロジェクトが大きくなるにつれて、多くのクラスが UserID と Password コードを繰り返していることに気付きました。ここで、ベース Login クラスが必要であると判断しました。

ILogin インターフェイスを実装する抽象基本ログイン クラスを作成し、すべての具象クラスを抽象クラスから継承し、必要に応じてオーバーライドすることは適切ですか? 当初はこれで問題ないと思っていました。それから、 ILogin はおそらく私の抽象クラスによってのみ実装される可能性が高いため、不要であると考え始めました。

抽象クラスとインターフェースの両方を維持する利点はありますか?

ありがとう！

これは、この質問のフォローアップ質問です。

次のような継承ツリーがあるとします。

これらのクラスごとにインターフェイスを定義することには利点がありますか？例：

おそらく他のクラス（のようなChevy）が実装したいと思うIcarかもしれませんし、おそらくそうIFordかもしれませんIMustangが、おそらくIMustangGTそれがそれほど具体的であるためではありません。この場合、インターフェースは不要ですか？

また、実装したいクラスは、コードが重複しないように、IFordから継承して1つの継承を使用したいと思うでしょう。Fordそれが与えられた場合、実装することの利点は何IFordですか？

私はかなり前からOOPを研究していて、理論をよく理解しています。私はOOPに関するHeadFirstの本を読みましたが、それは多くの理論を補強しましたが、ケーススタディはやや些細なものであることがわかりました。

私は毎日OOPの原則をコードに適用していることに気づきましたが、それらを正しく適用しているかどうかはわかりません。コードを見て、継承を適切に使用しているかどうか、オブジェクトが十分にまとまっているかどうかなどを知ることができるようになる必要があります。

確かなOOPスキルを開発するための次のステップを踏み出すための良い推奨事項（本、オンラインガイド、ブログ、ウォークスルーなど）はありますか？

私は主に.NET（ビジュアルベーシック）で作業していますが、さまざまなプラットフォームを組み込んだ提案を歓迎します。

簡単な例のコンテキストで質問をしようと思います...

抽象基本クラス Car があるとします。車には基本的なエンジン オブジェクトがあります。エンジンの始動を Engine オブジェクトに委譲する抽象 Car クラスに StartEngine() メソッドがあります。

Car のサブクラス (Ferrari など) が Engine オブジェクトを特定のタイプのエンジン (TurboEngine など) として宣言できるようにするにはどうすればよいですか? 別の Car クラス (TurboCar) が必要ですか?

単純な古い Engine オブジェクトを継承していますが、Car サブクラスでそれを TurboEngine として再宣言 (またはオーバーライド) することはできません。

編集: Engine の任意のサブクラスを Ferrari クラス内の myEngine 参照にプラグインできることは理解していますが、TurboEngine のみが公開するメソッドを呼び出すにはどうすればよいですか? myEngine はベース エンジンとして継承されるため、ターボ関連のものは含まれません。

ありがとう！