[オブジェクト向けプログラミング入門]抽象
3559 ワード
多形性と抽象化
多形性、抽象化、多形性に比べて抽象化に集中する
カプセル化とオブジェクト向けプログラミングに必要な
この点は非常に重要です.
たけいせい
複数のシェイプ
オブジェクト向け環境では、1つのオブジェクトに複数のタイプがあります.
-1つのオブジェクトに複数のタイプの機能があります.
多形例
iotTimerは充電可能なインタフェースを継承するため、iotTimerはtimerタイプであってもよいし、recahgタイプであってもよい.
右側のように、モノのネットワークオブジェクトをtimer、chargeable typeに割り当てることができます.
抽象
ではなぜ多形性と言うのでしょうか->抽象化しているからです.
データまたはプロシージャを意味の近い概念または意味のある表現として定義します.
二つの方式の抽象
-特定の性質、共通の性質(一般化)
単純な例(第1の方法)
-DBのUSERテーブル:ID、名前、電子メール
抽象的で異なる実施
第2の態様は、異なる実施において共通の特徴があれば、抽象化することができる.
以上の3つの機能がいずれもプッシュ送信のために実現されている場合、プッシュ通知として抽象化される.
タイプ抽象
-通常はインタフェースタイプとして抽象化されます
この場合,抽象化されたタイプはインタフェースで表現されることが多く,抽象化されたタイプと実装クラスはタイプ継承によって接続される.
抽象タイプは共通の性質を表し、この表現はすぐに抽象タイプがどんな機能を提供するかを意味し、抽象タイプ自体は実現を提供しない.(実施がどうなるかわからない)
実装は抽象型を継承するクラス(EmailNotifier,KaKaoNotifier)に実装を提供し,実装を提供するクラスを特定のクラスと呼ぶ.
抽象型の使用
Notifier notifier = getNotifier(...);
notifier.notify(someNoti);
-機能ではなく意図をよりよく表現
抽象型を使用する利点:柔軟性
ではなぜ抽象的なタイプを使うのでしょうか->変更が柔軟になる.
直接使用
(注文キャンセル処理ロジックは変更されていません…)
すなわち,本質とは全く関係のない他の部分の体現により,本質が変化している.
共通点を見出す.
-SMSの送信
Eメール送信
->抽象->通知
エクスポートされた抽象タイプの使用
抽象ターゲット・アクセス
通知方式の変更を要求されても、DefaultNotifierFactoryセクションを変更すればよい.
あるいはNotifierFactoryのinstance()部分を修正すればいいです.
重要なのは、
これは、新しい要求があっても、注文Cancleロジック自体が変わらないことを意味します.
これが抽象化の原因です
抽象結果:使用状況の柔軟な変更
抽象画はいつ作りますか。
抽象は依存オブジェクトが変更された場合
-まだ存在しない機能の初期抽象化に注意してください.
-誤った抽象は複雑さを増すだけ
-拡張が発生したときに抽象化しようとする実際の変更
抽象的になりたいなら?
Reference
この問題について([オブジェクト向けプログラミング入門]抽象), 我々は、より多くの情報をここで見つけました https://velog.io/@kanamycine/객체지향-프로그래밍-입문-추상화テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol