让学习编程变得生动有趣~

定义策略模式定义了一系列的算法，并将每一个算法封装起来，而且使他们可以互相替换。策略模式让算法独立于使用它的客户而独立变化。使用场景针对同一类型问题的多种处理方式，仅仅是具体行为有差别时；需要安全地封装多种同一类型的操作时；出现同一抽象类有多个子类，而又需要使用if-else或者switch-case来选择具体子类时；···总的来说，可以这么理解，使用继承违背常理（狗继承动物，让它飞就太天真了）时，使用实现繁琐（猴鸡狗猪都会叫，他们都各自实现叫的方法太累了）时，此时可以考虑组合（也就是策略

定义用原型模式指定创建对象的种类，并通过复制这些原型创建新的对象。原型设计模式，是23种设计模式的创建型模式，简单来说，就是对象的克隆。将要被克隆的对象，我们称之为原型。使用场景类初始化或new一个新对象时，需要消耗非常多的资源，因为通过原型复制的方式不会执行构造方法，避免了初始化占有的时间和空间。一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式复制多个对象供调用者使用，即保护性拷贝。UML类图

定义定义一个用于创建对象的接口，让子类决定实例化哪个类。使用场景复杂对象的创建可以使用工厂模式，用new就可以完成的对象的创建就无需使用工厂模式。UML类图一共四个角色，即四大模块：一是抽象工厂Factory，工厂方法模式的核心；二是具体工厂ConcreteFactory，实现了具体的业务逻辑；三是抽象产品Product，是工厂方法模式所创建的产品父类；四是具体产品ConcreteProduct，是抽象产品的某个具体产品对象。代码实现package com.tcl.tvweish

我们知道四人组的《设计模式》共介绍了23种，并且将其分成3类，分别是：创建型、结构型、行为型，如下所示： - **创建型**：**5个**。工厂方法模式、抽象工厂模式、Builder模式（Retrofit）、单例模式（类初始化）、原型模式 - **结构型**：**7个**。适配器模式、装饰模式（File操作）、代理模式（静态代理——代理对象内部操作委托对象、动态代理——代理对象里面不指定特定的委托对象，更加灵活）、组合模式、桥接模式、外观模式、享元模式 - **行为型**：**11个**。观察者模式

定义当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。使用场景代码中包含大量与对象状态有关的条件语句，比如，一个操作中含有庞大的多分支语句（ifelse或switchcase），且这些分支依赖于该对象的状态；设计原则UML类图代码实现日志打印总结状态模式和策略模式的结构几乎完全一样，但它们的目的和本质却完全不一样。优点：将繁琐的状态判断转换成结构清晰的状态族，在避免代码膨胀的同时也保证了可扩展性与可维护性缺点：增加系统类和对象的个数...

/** * 为什么使用单例？ * 一个类专门提供一些公共功能供别人调用，而本身并不会处理业务逻辑。那么创建多个实例，会消耗内存，造成不必要的开销。此时需要单例。 * 单例是什么？ * 让整个生命周期内只有一个实例。 * <p> * 一般单例模式有如下五种写法：懒汉式，双重校验锁，静态内部类，饿汉式和枚举。 * 懒汉式：非线程安全 * 双重校验锁：线程安全 * 静态内...

定义将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。使用场景初始化一个对象特别复杂时（如：参数较多，且很多参数都具有默认值）；相同的方法，不同的执行顺序，产生不同的事件结果时；产品类非常复杂，或者产品类中的调用顺序不同产生了不同的作用，这个时候使用建造者模式非常合适。UML类图Product产品类——产品的抽象类；Builder——抽象Builder类，规范产品的组建，一般是由子类实现具体的组建过程；ConcreteBuilder——具体的Builder类

闲说设计模式信耶稣的人都要读圣经，而信OO的人都要读四人组的《设计模式》，这就是OO的圣经。OO概念是我们的基础，OO原则 是我们的目标，而设计模式是我们的做法。把模式装进脑子里，然后在你的设计和已有的应用中，寻找何处可以使用它们。设计模式定义1、模式：在某情境下，针对某问题的某种解决方案。情境：就是应用某个模式的情况。这应该是会不断出现的情况。问题：就是你想在某情境下达成的目标，但也可以是某情境下的约束。解决方案：就是你所追求的，一个通用的设计，用来解决约束、达到目标。2、STA

定义为创建一组相关或是相互依赖的对象提供一个接口，而不需要指定它们的具体类。抽象工厂模式是围绕一个超级工厂创建其他工厂。使用场景一个对象族有相同的约束时可以使用抽象工厂模式，能解决接口选择的问题（比如Android和IOS是不同系统但有相同的电话、短信等软件）。UML类图...

策略设计模式做的事情就是，将不同的行为策略进行独立封装，与类在逻辑上解耦。根据不同的上下文，切换选择不同的策略，然后用类对象进行调用。有如下例子，一个游泳运动员会蛙泳、仰泳、自由泳多种游泳姿势，我们可以将游泳这个行为封装成接口，根据不同的场景我们可以调用不同的游泳姿势，如下代码所示：package com.agg.kotlinapplicationinterface SwimStra...

访问者设计模式，是GoF阐述的23中常见设计模式中，行为型设计模式的一种。访问者设计模式，表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变个元素类的前提下定义作用于这些元素的新操作。使用该设计模式可以让我们能够访问到各个元素，于是我们可以将相关方法的实现放在类的外部，这样就可以使得类不再臃肿。下面是具体的代码实现：sealed class Target { abstr...

工厂方法设计模式，它的核心作用就是通过一个工厂隐藏对象实例的创建逻辑，而不需要暴露给客户端，实现解耦。典型的使用场景就是当拥有一个父类与多个子类的时候，我们可以通过这种模式来创建子类对象。比如下面的业务场景：一个电脑加工厂，同时生产个人电脑和服务器主机。interface Computer { val cpu: String companion object Facto...

为了更好的扩展性，可以“使用策略模式和多态去掉switch”（业务逻辑层适用，界面表现层除外，会增加代码的复杂度）。“使用策略模式和多态去掉switch”的思想如下：多处使用相同switch时（我觉得这个是前提，如果只有一处使用switch，而且后面基本上不会再扩展，那简单封装一下就可以了，毕竟时间那么宝贵，为啥还多去折腾一下呢？），1、先将switch代码块封装到一个新clas...

——如果尿布臭了，就换掉它。《重构：改善既有代码的设计》，在该书的第3章“代码的坏味道”中，收录了Kent Beck关于重构时机的理解——Code Smell。Code Smell的22种代码坏味道如下：Duplicated Code。a、同一个class内的两个函数含有相同的表达式。——需要Extract Method，提炼出重复代码，然后让两个地点都调用被提炼出来的那一段代码...

在软件开发中，前人总结了六大设计原则如下：Single Responsibility Principle：不能有多个导致类变更的原因。一个类只负责一个职责。这个原则不仅仅适用于类，对于接口和方法也适用，而且接口和方法的单一职责更容易实现。——单一职责原则 Liskov Substitution Principle：就是只要父类出现的地方子类就可以出现，且替换成子类也不会出现任何错误或者异...