1.2 《硬啃设计模式》 第2章 学习设计模式需掌握的UML知识
要看懂 设计模式 ,你需要懂 类图 (Class Diagram ),也需要懂一点对象图(Object Diagram),下面介绍一些 UML 的必要知识,以便你学习设计模式。 属性、操作 下图简单介绍类的属性和操作。 类有属性(attributes)、操作(operations),属性和操作统称特
要看懂设计模式,你需要懂类图(Class Diagram),也需要懂一点对象图(Object Diagram),下面介绍一些UML的必要知识,以便你学习设计模式。属性、操作
下图简单介绍类的属性和操作。
类有属性(attributes)、操作(operations),属性和操作统称特性(features)。

下图进一步详细介绍类图细节,包括:属性和操作的作用域、属性类型、参数类型、方法返回值类型等。

接口、枚举

抽象类
继承关系
类B继承类A,如下图:
抽象类被继承,如下图:
实现关系
实现是指某接口被实现,而不是某类被实例化。
实现如下图:
依赖关系
先看图:
B依赖A,表示如果A的接口发生变化,B也需要相应地改变。
依赖的常见情况有:
1. B调用了A的方法。
2. B的方法中,使用了A为参数。
3. B的方法返回值类型为A。
引用关系
先看图:
Class1有箭头指向Class2,表示Class1中含有Class2的引用。
而上图进一步明确了具体的引用方式,就是:Class1中的私有变量m_Class2的类型是Class2。
你可能会问:某类保持另外一个类的引用,一般都会调用另外一个类的方法,那么它们的关系不应该是依赖关系吗?引用关系与依赖关系有什么区别?
这个问题很好!某些情况下,某类保持另外一个类的引用,但该类不调用另外一个类的方法,而是将另外一个类的引用暴露出来,供外部调用。
例如Class1有某一属性Class2,访问该属性可获得Class2的实例:
class1 = new Class1( );
class2 = class1.Class2;
Class1虽然有Class2的引用,但它自身不调用Class2的方法,而是让外部通过熟悉获得Class2的实例。
不过很多资料及书籍对“依赖关系”及“引用关系”的解释并不到位,不同资料之间的解释甚至是互斥的。而我见到的大部分设计模式的类图都不会区分“依赖关系”和“引用关系”,大部分设计模式的类图都会画成“引用关系”,本书后面的类图也将会不区别这两者,全部画成“引用关系”。
“包含”关系
我将“包含”关系分为“弱包含”和“强包含”,下图上面的是“弱包含”,下图下面的是“强包含”,此图说明了两种包含的区别。
“弱包含”和“强包含”只是我的一种俗称,学术的叫法是“聚合”和“组合”,一般资料可能会搞到你很晕,下图希望可以进一步解释清楚。

设计模式的类图中不少地方会用到“包含”关系,一些资料画成“强包含”,一些资料画成“弱包含”。我个人将“强包含”看成是“弱包含”的一种特例,大部分情况下我先画成“弱包含”,有需要才转化为“强包含”。本书中的包含关系,全部都画成“弱包含”。
对象图
类实例化后就是对象(Object),表示这些对象及对象之间关系的图就是对象图。有时候需要用对象图来表示设计模式。
对象图的例子:
请看下一文……
作者:张传波
创新工场创业课堂(敏捷课程)讲师
软件研发管理资深顾问
CMMI首席专家
《火球——UML大战需求分析》作者
《硬啃设计模式》作者
www.umlonline.org创办人

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











Java フレームワークにおけるデザイン パターンとアーキテクチャ パターンの違いは、デザイン パターンがソフトウェア設計における一般的な問題に対する抽象的な解決策を定義し、ファクトリ パターンなどのクラスとオブジェクト間の相互作用に焦点を当てていることです。アーキテクチャ パターンは、階層化アーキテクチャなどのシステム コンポーネントの編成と相互作用に焦点を当てて、システム構造とモジュールの間の関係を定義します。

デコレータ パターンは、元のクラスを変更せずにオブジェクトの機能を動的に追加できる構造設計パターンです。抽象コンポーネント、具象コンポーネント、抽象デコレータ、具象デコレータの連携によって実装され、ニーズの変化に合わせてクラス機能を柔軟に拡張できます。この例では、ミルクとモカのデコレーターが総額 2.29 ドルで Espresso に追加されており、オブジェクトの動作を動的に変更するデコレーター パターンの力を示しています。

1. ファクトリ パターン: オブジェクト作成とビジネス ロジックを分離し、ファクトリ クラスを通じて指定された型のオブジェクトを作成します。 2. オブザーバー パターン: サブジェクト オブジェクトが状態の変化をオブザーバー オブジェクトに通知できるようにし、疎結合とオブザーバー パターンを実現します。

デザイン パターンは、再利用可能で拡張可能なソリューションを提供することで、コード メンテナンスの課題を解決します。 オブザーバー パターン: オブジェクトがイベントをサブスクライブし、イベントが発生したときに通知を受信できるようにします。ファクトリ パターン: 具象クラスに依存せずにオブジェクトを作成するための集中的な方法を提供します。シングルトン パターン: クラスには、グローバルにアクセス可能なオブジェクトの作成に使用されるインスタンスが 1 つだけ存在することが保証されます。

アダプター パターンは、互換性のないオブジェクトが連携できるようにする構造設計パターンであり、オブジェクトがスムーズに対話できるように、あるインターフェイスを別のインターフェイスに変換します。オブジェクト アダプタは、適応されたオブジェクトを含むアダプタ オブジェクトを作成し、ターゲット インターフェイスを実装することにより、アダプタ パターンを実装します。実際のケースでは、クライアント (MediaPlayer など) はアダプター モードを通じて高度な形式のメディア (VLC など) を再生できますが、クライアント自体は通常のメディア形式 (MP3 など) のみをサポートします。

TDD は、高品質の PHP コードを作成するために使用されます。その手順には、テスト ケースを作成し、期待される機能を記述し、テスト ケースを失敗させることが含まれます。過度な最適化や詳細な設計を行わずに、テスト ケースのみが通過するようにコードを記述します。テスト ケースが合格したら、コードを最適化およびリファクタリングして、可読性、保守性、およびスケーラビリティを向上させます。

Guice フレームワークは、次のような多くの設計パターンを適用します。 シングルトン パターン: @Singleton アノテーションによってクラスのインスタンスが 1 つだけであることを保証します。ファクトリ メソッド パターン: @Provides アノテーションを使用してファクトリ メソッドを作成し、依存関係の注入中にオブジェクト インスタンスを取得します。戦略モード: アルゴリズムをさまざまな戦略クラスにカプセル化し、@Named アノテーションを通じて特定の戦略を指定します。

Java フレームワークでデザイン パターンを使用する利点には、コードの可読性、保守性、拡張性の向上が含まれます。欠点としては、複雑さ、パフォーマンスのオーバーヘッド、使いすぎによる学習曲線の急上昇などが挙げられます。実際のケース: プロキシ モードはオブジェクトの遅延読み込みに使用されます。デザイン パターンを賢く使用して、その利点を活用し、欠点を最小限に抑えます。
