我们谈论生活,讨论技术,借由文字,抵达心灵。
抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类结构:Client:客户端,具体使用抽象工厂的类与工厂方法模式的区别:产品不一样,现在有两类产品 A B,抽象工厂定义了一个创建产品A、创建产品B,工厂方法模式的升级版。工厂 2 可以创建产品 A 也可以创建产品 B,创建出来的产品是 A2 和 B2工厂 1 也可以创建产品 A 也可以创建产品 B,创建出来的产品是 A1 和 B1多增加相关的产品接口,再去工厂里面接口中增加一个方法//最上面这段可以理解成从客户端(Client)调用 public class AbstractFactory{ public static void main(String[] args){ Factroy factory1 = new Factory1(); //工厂 1 创建一个具体的产品 A ProductA productA = factory1.createProductA(); productA.info();
设计模式设计模式:是为了 复用 成功的设计和体系结构三大类:创建型模式、结构型模式、行为型模式创建型设计模式一个类创建模式,使用 继承 改变被实例化的类一个对象创建模式,将 实例化 委托给 另一个对象简单工厂模式定义一个工厂类,他可以根据参数的不同 返回不同类的实例,被创建的实例通常都具有共同的父类在简单工厂模式中,用于被创建实例的方法:静态方法 static因此 简单工厂模式 又被称为:静态工厂方法 Static Factory Method需要什么产品就传入产品对应的参数(需要产品 A,就传入产品 A 的参数),就会把产品 A 返回给你就可以获取所需要的产品对象,不需要知道其实现过程角色:工厂(核心):负责实现创建所有产品的内部逻辑工厂类可以直接被外界调用,创建所有对象:类名.静态方法名抽象产品:工厂类所创建的所有对象的父类封装了产品对象的公共方法,所有的具体产品都是其子类对象具体产品:简单工厂模式的 创建目标所有被创建的对象都是某个具体类的实例,要实现抽象产品中声明的抽象方法public class SimpleFactory{ //直接调用即可 public s
对象图展现了某一时刻一组对象以及他们之间的关系,描述了在类图中所建立的实物的实例的静态快照类名、属性对于一个对象来说 他们的行为应该都是一样的,所以方法可以省略掉一般在属性中会把属性对应的值写出来张三王五作为学生参加研讨会,李四作为助教参加研讨会用例图展现了一组用例、参与者以及他们之间的关系用例:椭圆参与者:小人用例之间的扩展关系 <<extend>> 和 包含关系 <<include>>参与者和用例之间的关联关系用例与用例,参与者与参与者之间的泛化关系学生:一般,留学生:特殊包含关系:用例和用例之间的关系一个用例,包含 另一个用例虚线,小箭头,上面写 <<include>> ,箭头右边是被包含的用例,左边是基本用例(包含用例)用例 A 包含 用例 B:可以理解为,B 用例是从 A 用例里分解出来的东西,执行 A 用例的时候一定会包含 B 的用例用户在商城想要查看订单、修改收货地址,都需要先登录才能做这些操作:就是你想要执行左边的这些用例,要先执行右边的用例扩展关系用例和用例之间的关系一个用例执行的时候,可能会发生
UML统一建模语言UML 由 3 个要素构成:UML 基本构造块、支配这些构造块如何放置在一起的规则和运用与整个语言的一些公共机制UML 的词汇表包含 3 种构造块:事物:对模型中最具有代表性的成分的抽象关系:把事物结合在一起图:聚集了相关的事物事物结构事物、行为事物、分组事物、注释事物结构事物UML 模型的静态部分,描述概念 或 物理元素。包括:类(Class)、接口(Interface)、协作(Collaboration)、用例(Use Case)、主动类(Active Class)、构件(Component)、制品(Artifact)、节点(Node)行为事物UML 模型的动态部分,是模型中的动词,描述了跨越时间和空间的行为。包括:交互(Interaction)、状态机(State Machine)、活动(Activity)分组事物UML 模型的组织部分,是一些由模型分解成的 “盒子”。最主要的分组事物是:包(Package)。结构事物、行为事物、其他分组事物都可以放进包内,纯粹是概念上的(仅在开发时存在)注释事物UML 模型中的解释部分关系依赖:两个事物间的予以关系,其中一个事
面向对象设计原则单一责任原则:SRP,Single Responsibility Principle就一个类而言,应该仅有一个引起它变化的原因。即,当需要修改某个类的时候,原因只有一个,让一个类制作一种类型责任。开放 - 封闭原则:Open & Close Principle,OCP软件实体(类、模块、函数等)应该是可以扩展的,即是 开放的;但是不可修改的,即是 封闭的对 扩展开放,对 修改关闭里氏替换原则,LSP,Liskov Substitution Principle子类型必须能够替换掉他们的 基类型(父类)。在任何父类可以出现的地方,都可以用子类的实例来复制给父类型的引用。(父类可以出现的地方,子类一定可以出现)当一个子类的实例应该能够替换任何其超类的实例时,它们之间才具有是一个(is-a)关系基类出现的地方,子类一定可以出现。依赖倒置原则,DIP,Dependence Inversion Principle抽象 不应该依赖于 细节细节 应该依赖于 抽象即,高层模块不应该依赖于低层模块,二者都应该依赖于抽象依赖于抽象,而不依赖于细节(实现)接口分离原则,ISP,Interfac
Luckyxyz