当你看见new这个关键字的时候, 就应该想到它是具体的实现.
这就是一个具体的类, 为了更灵活, 我们应该使用的是接口(interface).
有时候, 你可能会写出这样的代码:
这里有多个具体的类被实例化了, 是按照差别情况在运行时被实例化的.
当你看到这样的代码, 你就会知道当有需求需要对其进行改削或者扩展的时候, 你就得把这个文件打开, 然后看看在这里应该添加或者删除点什么. 这类的代码经常会分手在措施的多个处所, 这维护和更新起来就很麻烦而且容易堕落.
针对interface进行编程的时候, 你知道可以把本身独立于系统未来可能要产生的变革. 为什么呢? 因为如果你针对interface编程, 那么对付任何实现了该接口的具体类对你来说都可以用, 多态吗.
项目原始需求有一个前沿的披萨店, 做披萨, 下面是订购披萨的类:
new一个披萨, 然后凭据工序进行加工 最后返回披萨.
但是, 一个披萨店不成能只有一种披萨, 可能会有很多中披萨, 所以你可能会这样改削代码:
按照传入的类型, 创建差此外披萨, 然后加工返回.
然后问题来了, 跟着时间的推移, 一个披萨店会裁减不脱销的披萨并添加新品种披萨.
使用上面的代码就会呈现这个问题, 针对需求变革, 我不得不把OrderPizza的部分代码改来改去:
从这里, 我们也可以看到, 上半部分是会变革的部分, 下半部分是不乱的部分, 所以它们应该分隔(把变革的部分和不乱的部分分隔, 然后进行封装).
布局应该是这样的:
右上角是变革的部分, 把这部分封装到一个东西里, 它就是用来创建披萨的东西, 我们把这个东西叫做: 工厂.
工厂卖力创建东西的细节事情. 我们创建的这个工厂叫做SimplePizzaFactory, 而orderPizza()这个要领就是该工厂的一个客户(client).
任何时候客户需要披萨的时候, 披萨工厂就会给客户创建一个披萨.
接下来, 我们就成立这个简易的披萨工厂:
就是通过传入的类型参数, 成立并返回差别类型的披萨.
这样我们就把披萨创建的事情封装到了一个类里面, 产生变革的时候, 只需要改削这一个类即可.
注意: 有时候上面这种简单工厂可以使用静态要领, 但是这样也犯错误谬误, 就是无法通过担任来扩展这个工厂了.
回来改削PizzaStore这个类:
工厂是从结构函数传入的, 并在PizzaStore里面保存一个引用.
在OrderPizza()要领里面, 我们使用工厂的创建要领取代了new关键字, 所以在这里没有具体的实例化.
简单工厂的界说简单/简易工厂并不是一个设计模式, 更多是一个编程习惯. 但是使用的非常广泛.
简单工厂类图:
这个很简单, 就不解释了.
简单工厂就到这, 下面要讲两个重量级的工厂模式.
用C#/.NET Core实现简单工厂Pizza父类:
using System; using System.Collections.Generic; namespace SimpleFactory.Pizzas { public abstract class Pizza { public string Name { get; protected set; } public string Dough { get; protected set; } public string Sauce { get; protected set; } protected List<string> Toppings = new List<string>(); public void Prepare() { Console.WriteLine($"Preparing: {Name}"); Console.WriteLine($"Tossing: {Dough}"); Console.WriteLine($"Adding sauce: {Sauce}"); Console.WriteLine("Adding toppings: "); Toppings.ForEach(x => Console.WriteLine($" {x}")); } public void Bake() { Console.WriteLine("Bake for 25 minutes"); } public void Cut() { Console.WriteLine("Cutting the pizza into diagnol slices"); } public void Box() { Console.WriteLine("Placing pizza in official PizzaStore box......"); } } }
View Code各类Pizza: