我个人认为，如果你想靠着背面试题来获得心仪的offer，用癞蛤蟆想吃天鹅肉形容完全不过分。想必大家能感受到面试越来越难，想找到心仪的工作也是越来越难，高薪工作羡慕不来，却又对自己目前的薪资不太满意，工作几年甚至连一个应届生的薪资都比不上，终究是错付了，错付了自己没有去提升技术。这些面试题分享给大家的目的，其实是希望大家通过大厂面试题分析自己的技术栈，给自己梳理一个更加明确的学习方向，当你准备好去面试大厂，你心里有底，大概知道面试官会问多广，多深，避免面试的时候一问三不知。
- 创建型模式主要包括如下6种模式。
| 模式名称 | 定义 | 概述 |
| — | — | — |
| 简单工厂模式 | 根据传人的参数即可返回所需的对象,而不需要知道具体类的类名 | 根据提供给它的数据,返回几个可能类中的一个类的实例。通常它返回的类都有一个公共的父类和公共的方法。简单工厂模式不属于GoF设计模式 |
| 工厂方法模式 | 定义一个用于创建对象的接口-让子类决定将哪一个类实例化。工厂方法模式使一个类的实例化延迟到其子类 | 将基一类对象的创建过程封装在单独的类中,通过引入抽象层的方式来使得对象的创建和使用更为灵活 |
| 抽象工厂模式 | 提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们具体的类 | 在一个类中可以创建多个不同类型的对象,这些对象所对应的类型都源于抽象层,使得系统具有极佳的扩展性和灵活性 |
| 建造者模式 | 将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示 | 一步一步构造一个由多个部分组成的复杂对象 |
| 原型模式 | 用原型实例指定创建对象的种类,并且通过复制这个原型来创建新的对象 | 通过复制已有对象创建出相似的其他对象 |
| 单例模式 | 保证一个类仅有一个实例,并提供一个访问它的全局访问点 | 控制系统中所创建的对象实例的个数 |
下面将带大家来学习这些巧妙的模式，并将他们运用到实际开发中，让大家更加轻松的吃到 “苹果”
=========================================================================
-
工厂模式（Factory Pattern）是 Java 中最常用的设计模式之一。这种类型的设计模式属于
创建型模式，它提供了一种创建对象的最佳方式。 -
在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。
-
简单工厂模式又称为静态工厂方法模式,它属于类创建型模式。在简单工厂模式中,可以根据参数的不同返回不同类的实例。专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。
-
如下图所示,用户无须知道苹果,橙﹑香蕉如何创建,只需要知道水果的名字则可得到对应的水果。
- 一个软件系统可以提供多个外观不同的按钮(如圆形按钮、矩形按钮﹑菱形按钮等),这些按钮都源自同一个基类,不过在继承基类后不同的子类修改了部分属性从而使得它们可以呈现不同的外观,如果我们希望在使用这些按钮时,不需要知道这些具体按钮类的名字,只需要知道表示该按钮类的一个参数，并提供一个调用方便的方法,把该参数传入方法即可返回一个相应的按钮对象,此时,就可以使用简单工厂模式。
简单工厂模式结构比较简单,其核心是工厂类。包含如下角色。
- Factory(工厂角色)
工厂角色即工厂类，它是简单工厂模式的核心,负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用,创建所需的产品对象。在工厂类中提供了静态的工厂方法 factoryMethod() ,它返回一个抽象产品类Product,所有的具体产品都是抽象产品的子类。
- Product(抽象产品角色)
抽象产品角色是简单工厂模式所创建的所有对象的父类,负责描述所有实例所共有的公共接口,它的引入将提高系统的灵活性,使得在工厂类中只需定义一个工厂方法,因为所有创建的具体产品对象都是其子类对象。
- ConcreteProduct(具体产品角色)
具体产品角色是简单工厂模式的创建目标,所有创建的对象都充当这个角色的某个具体类的实例。每一个具体产品角色都继承了抽象产品角色。需要实现定义在抽象产品中的抽象方法。
结构分析 👇
某销售管理系统支持多种支付方式如现金支付(CashPay)、信用卡支付(CreditcardPay),代金券支付(VoucherPay)等,在设计中如果不使用简单工厂模式,可能会存在如下支付方法。
public void pay(String type){
if(type.equalsIgnoreCase(“cash”){
//现金支付处理代码
}
else if(type.equalsIgnoreCase(“creditcard”)){
//信用卡支付处理代码
}
else if(type.equalsIgnoreCase(“voucher”)){
//信用卡支付处理代码
}
else{
…
}
}
- 问题：由于不同的支付方式其支付处理方法不一致,因此该方法源代码将相当冗长,而且每当需要增加新的支付方式时,不得不修改这段if…else…代码,增加很多新的支付处理代码。代码越长意味着维护工作量越大,测试难度也越大,扩展和修改也越不灵活。因此可以考虑使用简单工厂模式对其进行重构。
下面我们通过简单工厂模式，对原有的代码进行改进 👇
为了保证系统的扩展性并将各种支付类型对象的创建封装在一个统一的方法中，需要引人抽象支付方式类,它定义了抽象的支付方法,抽象支付方法类定义如下
public abstract class AbstractPay{
public abstract void pay();
}
将每一种支付方式封装在一个独立的类中,各个支付方式类相对独立,修改其一对其他类无任何影响,这些独立的支付方式类充当具体产品类的角色,是抽象支付方式类的子类,如现金支付类信用卡支付类定义如下
public class CashPay extends AbstractPay{
public void pay(){
//现金支付处理代码
}
}
public class CreditcardPay extends AbstractPay{
public void pay(){
//信用卡支付处理代码
}
}
提供一个代码相对简单,而且只负责创建对象而不必关心对象细节的工厂类来创建各种具体的支付方式产品类,注意其工厂方法的返回类型是抽象类型,支付方式工厂类定义如下
public class PayMethodFactory{
public static AbstractPay getPayMethod(String type){
if(type.equalsIgnoreCase(“cash”)){
return new CashPay(); //根据参数创建具体产品
}else if(type.
最低0.47元/天 解锁文章
284
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
