5つのデザインパターンでシェア
デザインモードでは、実績のある開発の過程で蓄積され、特定の問題の解決策を繰り返し、特定の環境を解決するために使用することができます。
ファクトリパターン
シンプルな、一般的な、3つの特定の抽象モデルに分け、この分析は簡単で、一般的な植物工場を識別します。
機能ファクトリメソッドパターンは、オブジェクトを作成するためのインタフェースを定義するが、サブクラスは、クラスの特定のインスタンスを決定させることです。そのサブクラスを遅らせるために、クラスをインスタンス化するために、工場の製造方法。
使用シナリオ:あなたは、データベース、ログシステムに適した複雑なオブジェクトを作成する必要があります。シンプル簡単にファクトリパターンを使用しなくて新しいオブジェクトを使用することができるようにします。
長所:消費者と事業体との間に直接の依存関係に加えて、消費者向け無誘導の場合に作成されたオブジェクトの「処理」することができます。
短所:プロジェクトが肥大化になるような方法でコードの量を増やします。
public interface Clothes {
/**
* 制造衣物
*/
void make();
}
/**
* 裙子
*/
class Dress implements Clothes {
@Override
public void make() {
System.out.println("给你裙子");
}
}
/**
* 衬衫
*/
class Shirt implements Clothes {
@Override
public void make() {
System.out.println("给你衬衫");
}
}
/**
* 裤子
*/
class Pants implements Clothes {
@Override
public void make() {
System.out.println("给你裤子");
}
}
/**
* 没造出来
*/
class NoClothes implements Clothes {
@Override
public void make() {
System.out.println("没造出来");
}
}
シンプル工場:
クラス固有の機能が実装する必要が同じインターフェイスを、工場が担当する論理的な意思決定およびインスタンス化。
消費者は、工場の内部動作を気にしないだけで需要を作った工場出荷時の処理によってインスタンス化、および消費者ニーズの対応するインスタンスに沿って戻ります。
class SimpleFactory { Clothes makeClothes(String type) { Clothes clothes; switch (type) { case "dress": clothes = new Dress(); break; case "shirt": clothes = new Shirt(); break; case "pants": clothes = new Pants(); break; default: clothes = new NoClothes(); break; } return clothes; } } public class SimpleFactoryDemo { public static void main(String[] args) { Clothes clothes; System.out.println("简单工厂模式:"); SimpleFactory simpleFactory = new SimpleFactory(); System.out.println("工厂,我需要裤子"); clothes = simpleFactory.makeClothes("pants"); clothes.make(); System.out.println("工厂,我需要衬衫"); clothes = simpleFactory.makeClothes("shirt"); clothes.make(); } }
利点:消費者と使いやすい、消費者は修正機能が機能だけを追加したり、機能を変更するために渡されたパラメータの名前を変更する必要が終了し、消費者の変更する必要はありません単に工場で対応する判定ブランチを追加し、コードを。
短所:オブジェクトが作成され、より多くする必要が増加したファクトリクラスのカップリングにつながる、各ファクトリクラスのメンテナンスを修正しながら、コードファクトリクラスの量は、開閉の原則に違反している間、非常に高くなります。
ノーマルファクトリー:
同じインターフェイス機能を実装して、特定のクラスに基づいてすべてのファクトリクラスを継承同じ抽象クラスコンフィギュレーションを。クライアントに工場を決定するために、単純なロジックの移行、消費者は、工場の使用を選択し、工場はすなわち、異なる特定のカテゴリのさまざまな機能を作成するための責任がある工場やフィーチャクラス1に対応します。
/** * 抽象工厂类 */ abstract class AbstractFactory { /** * 抽象获取实体的方法 * * @return 衣物实体 */ abstract Clothes getClothes(); } /** * 衬衫工厂 */ class ShirtFactory extends AbstractFactory { @Override Clothes getClothes() { System.out.println("衬衫工厂开工"); return new Shirt(); } } /** * 裙子工厂 */ class DressFactory extends AbstractFactory { @Override Clothes getClothes() { System.out.println("裙子工厂开工"); return new Dress(); } } public class NormalFactoryDemo { public static void main(String[] args) { AbstractFactory factory; System.out.println("工厂模式:"); System.out.println("想要裙子,来个裙子工厂造一下"); factory = new DressFactory(); factory.getClothes().make(); System.out.println("想要衬衫,来个衬衫工厂造一下"); factory = new PantsFactory(); factory.getClothes().make(); } }
メリット:簡単な開口部の欠点を克服するために工場を結合し、原則に違反して工場の閉鎖の程度を低減することができます。
短所:メンテナンスや機能を追加するには、あなたが変更する必要があるコードの量を増やします。
複合モード
合成モードは、ツリー構造で複数のオブジェクトの組み合わせ消費者ができるように、階層- 「全部」を表すためにオブジェクト・モードで個々の複数のオブジェクトを合成処理することによって治療すること。
複合モードを達成するための最も重要な領域である、相互運用可能なインターフェイス。
これは、同じベースオブジェクトと単純なオブジェクトとマッチング処理の理由の組み合わせとすることができるオブジェクトモデルの組み合わせで組み立てられた複合オブジェクト、の間のインタフェースを有しています。
使用シナリオ:ツリーメニュー、ツリーのフォルダ管理など
/**
* 抽象构件
*/
abstract class AbstractComponent {
String mark;
AbstractComponent(String mark) {
this.mark = mark;
}
/**
* 添加子节点
*/
abstract void add(AbstractComponent component);
/**
* 删除子节点
*/
abstract void remove(AbstractComponent component);
/**
* 显示结构
*/
abstract void function(int depth);
}
/**
* 构件类型1:分支型
* 分支型特有:实现添加与删除节点功能
* 同时实现方法功能
*/
class Branch extends AbstractComponent {
Branch(String mark) {
super(mark);
}
private List<AbstractComponent> components = new ArrayList<>();
@Override
void add(AbstractComponent component) {
components.add(component);
}
@Override
void remove(AbstractComponent component) {
components.remove(component);
}
@Override
void function(int depth) {
for (int i = 1; i < depth; i++) {
System.out.print("--");
}
System.out.println(mark);
for (AbstractComponent component : components
) {
component.function(depth + 1);
}
}
}
/**
* 构件类型2:末端型
* 仅实现方法功能
*/
class Extremity extends AbstractComponent {
Extremity(String mark) {
super(mark);
}
@Override
void add(AbstractComponent component) {
}
@Override
void remove(AbstractComponent component) {
}
@Override
void function(int depth) {
for (int i = 1; i < depth; i++) {
System.out.print("--");
}
System.out.println(mark);
}
}
public class CompositeDemo {
public static void main(String[] args) {
System.out.println("设计模式-组合模式Demo:\n");
//初始化根节点
AbstractComponent root = new Branch("根节点构件");
//配置分支
AbstractComponent branch1 = new Branch("分支构件1");
branch1.add(new Extremity("末端构件1-1"));
AbstractComponent branch2 = new Branch("分支构件2");
AbstractComponent branch21 = new Branch("分支构件2-1");
branch21.add(new Extremity("末端构件2-1-1"));
branch2.add(branch21);
AbstractComponent branch22 = new Branch("分支构件2-2");
branch22.add(new Extremity("末端构件2-2-1"));
branch22.add(new Extremity("末端构件2-2-2"));
branch2.add(branch22);
//组合构件
root.add(branch1);
root.add(branch2);
root.add(new Branch("分支构件3"));
root.add(new Extremity("末端构件3"));
//使用构件
root.function(1);
}
}
利点:
- 合成モードは、消費者ができ、一貫処理とコンテナオブジェクト心配することなく、その単一のオブジェクトまたはターゲットの組み合わせで処理容器。
- だから消費者は、直接依存しない、複雑なオブジェクトコンテナを行う結合の度合いを軽減します。
- することができ、より簡単に、対象組成物の新しいメンバーに加えます。
短所:作るデザインはより複雑に。消費者は、クラス間の階層関係を整理するために多くの時間を費やす必要があります。
デコレーター
特長のDecoratorパターンがされ、その構造を変更せずに、既存のオブジェクトに新しい機能を追加することができ。
このパターンは、装飾を作成し、元のクラスをラップするために使用され、クラスメソッドの整合性を維持することが追加機能を提供する前提の下で署名しました。
使用シナリオ:古いコードのメンテナンスは、動的オブジェクトに機能を追加します
/**
* 抽象构件,装饰器和基础构件都需要继承它
*/
abstract class AbstractComponent {
/**
* 功能
*/
abstract void function();
}
/**
* 基础构件
*/
class BaseComponent extends AbstractComponent {
@Override
void function() {
System.out.println("这里是基本类在小声说话");
}
}
/**
* 装饰器构件
*/
class Decorator extends AbstractComponent {
private AbstractComponent component;
Decorator(AbstractComponent component) {
this.component = component;
}
@Override
void function() {
component.function();
speakLoudly();
}
void speakLoudly() {
System.out.println("然后借助装饰器又喊了一遍");
}
}
public class DecoratorDemo {
public static void main(String[] args) {
AbstractComponent baseComponent = new BaseComponent();
AbstractComponent superComponent = new Decorator(baseComponent);
System.out.println("基本类:");
baseComponent.function();
System.out.println("装饰器增强:");
superComponent.function();
}
}
長所:
- 動的な拡張、機能クラスの継承よりも柔軟性、および消費者に透明。
- することができ、同じ装飾されたオブジェクトに対して数回に装飾され、複雑な機能は異なる動作を作成します。
短所:
- 多層装飾のコードはより複雑です。
- 以来、装飾層の各々は、対応するオブジェクトを作成する装飾が非常にネストされている場合、それは過度の小さなオブジェクトをもたらすことができます。
- 装飾的なネスティングがエラーを起こしやすい、とにつながる高い複雑さをトラブルシューティングするためのデバッグ。
ブリッジモード
ブリッジモードである、その実装から分離し、抽象化、彼らは独立して変化させることができるように、。
付加的な複雑さを導入することなく、オブジェクト変更のための複数の次元を提供します。
Paozhaopaozheプログラムは、どこへ行く橋を橋に遭遇しました。
使用シナリオ:インター成分系、動的に実行時に、スイッチング・システム・オブジェクト、望ましくない継承されたマルチレベルシステムの十分に高い柔軟性を有する必要があります。
/**
* 被桥接的类应该实现这个接口
*/
interface Bridgeable {
/**
* 功能接口
*/
public void method();
}
/**
* 跑步模式
*/
class RunningBridge implements Bridgeable {
@Override
public void method() {
System.out.println("连接跑步端口\n一直在跑步...");
}
}
/**
* 站定模式
*/
class StandingBridge implements Bridgeable {
@Override
public void method() {
System.out.println("连接原地呆着端口\n站在原地不动...");
}
}
/**
* 定义一个抽象类桥,定义桥接目标的抽象实例
*/
abstract class AbstractBridge {
/**
* 待放入的桥接目标
*/
private Bridgeable bridgeable;
/**
* 使用桥接目标的方法
*/
public void method() {
bridgeable.method();
}
/**
* 设置桥接的目标
*/
void setBridgeable(Bridgeable bridgeable) {
this.bridgeable = bridgeable;
}
/**
* 获取桥接的目标
*/
Bridgeable getBridgeable() {
return bridgeable;
}
}
/**
* 实现功能的桥
*/
class MyBridge extends AbstractBridge {
@Override
public void method() {
getBridgeable().method();
}
}
public class BridgeDemo {
public static void main(String[] args) {
// 实例化一个桥
AbstractBridge bridge = new MyBridge();
// 实例化一个桥接目标
RunningBridge runningBridge = new RunningBridge();
// 把目标传入桥
bridge.setBridgeable(runningBridge);
// 通过桥使用目标
bridge.method();
// 实例化一个桥接目标
StandingBridge standingBridge = new StandingBridge();
// 把目标传入桥
bridge.setBridgeable(standingBridge);
// 通过桥统一的方法进去
bridge.method();
}
}
長所:
1. 实现了***抽象与实现部分的分离***。
- *の機能改善スケーラビリティを。
- 提供するダイナミックスイッチングモードを。
短所:
1. 增加了系统的***设计和理解难度***。
- システムのための異なる寸法は、明確に区別が必要で、従って制限されます。
プロキシモード
プロキシモードでは、オブジェクトの実装への参照を制御することで、プロキシオブジェクトとプロキシオブジェクトを消費者に提供することです。
演技のクラスは、機能インタフェースを実装し、クラスの実際の機能を呼び出すためにプロキシクラスの関数インタフェースを呼び出すことによって、建設、消費者のプロキシクラスにインタフェース固有の機能を実装するクラスを作成します。
これは、クラスオブジェクトをコンストラクタで作成され、デコレータのクラス構築物は外に渡されることを除いて、装飾的なモードと非常によく似ています。
使用シナリオ:アクセスを制限する必要がある、あなたは、特定の機能を拡張する必要があり、特定の方法を扱う際に区別する必要があります。
長所:
- 中間単離は、機能オブジェクトは、プロキシクラスによって呼び出され、消費者や設計から分離することができます。
- 開閉の原則に沿って、何も変更が良い、特定の機能クラスをパッケージ化されていません。
短所:
- クライアントと実際のオブジェクト間のプロキシオブジェクトを増加し、そのプロキシモードのいくつかの種類が遅く、処理速度の要求につながる可能性があるため。
- プロキシモードを実装するいくつかの代理店モデルは非常に複雑であり、実現するために、追加の作業が必要です。
/**
* 代理沟通的接口
*/
interface Proxyable {
/**
* 功能
*/
public void method();
}
/**
* 实现功能的具体类
*/
class ProxySource implements Proxyable {
@Override
public void method() {
System.out.println("作者出来说话");
}
}
帯電防止剤
プロキシクラス、開閉の原則に準拠した、ターゲットオブジェクト拡張機能を作成します。
/** * 静态代理 */ class StaticProxy implements Proxyable { private ProxySource proxySource = null; StaticProxy() { proxySource = new ProxySource(); } @Override public void method() { System.out.println("代理人收到消息,去找作者"); proxySource.method(); System.out.println("代理人的任务做完了"); } }
長所:開閉の原則に沿って、およびのためのパフォーマンスへの影響は最小限に抑え。
短所:メンテナンス時にワークロードは、それぞれの新しいサービスに対応するプロキシを増やす必要があります。そして、インターフェイスの変更は、また、プロキシクラスを変更する必要がある場合。
動的プロキシ
手動でプロキシクラスを作成する必要はありません、唯一のダイナミックプロセッサを記述する必要があります。ランタイム反射時に動的プロキシオブジェクトによって生成されます。
/** * 动态代理 */ class DynamicProxy { /** * 配置动态代理调用 */ private static final InvocationHandler SOURCE_HANDLE = new InvocationHandler() { @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Object result = method.invoke(new ProxySource(), args); System.out.println("动态代理人的任务做完了"); return result; } }; /** * 获取被代理的实例 */ Proxyable getProxy() { Proxyable proxyInstance; System.out.println("动态代理人开始到处找作者"); proxyInstance = (Proxyable) Proxy.newProxyInstance(ProxySource.class.getClassLoader(), new Class[] { Proxyable.class }, SOURCE_HANDLE); System.out.println("找到作者了"); return proxyInstance; } }
長所:
- ダイナミックプロキシは大幅にコード開発の量を減少させます。
- これは、結合度を減らし、サービス・インターフェースへの依存を軽減します。
短所:
- サポートされる唯一のインタフェースエージェントに限定
- 反射機構ため、低い動作効率