设计模式之软件设计原则
Posted 二木成林
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了设计模式之软件设计原则相关的知识，希望对你有一定的参考价值。
目录
软件设计原则
在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据6条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。
开闭原则
开闭原则：对扩展开放，对修改关闭。
在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类。
因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。
- 要求：对程序进行扩展的时候，不能修改原代码。
- 解决：使用抽象类或接口，有需求的时候继承抽象类或实现接口即可完成扩展。
例：很多软件程序都可以更换主题，如黑色主题、默认主题、亮色主题等，可以定义一个主题抽象类AbstractTheme，而具体每个主题（默认主题DefaultTheme、黑色主题BlackTheme和亮色主题LightTheme）是其子类，用户可以自己选择使用什么主题，而不必修改原其他主题的源码，满足开闭原则。
其UML图如下：
上例代码如下：
- AbstractTheme.java
public abstract class AbstractTheme {
// 显示主题
public abstract void show();
}
- BlackTheme.java
public class BlackTheme extends AbstractTheme {
@Override
public void show() {
System.out.println("黑色主题");
}
}- DefaultTheme.java
public class DefaultTheme extends AbstractTheme {
@Override
public void show() {
System.out.println("默认主题");
}
}- LightTheme.java
public class LightTheme extends AbstractTheme {
@Override
public void show() {
System.out.println("亮色主题");
}
}
- Soft.java
public class Soft {
private AbstractTheme theme;
public Soft() {
}
public Soft(AbstractTheme theme) {
this.theme = theme;
}
public void setTheme(AbstractTheme theme) {
this.theme = theme;
}
public void display(){
theme.show();
}
}Test.java
public class Test {
public static void main(String[] args) {
// 1.创建软件对象
Soft soft = new Soft();
// 2.创建主题对象
// DefaultTheme theme=new DefaultTheme();// 使用默认主题
// BlackTheme theme=new BlackTheme();// 使用黑色主题
LightTheme theme = new LightTheme();// 使用亮色主题
// 3.为软件设置主题
soft.setTheme(theme);
// 4.显示主题
soft.display();
}
}里氏替换原则
里氏替换原则：子类可以扩展父类的功能，但不能改变父类原有的功能。
里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。
也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。
根据上述理解，对里氏替换原则的定义可以总结如下：
- 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法
- 子类中可以增加自己特有的方法
- 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松
- 当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的的输出/返回值）要比父类的方法更严格或相等
关于里氏替换原则的例子，最有名的是“正方形不是长方形”。当然，生活中也有很多类似的例子，例如，企鹅、鸵鸟和几维鸟从生物学的角度来划分，它们属于鸟类；但从类的继承关系来看，由于它们不能继承“鸟”会飞的功能，所以它们不能定义成“鸟”的子类。同样，由于“气球鱼”不会游泳，所以不能定义成“鱼”的子类；“玩具炮”炸不了敌人，所以不能定义成“炮”的子类等。
下面以企鹅不是鸟为例来应用里氏替换原则。
例：鸟一般都会飞行，例如麻雀的飞行速度是120，但某些虽然归属于鸟类，却不会飞，如企鹅等。现在要求设计一个实例，计算这种鸟飞行300要花费的时间，能够计算麻雀的飞行时间成功，但计算企鹅的飞行时间会失败，不符合要求。其UML图如下：
实现代码如下：
- Bird.java
public class Bird {
private double flySpeed;// 鸟的飞行速度
/**
* 设置鸟的飞行速度
*
* @param flySpeed 鸟的飞行速度
*/
public void setFlySpeed(double flySpeed) {
this.flySpeed = flySpeed;
}
/**
* 根据鸟的飞行距离和飞行速度来计算飞行时间
*
* @param flyDistance 鸟的飞行距离
* @return 返回计算成功的鸟的飞行时间
*/
public double getFlyTime(double flyDistance) {
return flyDistance / flySpeed;
}
}- Penguin.java
public class Penguin extends Bird {
@Override
public void setFlySpeed(double flySpeed) {
// 因为企鹅是不会飞的，所以如果设定了飞行速度，不符合逻辑，必须置为0
flySpeed = 0;
}
}- Sparrow.java
public class Sparrow extends Bird {
}- Test.java
public class Test {
public static void main(String[] args) {
// 设定飞行距离
double flyDistance = 300;
// 计算麻雀的飞行时间
Bird sparrow = new Sparrow();
sparrow.setFlySpeed(120);// 设定麻雀飞行速度为120
double sparrowFlyTime = sparrow.getFlyTime(flyDistance);// 得到麻雀的飞行时间结果
System.out.println(sparrowFlyTime);// 2.5
// 计算企鹅的飞行时间
Bird penguin = new Penguin();
penguin.setFlySpeed(120);// 设定企鹅飞行速度为120
double penguinFlyTime = penguin.getFlyTime(flyDistance);// 得到企鹅的飞行时间结果
System.out.println(penguinFlyTime);// Infinity【注：不是正确结果，任何数除以浮点数0结果为Infinity或-Infinity】
}
}程序运行失败的原因是，企鹅重写了鸟类的setFlySpeed(double flySpeed)方法，这违背了里氏替换原则。解决方法是取消企鹅原来的继承关系，定义鸟和企鹅更通常的父类，如动物类，它们都具有移动的能力。企鹅的飞行速度为0，但移动速度不为0，可以计算出它移动相同距离所花费的时间。重新设计后的UML类图如下：
- Animal.java
public class Animal {
private double moveSpeed;// 移动速度
/**
* 设置动物的移动速度
*
* @param moveSpeed 动物的移动速度
*/
public void setMoveSpeed(double moveSpeed) {
this.moveSpeed = moveSpeed;
}
/**
* 计算动物的移动速度
*
* @param moveDistance 给定的移动距离
* @return 返回计算成功的移动时间
*/
public double getMoveTime(double moveDistance) {
return moveDistance / moveSpeed;
}
}- Bird.java
public class Bird extends Animal{
private double flySpeed;// 鸟的飞行速度
/**
* 设置鸟的飞行速度
*
* @param flySpeed 鸟的飞行速度
*/
public void setFlySpeed(double flySpeed) {
this.flySpeed = flySpeed;
}
/**
* 根据鸟的飞行距离和飞行速度来计算飞行时间
*
* @param flyDistance 鸟的飞行距离
* @return 返回计算成功的鸟的飞行时间
*/
public double getFlyTime(double flyDistance) {
return flyDistance / flySpeed;
}
}- Penguin.java
public class Penguin extends Animal {
}- Sparrow.java
public class Sparrow extends Bird {
}
- Test.java
public class Test {
public static void main(String[] args) {
// 设定飞行距离
double flyDistance = 300;
// 计算麻雀的飞行时间
Bird sparrow = new Sparrow();
sparrow.setFlySpeed(120);// 设定麻雀飞行速度为120
double sparrowFlyTime = sparrow.getFlyTime(flyDistance);// 得到麻雀的飞行时间结果
System.out.println(sparrowFlyTime);// 2.5
// 计算企鹅的移动时间
Animal penguin = new Penguin();
penguin.setMoveSpeed(120);// 设定企鹅移动速度为120
double penguinFlyTime = penguin.getMoveTime(flyDistance);// 得到企鹅的移动时间结果
System.out.println(penguinFlyTime);// 2.5
}
}依赖倒置原则
依赖导致原则：高层模块不应该依赖低层模块，要面向接口编程，而不是面向实现类编程。
高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。
依赖倒置原则的主要作用如下：
- 依赖倒置原则可以降低类间的耦合性。
- 依赖倒置原则可以提高系统的稳定性。
- 依赖倒置原则可以减少并行开发引起的风险。
- 依赖倒置原则可以提高代码的可读性和可维护性。
依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点，就能在项目中满足这个规则：
- 每个类尽量提供接口或抽象类，或者两者都具备。
- 变量的声明类型尽量是接口或者是抽象类。
- 任何类都不应该从具体类派生。
- 使用继承时尽量遵循里氏替换原则。
例：现要组装一台电脑，需要配件cpu，硬盘，内存条。只有这些配置都有了，计算机才能正常的运行。选择cpu有很多选择，如Intel，AMD等，硬盘可以选择希捷，西数等，内存条可以选择金士顿，海盗船等。 其UML类图如下：
实现类代码如下：
- IntelCpu.java
public class IntelCpu {
public void run(){
System.out.println("使用Intel处理器");
}
}- KingstonMemory.java
public class KingstonMemory {
public void save(){
System.out.println("使用金士顿作为内存条");
}
}- XiJieHardDisk.java
public class XiJieHardDisk {
public void save(String data) {
System.out.println("使用希捷硬盘存储数据" + data);
}
public String get() {
System.out.println("使用希捷希捷硬盘取数据");
return "数据";
}
}- Computer.java
public class Computer {
private XiJieHardDisk hardDisk;
private IntelCpu cpu;
private KingstonMemory memory;
public void setHardDisk(XiJieHardDisk hardDisk) {
this.hardDisk = hardDisk;
}
public void setCpu(IntelCpu cpu) {
this.cpu = cpu;
}
public void setMemory(KingstonMemory memory) {
this.memory = memory;
}
public void run() {
System.out.println("计算机工作");
cpu.run();
memory.save();
String data = hardDisk.get();
System.out.println("从硬盘中获取的数据为：" + data);
}
}- Test.java
public class Test {
public static void main(String[] args) {
// 1.创建电脑类
Computer computer = new Computer();
// 2.设置硬盘、CPU和内存条参数
// 2.1设置硬盘
XiJieHardDisk hardDisk = new XiJieHardDisk();
computer.setHardDisk(hardDisk);
// 2.2设置CPU
IntelCpu cpu = new IntelCpu();
computer.setCpu(cpu);
// 2.3设置内存条
KingstonMemory memory = new KingstonMemory();
computer.setMemory(memory);
// 3.启动电脑
computer.run();
}
}上面的代码已经组装了一台电脑，但是组装的电脑CPU只能是intel的，内存条只能是金士顿的，硬盘只能是希捷的，这是不好的，因为用户都希望自己选择配置配件。
所以需要根据依赖倒置原则进行改进，使用接口而非实现类。修改后的UML类图如下：
实现代码如下：
- Cpu.java
public interface Cpu {
/**
* 运行CPU
*/
void run();
}- IntelCpu.java
public class IntelCpu implements Cpu {
public void run(){
System.out.println("使用Intel处理器");
}
}
- HardDisk.java
public interface HardDisk {
/**
* 保存数据到硬盘中
*
* @param data 待保存的数据
*/
void save(String data);
/**
* 获取数据
*
* @return 获取到的数据
*/
String get();
}
- XiJieHardDisk.java
public class XiJieHardDisk implements HardDisk{
public void save(String data) {
System.out.println("使用希捷硬盘存储数据" + data);
}
public String get() {
System.out.println("使用希捷希捷硬盘取数据");
return "数据";
}
}
- Memory.java
public interface Memory {
void save();
}
- KingstonMemory.java
public class KingstonMemory implements Memory {
public void save(){
System.out.println("使用金士顿作为内存条");
}
}
- Computer.java
public class Computer {
private HardDisk hardDisk;
private Cpu cpu;
private Memory memory;
public void setHardDisk(HardDisk hardDisk) {
this.hardDisk = hardDisk;
}
public void setCpu(Cpu cpu) {
this.cpu = cpu;
}
public void setMemory(Memory memory) {
this.memory = memory;
}
public void run() {
System.out.println("计算机工作");
cpu.run();
memory.save();
String data = hardDisk.get();
System.out.println("从硬盘中获取的数据为：" + data);
}
}- Test.java
public class Test {
public static void main(String[] args) {
// 1.创建电脑类
Computer computer = new Computer();
// 2.设置硬盘、CPU和内存条参数
// 2.1设置硬盘
HardDisk hardDisk = new XiJieHardDisk();
computer.setHardDisk(hardDisk);
// 2.2设置CPU
Cpu cpu = new IntelCpu();
computer.setCpu(cpu);
// 2.3设置内存条
Memory memory = new KingstonMemory();
computer.setMemory(memory);
// 3.启动电脑
computer.run();
}
}面向对象的开发很好的解决了这个问题，一般情况下抽象的变化概率很小，让用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度。
接口隔离原则
“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法；一个类对另一个类的依赖应该建立在最小的接口上。
接口隔离原则：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
例：我们需要创建一个月亮品牌的安全门，该安全门具有防火、防水、防盗的功能。可以将防火，防水，防盗功能提取成一个接口，形成一套规范。UML类图如下：
实现类代码如下：
- SafetyDoor.java
public interface SafetyDoor {
/**
* 防盗
*/
void antiTheft();
/**
* 防火
*/
void fireproof();
/**
* 防水
*/
void waterproof();
}- MoonSafetyDoor.java
public class MoonSafetyDoor implements SafetyDoor {
@Override
public void antiTheft() {
System.out.println("防盗");
}
@Override
public void fireproof() {
System.out.println("防火");
}
@Override
public void waterproof() {
System.out.println("防水");
}
}- Test.java
public class Test {
public static void main(String[] args) {
SafetyDoor safetyDoor=new MoonSafetyDoor();
safetyDoor.antiTheft();
safetyDoor.fireproof();
safetyDoor.waterproof();
}
}我们可以发现上面存在的问题，月亮品牌的安全门具有防盗、防火、防水的功能，但如果我们需要创建一个太阳品牌的安全门，而该安全门只具有防盗、防火功能呢？要再创建一个具有防火、防水功能的星星品牌的安全门呢，我们当然还是实现SafetyDoor接口，让一些方法只是实现但不写方法体，但这违背了接口隔离原则，我们需要进行修改，看如下UML类图：
实现代码如下：
- AntiTheft.java
public interface AntiTheft {
/**
* 防盗
*/
void antiTheft();
}- Fireproof.java
public interface Fireproof {
/**
* 防火
*/
void fireproof();
}- Waterproof.java
public interface Waterproof {
/**
* 防水
*/
void waterproof();
}- MoonSafetyDoor.java
public class MoonSafetyDoor implements AntiTheft, Fireproof, Waterproof {
@Override
public void antiTheft() {
System.out.println("防盗");
}
@Override
public void fireproof() {
System.out.println("防火");
}
@Override
public void waterproof() {
System.out.println("防水");
}
}- SunSafetyDoor.java
public class SunSafetyDoor implements AntiTheft, Fireproof {
@Override
public void antiTheft() {
System.out.println("防盗");
}
@Override
public void fireproof() {
System.out.println("防火");
}
}- StarSafetyDoor.java
public class StarSafetyDoor implements Fireproof,Waterproof{
@Override
public void fireproof() {
System.out.println("防火");
}
@Override
public void waterproof() {
System.out.println("防水");
}
}- Test.java
public class Test {
public static void main(String[] args) {
// 月亮牌安全门
MoonSafetyDoor moonSafetyDoor = new MoonSafetyDoor();
moonSafetyDoor.antiTheft();
moonSafetyDoor.fireproof();
moonSafetyDoor.waterproof();
System.out.println("==============================");
// 太阳牌安全门
SunSafetyDoor sunSafetyDoor = new SunSafetyDoor();
sunSafetyDoor.antiTheft();
sunSafetyDoor.fireproof();
System.out.println("==============================");
// 星星牌安全门
StarSafetyDoor starSafetyDoor = new StarSafetyDoor();
starSafetyDoor.fireproof();
starSafetyDoor.waterproof();
}
}迪米特原则
迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。
但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。
有点类似代理，“最少知道”就是只给类对象并提供方法，而不暴露细节。
例：明星需要工作，日常事务由经纪人负责，无论是粉丝的见面会还是与媒体公司的业务交谈，这里经纪人是明星的‘朋友’，而粉丝和媒体公司是‘陌生人’，所以适合使用迪米特原则。UML类图如下：
实现代码如下：
- Star.java
public class Star {
private String name;
public Star(String name) {
this.name = name;
}
public String getName() {
return name;
}
}- Fans.java
public class Fans {
private String name;
public Fans(String name) {
this.name = name;
}
public String getName() {
return name;
}
}- Company.java
public class Company {
private String name;
public Company(String name) {
this.name = name;
}
public String getName() {
return name;
}
}- Agent.java
public class Agent {
private Star myStar;
private Fans myFans;
private Company myCompany;
public void setMyStar(Star myStar) {
this.myStar = myStar;
}
public void setMyFans(Fans myFans) {
this.myFans = myFans;
}
public void setMyCompany(Company myCompany) {
this.myCompany = myCompany;
}
/**
* 明星与粉丝见面
*/
public void meeting() {
System.out.println(myFans.getName() + "与明星" + myStar.getName() + "见面了。");
}
/**
* 明星与公司见面
*/
public void business() {
System.out.println(myCompany.getName() + "与明星" + myStar.getName() + "商谈业务。");
}
}
- Test.java
public class Test {
public static void main(String[] args) {
// 创建经纪人类对象
Agent agent = new Agent();
// 传递Star、Fans和Company对象
Star star = new Star("初音未来");
agent.setMyStar(star);
Fans fans = new Fans("张三");
agent.setMyFans(fans);
Company company = new Company("歌姬公司");
agent.setMyCompany(company);
// 调用方法
agent.meeting();
agent.business();
}
}合成复用原则
合成复用原则：要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。
- 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
- 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
- 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。
采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点。
- 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
- 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
- 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。
合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。
例：汽车按照“动力源”可以分为汽油汽车、电动汽车等，按“颜色”可以分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这种分类，其组合有6类。如下图UML所示：
实现代码如下：
从上图可以看出用继承关系会产生很多子类，如果再增加动力源如“柴油”、“氢气”等或者添加颜色如“银色”等，会增加更多的子类，并且现需要修改源代码，违背了开闭原则。
采用组合复用原则能解决上述问题，其UML类图如下：
实现代码如下：
- Color.java
public class Color {
String color;
public Color(String color) {
this.color = color;
}
public String getColor() {
return color;
}
public void setColor(String color) {
this.color = color;
}
}- Power.java
public class Power {
String power;
public Power(String power) {
this.power = power;
}
public String getPower() {
return power;
}
public void setPower(String power) {
this.power = power;
}
}- Car.java
public class Car {
protected Color color;
protected Power power;
public Car(Color color, Power power) {
this.color = color;
this.power = power;
}
public void move() {
System.out.println(color.getColor() + power.getPower() + "汽车");
}
}- Test.java
public class Test {
public static void main(String[] args) {
// 设定汽车的颜色和动力源
Color color = new Color("白色");
Power power = new Power("电动");
Car car = new Car(color, power);
// 调用move方法
car.move();
}
}单一职责原则
单一职责原则：规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。
问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。
单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点：
- 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
- 提高类的可读性。复杂性降低，自然其可读性会提高。
- 提高系统的可维护性。可读性提高，那自然更容易维护了。
- 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。
单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。
例：大学学生工作主要包括学生生活辅导和学生学业指导两个方面的工作，其中生活辅导主要包括班委建设、出勤统计、心理辅导、费用催缴、班级管理等工作，学业指导主要包括专业引导、学习辅导、科研指导、学习总结等工作。如果将这些工作交给一位老师负责显然不合理，正确的做 法是生活辅导由辅导员负责，学业指导由学业导师负责。其UML类图如下：
实现代码如下：
- StudentJob.java
public class StudentJob {
public void classCommitteeConstruction() {
System.out.println("班委建设");
}
public void attendanceManagement() {
System.out.println("出勤管理");
}
public void psychologicalCounseling() {
System.out.println("心理辅导");
}
public void feeCollection() {
System.out.println("费用收取");
}
public void classWindConstruction() {
System.out.println("班风建设");
}
public void faq() {
System.out.println("答疑解惑");
}
public void professionalGuidance() {
System.out.println("专业指导");
}
public void studyCounseling() {
System.out.println("学习辅导");
}
public void summarize() {
System.out.println("学习总结");
}
}
我们利用单一职责原则修改后，让辅导员负责学生的生活指导，而让学业导师负责学业指导，分别负责不同的职责。其UML类图如下：
实现代码如下：
- Counselor.java
public class Counselor {
public void classCommitteeConstruction() {
System.out.println("班委建设");
}
public void attendanceManagement() {
System.out.println("出勤管理");
}
public void psychologicalCounseling() {
System.out.println("心理辅导");
}
public void feeCollection() {
System.out.println("费用收取");
}
public void classWindConstruction() {
System.out.println("班风建设");
}
public void faq() {
System.out.println("答疑解惑");
}
}- Tutor.java
public class Tutor {
public void professionalGuidance() {
System.out.println("专业指导");
}
public void studyCounseling() {
System.out.println("学习辅导");
}
public void summarize() {
System.out.println("学习总结");
}
}- StudentJob.java
public class StudentJob {
/**
* 生活辅导
*
* @param teacher 辅导员
*/
public void lifeCounseling(Counselor teacher) {
teacher.attendanceManagement();
teacher.classCommitteeConstruction();
teacher.classWindConstruction();
teacher.faq();
teacher.feeCollection();
teacher.psychologicalCounseling();
}
/**
* 学业指导
*
* @param tutor 学业导师
*/
public void academicGuidance(Tutor tutor) {
tutor.professionalGuidance();
tutor.studyCounseling();
tutor.summarize();
}
}
- Test.java
public class Test {
public static void main(String[] args) {
StudentJob studentJob=new StudentJob();
// 生活辅导
studentJob.lifeCounseling(new Counselor());
// 学业指导
studentJob.academicGuidance(new Tutor());
}
}注意：单一职责同样也适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。
以上是关于设计模式之软件设计原则的主要内容，如果未能解决你的问题，请参考以下文章
跟着盒子的代码设计示例，一起对面向对象的设计模式之SOLID原则加深理解