初心者のための緩やかなカップリングとオブジェクト指向のプラクティス

Question

クラスを疎結合することは、理解しやすく、変更し、デバッグしやすいコードを書く重要な側面です。しかし、初心者でも、私が苦労している最も簡単な例を超えて、いつでもいつでも。

文字列、整数、および単純なデータ型を独自のクラスでカプセル化する方法は多かれ少なかれ理解しています。しかし、リッチテキストフォーマットのような情報を扱うときは、コンポーネントにすでに存在するさまざまなメソッドを使用していない限り、実際には複雑になります。この例を続行するには、UIにRTFメモコンポーネントを含むものを記述していたとします。 Delphiでは、コンポーネントには書式設定されたテキストを保存するなどの作業を行うための組み込みメソッドがあります。さらに、RTFテキスト自体を操作する唯一の（または少なくとも最善の）方法は、コンポーネントに組み込まれたメソッドを使用しているように見えることがあります。

テキストを保存、読み込み、書式設定するためのテキストを別のクラスに作成するにはどうすればよいですか？

私自身は、通常、（a）必要以上に複雑に思えるものを実行したり、すでに存在しているメソッドを再開発したり、（b）まだ密接に結合しているクラスを作成したりしないでください。彼らが情報広告で言うように、「もっと良い方法が必要です」

「より良い方法」がどのように機能しているか、概念的には分かりません。何かご意見は？

Answer 1

私はあなたがいくつかの基本的な概念を見逃していると思います。

OOPの背後にある考え方は、離散的で再利用可能な論理単位で始まります。自己充足型モジュールの作成に重点を置いています。

RTFメモコンポーネントの場合、プログラム内の他のオブジェクトがどのように影響を受けないように、指定されたデータセット（メモ）を処理することによって、上記の基準を満たしますジョブ。インターフェイスを表示し、データを受け入れ、その特定のデータを操作し、そのデータをプログラムの別の部分に渡すことが目的です。

loosely coupledの背後にあるアイデアは、単にそのメモコントロールを同じインターフェイス仕様を満たす別のコントロールに置き換えることができます。つまり、インスタンス化してユーザーが操作できるようにし、必要に応じてデータを取り出すことができます。

ゆるく結合されているという考えは、Separation of Concerns（SoC）のアイデアを手にしています。重複する機能を減らして管理しやすくするために、プログラムを別の機能に分割するプロセスです。しかし、彼らは同じことではありません。事実、これはプログラミングの手続きスタイルからOOPに移行する主な要因の1つです。 OOPとして、プログラミングは関連した機能と離散的な機能の点で考えるべきである。

実際にSoCについて質問しているようです。

SoCを実現する方法はたくさんあります。 UI、処理ロジック、パーシスタンスレイヤーを分離した状態に保つことが必要な場合があります（MVCデザインパターンなど）。複雑さを軽減するために単に関連する機能をまとめているだけの場合もあります。 RTFコントロールはデータを操作するために必要なすべての関数を含んでいるため、すでに依存関係はありません。

Answer 2

この質問では完全にはっきりしていませんが、ここでは戦略パターンがうまくいくようです。

親RTFオブジェクトに基づいてオブジェクトを作成しますが、独自のメソッドで定義済みオブジェクトとして保存するなどの処理方法を設定します。

これにより、すべての親メソッドを厳密に継承することなく、構成の力が可能になり、巨大なカスタムオブジェクトを構築する必要はなく、必要なメソッドを置き換えるだけです。

Answer 3

クラスをデカップリングする方法として、インタフェースと依存性注入の2つの概念をお勧めします。インタフェースは、実装とは独立した一連の期待動作を定義する方法を提供します。クラスをクラスではなくインターフェイスに依存させると、そのクラスに依存するクラスを書き直すことなく、そのインターフェイスを実装する他のクラスを置き換えることができます。

依存関係注入を使用するインターフェイスを使用する場合、つまり、独自の特定の実装を作成するのではなく、実際に実装するクラスをクラスに与えると、アプリケーションでさらにデカップリングが達成されます。今、クラスはインターフェイスについてしか知りませんし、インターフェイスを作成する方法も知らず、使用するだけです。依存関係注入は、ビルダーやファクトリなどの作成パターンでよく使用されます。ここでは、単一クラスのオブジェクトの構築をローカライズして、クラスを追加してアプリケーションを拡張するときにそのクラスだけを変更する必要があります。

また、結合（および双子、凝集）は相対的な尺度であることに注意してください。あなたはすべてのカップリングを排除することはできませんまたはあなたのオブジェクトは、相互作用することはできません。依存度をある程度保つことが必要です。使いやすさと実装のバランスをとる必要があります。

具体的な例として、実際のコードなしでは分かりにくいです。私は、あなたがソリューションを過剰に設計していてDRYの原則に違反していると思われます（繰り返しません）。インターフェイスを使用する方法や、フレームワークコンポーネントからクラスを完全に再実装するのではなく、軽量ラッパーを使用する方法を検討する必要があります。

Answer 4

あなたが選んだ例はかなり複雑です。

rtfメモコンポーネントが非常に疎結合していると言うと、あなたは正しいです。とてもゆるやかに、実際には拡張可能ではなく、そのまま使用することができます。 は、プレゼンテーション/ビュー、コントローラ、モデルを統合しています。

よく設計された拡張可能なリッチテキストシステムの例を見るには、OS X text system（またはコードを読む場合はGnustep）のドキュメントを参照してください。設計上の意思決定が必要であり、あるモジュールから他のモジュールに隠す必要があるため、複雑です。そこで、あなたは良い構造で直接作業することができます。そうしない場合にのみ意味をなす部品データの

• 読み込みと保存：

  RTF形式のメモコンポーネントを使用すると、うまく設計されたクラスを使用して回避する必要がある場合があります使用の制限された範囲を持っていますプログラム内の他のデータを同じファイル/ dbに保存する必要があります。

• また、大量のデータをうまく処理できません。
• そしてrtfの小さなサブセットしか理解できません。