设计模式原则

最新推荐文章于 2024-02-19 11:30:24 发布
最新推荐文章于 2024-02-19 11:30:24 发布
阅读量104 收藏
点赞数
分类专栏： 设计模式 文章标签： 设计模式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/t194978/article/details/123466568
版权

文章目录

单一职责

应该有且仅有一个原因引起类的变更。

例如，设计一个视频播放系统，要求：如果是VIP用户就播放完整影片，否则只允许试看5分钟。

class VideoService {

	public void play(Long videoId, Long userId) {
		if (haveAuth(userId)) {
			System.out.println("播放完整影片...");
		}else {
			System.out.println("试看5分钟...");
		}
	}

	public boolean haveAuth(Long userId){
		// 判断用户是否是VIP
		return true;
	}
}

这个类的设计明显不符合单一职责，它做了两件事情：1.视频的播放、2.权限的判断。

如果非会员从原来的试看5分钟提升至10分钟，play的逻辑是不是要修改？
谁说只有VIP才可以观看完整影片，如果允许用户付费解锁单个影片呢？haveAuth是不是要修改？

这就已经有两个原因会引起类的变更了，你能百分百保证其中一个逻辑的变更不会影响到另外一个逻辑的运行吗？这通常很难保证，需求变更时，改动的代码应该越少越好。

将职责进行拆分，AuthService负责权限，VideoService负责视频的播放：

class VideoService {
	AuthService authService = new AuthService();

	public void play(Long videoId, Long userId) {
		if (authService.haveAuth(userId)) {
			System.out.println("播放完整影片...");
		}else {
			System.out.println("试看5分钟...");
		}
	}
}

class AuthService{
	
	public boolean haveAuth(Long userId){
		// 用户是否是VIP？ or  用户是否购买单个影片？
		return true;
	}
}

现在，VideoService职责很清晰，有权限就播放完整影片，没权限就试看，至于用户是VIP还是购买了单个影片，它完全不关心。

单一职责的优点：

  • 类的复杂性降低，实现什么职责都有清晰明确的定义。
  • 可读性提高。
  • 可维护性提高。
  • 变更引起的风险降低。

事实上，VideoService的职责还可以进行拆分，它本应该只负责视频的播放，至于是完整影片还是5分钟，这其实也属于业务逻辑。但是在实际的开发中，拆分到这一层差不多就可以了，职责拆分的过细，会导致类文件的激增，类间的结构会变得复杂，开发成本会上升。
一个类的职责到底有哪些？这通常很难有一个明确的定义，需要结合实际情况来设计。

单一职责的核心就是拆分，职责的拆分，它不仅适用于类，也适用于方法，每一个方法的功能都应该是相互独立，职责清晰的，这不仅提高了程序的可读性和可维护性，方法的复用性也会提高。一个功能过于“丰富”的方法，通常很难被复用。

里氏替换原则

所有引用基类的地方必须能透明地使用其子类的对象。

子类可以扩展父类的功能，但不能改变父类原有的功能。

例如系统在发送短信时，需要将发送记录保存到数据库中，如果子类重写了父类的方法，修改了业务逻辑，日志记录功能将会丢失，这是非常危险的。

class SmsService{

	public void sendMessage(String target) {
		System.out.println("发送短信前记录日志...");
		System.out.println("发送短信...");
	}
}

class MySmsService extends SmsService {

	@Override
	public void sendMessage(String target) {
		System.out.println("子类发送短信...");
	}
}

一种较好的解决办法是，将公共的代码提取到基类，然后预留一个钩子函数交给子类扩展：

class SmsService{

	// 发送短信，final，禁止子类重写
	public final void sendMessage(String target) {
		System.out.println("发送短信前记录日志...");
		System.out.println("发送短信...");
		hook();
	}

	protected void hook(){
		// 钩子函数，父类什么也不做，子类扩展
	}
}

class MySmsService extends SmsService {

	@Override
	protected void hook() {
		System.out.println("短信发送后的增强...");
	}
}

继承的优点：

  1. 代码共享。
  2. 提高代码的复用性。
  3. 提高类的开放性，可以被子类增强。

继承的缺点：

  1. 较强的侵入性，子类必须拥有父类的所有方法和属性。
  2. 增加了耦合，父类的特性改变，子类也必须跟着改变。

继承有它的优点，自然也有它的缺点，如果子类不能完整的实现父类的方法，或者父类的方法在子类的实现中“变味儿”了，则建议断开继承关系，采用依赖、组合等关系来代替。

依赖倒置原则

  1. 高层模块不依赖低层模块，而是互相依赖其抽象。
  2. 抽象不依赖细节，细节依赖于抽象。

通常一个业务逻辑会由N个原子逻辑组成，原子逻辑是不可分割的，也就是低层模块，由N个原子逻辑组成的业务逻辑就是高层模块。
例如：用户下订单是一个高层模块，下单需要发起支付，扣减库存等操作就是低层模块，订单服务应该依赖支付、库存服务的接口，而不是实现细节。说白了就是：面向接口编程。

如下示例，是一个订单服务：

// 订单服务
class OrderService {
	AliPay pay = new AliPay();

	// 下单
	public void order() {
		// 支付
		pay.pay();
		// 发货......
	}

}

class AliPay {
	void pay() {
		System.out.println("使用支付宝支付...");
	}
}

没有将支付抽象出来，订单服务直接依赖AliPay实现，导致程序难以扩展。
如果要接入微信支付呢？所有涉及到支付的地方都需要修改，风险太大。
有支付就有退款，你没办法强制要求所有的支付服务都实现退款功能，说白了系统没有将支付服务规范起来。

基于依赖倒置原则，程序可以优化如下：

// 订单服务
class OrderService {
	private Pay pay;

	public OrderService(Pay pay) {
		this.pay = pay;
	}

	// 下单
	public void order() {
		// 支付
		pay.pay();
		// 发货......
	}

}

interface Pay {
	// 支付
	void pay();

	// 退款
	void refund();
}

class AliPay implements Pay{

	@Override
	public void pay() {
		System.out.println("支付宝支付...");
	}

	@Override
	public void refund() {
		System.out.println("退款到支付宝账户...");
	}
}

class WeChat implements Pay{

	@Override
	public void pay() {
		System.out.println("微信支付...");
	}

	@Override
	public void refund() {
		System.out.println("退款到微信账户...");
	}
}

定义Pay接口，将支付服务规范化，涉及到支付业务的只依赖接口，不依赖具体实现。程序的扩展性得到提高，更换第三方支付业务，只需要实现Pay接口，通过构造器传入即可，其他代码都不用动。

当支付服务的规则有变更时，修改接口，所有的实现类都必须做相应的调整，否则编译会不通过，这就是实现依赖于抽象，低层依赖于高层，依赖倒置了。

为了满足依赖倒置原则，开发的时候尽量遵循如下规则：

  1. 类尽量有抽象父类或接口。
  2. 变量、形参尽量是抽象类或接口。
  3. 尽量不要从具体类再派生出子类。
  4. 尽量不要重写基类方法，会影响依赖的稳定性。
  5. 结合里氏替换原则使用，可以用子类对象透明的代替基类对象。

接口隔离原则

  1. 客户端不应该依赖它不需要的接口。
  2. 类间的依赖关系应该建立在最小的接口上。

接口尽量细化，建立单一接口，避免定义过度“臃肿而庞大”的接口。

如下示例，设计一个个人博客系统，普通用户只能查看博客，而管理员则可以增删改查。

interface IBlogService {

	void add();

	void delete();

	void update();

	void select();
}

class UserBlogService implements IBlogService{

	@Override
	public void add() {
		// 普通用户不能新增
	}

	@Override
	public void delete() {
		// 普通用户不能删除
	}

	@Override
	public void update() {
		// 普通用户不能修改
	}

	@Override
	public void select() {
		System.out.println("普通用户只能查看博客...");
	}
}

class AdminBlogService implements IBlogService{

	@Override
	public void add() {
		System.out.println("管理员新增博客...");
	}

	@Override
	public void delete() {
		System.out.println("管理员删除博客...");
	}

	@Override
	public void update() {
		System.out.println("管理员更新博客...");
	}

	@Override
	public void select() {
		System.out.println("管理员查看博客...");
	}
}

显然，普通用户UserBlogService被迫实现了它不需要实现的接口，IBlogService应该被拆分为两个接口，一个定义查看，一个定义管理维护。

// 只可查看
interface IReadBlogService {

	void select();
}

// 支持增删改查
interface IAdminBlogService extends IReadBlogService{
	
	void add();
	
	void delete();
	
	void update();
}

// 普通用户只能查看
class UserBlogService implements IReadBlogService{
	@Override
	public void select() {
		System.out.println("普通用户只能查看博客...");
	}
}

// 管理员不仅能看，还能增删改
class AdminBlogService implements IAdminBlogService {

	@Override
	public void add() {
		System.out.println("管理员新增博客...");
	}

	@Override
	public void delete() {
		System.out.println("管理员删除博客...");
	}

	@Override
	public void update() {
		System.out.println("管理员更新博客...");
	}

	@Override
	public void select() {
		System.out.println("管理员查看博客...");
	}
}

要做到极致的接口隔离原则，就是一个接口只有一个方法，但是开发中我们绝不会这么去做，粒度太小了，导致接口数量剧增，难以开发。但是接口粒度太大灵活性会降低，所以如何定义好一个接口的粒度需要开发人员长期的实践和经验积累。

迪米特法则

也被称为：最少知道原则：一个类应该对它依赖的类了解的越少越好。

迪米特法则的核心是：只与朋友交流。它的目的是减少类间的依赖，提高内聚，降低耦合。
朋友类的定义：成员变量，方法的入参、出参属于朋友类，出现在方法体内部的则不是朋友类。

一个类应该对其所依赖的类知道的越少越好，你的内部实现不管多复杂我并不关心，我只管调用你的public方法。

示例，创建一个缓存容器，缓存有三种淘汰策略，分别是：FIFO、LFU、LRU。

// 缓存接口
interface Cache{

	void something();
}

class FIFOCache implements Cache{

	@Override
	public void something() {
		System.out.println("先进先出的缓存...");
	}
}

class LFUCache implements Cache{

	@Override
	public void something() {
		System.out.println("最少使用缓存...");
	}
}

class LRUCache implements Cache{

	@Override
	public void something() {
		System.out.println("最久未使用缓存...");
	}
}

定义缓存枚举和缓存工厂，来获取缓存容器对象：

enum CacheType{
	FIFO,
	LFU,
	LRU
}

class CacheFactory{
	public static Cache create(CacheType type) {
		switch (type) {
			case FIFO:
				return new FIFOCache();
			case LFU:
				return new LFUCache();
			case LRU:
				return new LRUCache();
			default:
				return null;
		}
	}
}

客户端使用：

public class Client {
	public static void main(String[] args) {
		Cache cache = CacheFactory.create(CacheType.FIFO);
	}
}

客户端除了依赖于CacheFactory，还依赖于CacheType。这不符合迪米特法则，客户端应该只和CacheFactory打交道就够了。

因此CacheFactory可以做如下优化：

class CacheFactory{
	
	public static Cache createFIFO(){
		return new FIFOCache();
	}
	
	public static Cache createLFU(){
		return new LFUCache();
	}
	
	public static Cache createLRU(){
		return new LRUCache();
	}
}

客户端调用：

public class Client {
	public static void main(String[] args) {
		Cache fifo = CacheFactory.createFIFO();
		Cache lfu = CacheFactory.createLFU();
		Cache lru = CacheFactory.createLRU();
	}
}

这样客户端就只依赖CacheFactory了，方法名见名知意，降低了耦合，缺点是加了新的淘汰策略的容器需要修改CacheFactory。

开闭原则

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
大白话就是：对于一个程序而言，应该通过扩展来实现需求变化，而不是修改现有的代码。

一个软件产品，开发完成上线后会进入漫长的维护期，期间还会遇到各种需求变化，需要对软件进行维护升级，开发者在设计程序的时候要尽量适应变化，以提高软件的稳定性和扩展性。

面对变化，最直接的方式就是修改现有代码，但是它的风险是很大的，你很难保证依赖这一块代码的其他功能不会受到影响，因此测试人员必须对所有可能受到影响的功能重新测试一遍，成本太大了。

另一种方式，就是通过派生类来做扩展，在原有的功能之上做增强，以满足客户的新需求。

例如设计一个商城系统，支持添加商品，计算总额并输出订单详情：

@Getter
class Goods {
	private String name;//商品名
	private BigDecimal price;//价格
	private BigDecimal actuallyPaid;//实付

	public Goods(String name, BigDecimal price) {
		this.name = name;
		this.price = price;
		this.actuallyPaid = price;
	}

	public void setActuallyPaid(BigDecimal actuallyPaid) {
		this.actuallyPaid = actuallyPaid;
	}
}

// 订单
class Order{
	private List<Goods> list = new ArrayList<>();
	private BigDecimal totalMoney;//总金额

	// 添加商品
	public void addGoods(Goods goods){
		list.add(goods);
	}

	// 支付
	public void pay() {
		BigDecimal sum = BigDecimal.ZERO;
		for (Goods goods : list) {
			sum = sum.add(goods.getPrice());
		}
		totalMoney = sum;
	}

	// 输出订单详情
	public void print() {
		System.out.println("商品\t原价\t实付");
		for (Goods goods : list) {
			System.out.println(goods.getName()+"\t"+goods.getPrice()+"\t"+goods.getActuallyPaid());
		}
		System.out.println("总价:" + totalMoney);
	}
}

客户端使用：

public class Client {
	public static void main(String[] args) {
		Order order = new Order();
		order.addGoods(new Goods("苹果",BigDecimal.valueOf(100)));
		order.addGoods(new Goods("香蕉",BigDecimal.valueOf(200)));
		order.addGoods(new Goods("橘子", BigDecimal.valueOf(150)));
		order.pay();
		order.print();
	}
}

商品	原价	实付
苹果	100	100
香蕉	200	200
橘子	150	150
总价:450

程序很简单，那如果遇到双11，推出了【满300减40】的优惠活动，程序要如何处理？直接修改Order::pay()逻辑吗？那如果双11过去了，恢复到原价购买呢？再把支付逻辑改回来吗？累不累？？？

优化一下，将Order抽象出来，定义为接口：

interface Order {

	// 添加商品
	void addGoods(Goods goods);

	// 支付
	void pay();

	// 输出订单信息
	void print();
}

编写一个抽象订单类，实现公共的业务逻辑：

abstract class AbstractOrder implements Order {
	protected List<Goods> list = new ArrayList<>();
	protected BigDecimal totalMoney;

	@Override
	public final void addGoods(Goods goods) {
		list.add(goods);
	}

	@Override
	public final void print() {
		System.out.println("商品\t原价\t实付");
		for (Goods goods : list) {
			System.out.println(goods.getName() + "\t" + goods.getPrice() + "\t" + goods.getActuallyPaid());
		}
		System.out.println("总价:" + totalMoney);
	}
}

平价订单实现：

// 平价订单
class ParOrder extends AbstractOrder {

	@Override
	public void pay() {
		BigDecimal sum = BigDecimal.ZERO;
		for (Goods goods : list) {
			sum = sum.add(goods.getPrice());
		}
		totalMoney = sum;
	}
}

折扣订单实现：

// 折扣订单 满300减40，上不封顶
class DiscountOrder extends AbstractOrder {

	@Override
	public void pay() {
		BigDecimal originalPrice = BigDecimal.ZERO;
		for (Goods goods : list) {
			originalPrice = originalPrice.add(goods.getPrice());
		}
		totalMoney = originalPrice.subtract(BigDecimal.valueOf(Math.floorDiv(originalPrice.intValue(), 300) * 40));
		for (Goods goods : list) {
			// 计算单个商品的实付，方便退款
			goods.setActuallyPaid(
					goods.getPrice()
							.divide(originalPrice,2,BigDecimal.ROUND_HALF_UP)
							.multiply(totalMoney));
		}
	}
}

客户端使用：

public class Client {
	public static void main(String[] args) {
		Order order = new DiscountOrder();//折扣订单
		order.addGoods(new Goods("苹果", BigDecimal.valueOf(100)));
		order.addGoods(new Goods("香蕉", BigDecimal.valueOf(200)));
		order.addGoods(new Goods("橘子", BigDecimal.valueOf(100)));
		order.pay();
		order.print();
	}
}
商品	原价	实付
苹果	100	90.00
香蕉	200	180.00
橘子	100	90.00
总价:360

只要更换订单实现即可，其他地方都不用动，以后如果有新的折扣活动，继续增加实现类即可。

开闭原则是一个比较“虚”的原则，它没有告诉我们应该如何去实现。事实上，它是软件设计的一个目标，只要开发者遵循了前面五大设计原则，善用23种设计模式，就是在遵循开闭原则，设计出来的软件一定是对扩展开放，对修改关闭的。

开闭原则的核心是：封装程序中变与不变的地方。用接口或抽象来封装规则，描述契约，这是基本稳定不变的，通过派生子类来实现细节，扩展功能，这是易变的，尽量依赖抽象，避免依赖实现。

如来神掌十八式
关注
专栏目录
设计模式以及用户登陆注册页面
06-01
设计模式的简单介绍 有助于大家了解java设计模式 。
设计模式六大原则
程序员小潘
12-23 804
文章目录单一职责里氏替换原则依赖倒置原则接口隔离原则迪米特法则开闭原则 单一职责 应该有且仅有一个原因引起类的变更。 例如，设计一个视频播放系统，要求：如果是VIP用户就播放完整影片，否则只允许试看5分钟。 class VideoService { public void play(Long videoId, Long userId) { if (haveAuth(userId)) { System.out.println("播放完整影片..."); }else { System.o
程序设计--设计模式六大原则
qq_41807126的博客
01-29 767
程序设计--23种设计模式设计模式设计模式六大原则单一职责原则（Single Responsibility principle）里氏替换原则（Single Responsibility principle）迪米特法则（Single Responsibility principle）使用扩展 设计模式 面向对象语言开发过程中，遇到各种场景和问题的解决方案和思路，沉淀下来就是设计模式（套路） 设计模式...
六大设计模式原则-迪米特法则
qq_34222160的博客
03-16 1万+
一、迪米特法则定义 迪米特法则又最少知识原则，其定义如下： 迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少的与其他实体发生相互作用。 二、迪米特法则描述 如果一个系统满足迪米特法则，那么当其中一个软件实体发生变化时，就会尽量少的影响其他软件实体，扩展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可以降低系统的耦合度，使类与类之间保持松耦合状态。 迪米特法则还有几种定义形式，包括：不要和"陌生人"说话、只与你的直接朋友通信等
设计模式——七大设计原则
weixin_43412762的博客
12-05 3047
设计模式的七大原则：开闭原则、里氏代换原则、依赖倒转原则、接口隔离原则、合成复用原则、迪米特法则
六大设计模式原则-接口隔离原则
qq_34222160的博客
03-17 7522
一、接口隔离原则定义 接口隔离原则定义如下： 接口隔离原则(Interface Segregation Principle, ISP)：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。 二、接口隔离原则描述 根绝接口隔离原则，当一个接口太大时，我们需要将它分割成一些细小的接口，使用该接口的客户端只需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色，不干不该干的事情，干该干的事请。这里的"接口"往往有两种不同的定义：一种是指一个类型所具有的方法特征的集合，仅仅是一种
设计模式七大原则
java123456111的博客
05-18 4612
1、设计模式的目的 ​ 编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性 等多方面的挑战，设计模式是为了让程序(软件)，具有更好 ​ 1) 代码重用性 (即：相同功能的代码，不用多次编写) ​ 2) 可读性 (即：编程规范性, 便于其他程序员的阅读和理解) ​ 3) 可扩展性 (即：当需要增加新的功能时，非常的方便，称为可维护) ​ 4) 可靠性 (即：当我们增加新的功能后，对原来的功能没有影响) ​ 5) 使程序呈现高内聚，低耦合的特性 2、设计模式七大原则 ​ 设计模
详细介绍设计模式七大原则
最新发布
m0_54187478的博客
02-19 2556
单一职责原则：一个类应该只有一个引起它变化的原因。开闭原则：软件实体应对扩展开放，对修改封闭。里氏替换原则：子类型必须能够替换掉它们的基类型。依赖倒置原则：高层模块不应依赖于低层模块，两者都应依赖于抽象；抽象不应依赖于细节，细节应依赖于抽象。接口隔离原则：使用多个专门的接口比使用单一的总接口更好。合成/聚合复用原则：尽量使用对象的组合/聚合，而不是继承关系达到复用的目的。迪米特法则（最少知道原则）：一个对象应对其他对象有尽可能少的了解。
设计模式与设计原则.pdf
09-17
本文件《设计模式与设计原则.pdf》中，将详细地探讨设计模式以及与之相关的六大设计原则。 首先，设计模式主要分为三类： 1. 创建型模式（Creational patterns）：这些模式提供了一种在创建对象的同时隐藏创建逻辑...
JAVA 24种设计模式介绍与6大设计原则.pdf
04-12
在这些设计模式和原则中，策略模式是一个非常重要的行为型设计模式，它定义了一系列算法，并将每个算法封装起来，使它们可以相互替换使用。策略模式让算法的变化独立于使用算法的客户端。 以提供的文档内容为例，...
设计模式之六大原则详解，Markdown笔记
11-18
详细介绍了设计模式六大原则，配有示例代码和图片，有开闭原则，单一职责原则，里氏替换原则，依赖倒置原则，接口隔离原则，迪米特法则等等。
Java设计模式之七大设计原则
热门推荐
qq_49529322的博客
04-28 1万+
Java设计模式之七大设计原则 本文对Java设计模式中的七大设计原则进行汇总介绍，提炼最核心的概念。 设计模式总结笔记 一、设计模式七大原则 设计模式的目的： 代码可重用性：相同功能的代码，不用多次编写。 可读性：编程规范性，便于其他程序员的阅读和理解。 可扩展性：当需要增加新的功能的时候，非常方便，称为可扩展性。 可靠性：当我们新增功能后，对原来的功能没有影响。 使程序呈现高内聚、低耦合特性。 1.1、单一职责原则 不遵守单一职责原则： 对类来说的，就是一个类应该只负责一项职责。 比如：Us
Java设计模式六大原则
流楚丶格念的博客
10-16 1545
单一职责原则：一个类，应当只有一个引起它变化的原因；即一个类应该只有一个职责里氏替换原则：所有引用基类的地方必须能透明地使用其子类对象。依赖倒置原则：高层模块不应该依赖低层模块，两者都依赖其抽象；抽象不依赖细节；细节应该依赖于抽象。接口隔离原则：客户端不应该依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上。迪米特法则：是一个对象应当对其他对象尽可能少的了解，如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用；
UML类图几种关系的总结
t194978的博客
04-23 2044
在UML类图中，常见的有以下几种关系:泛化（Generalization）,  实现（Realization）,关联（Association）,聚合（Aggregation）,组合(Composition)，依赖(Dependency)   1.泛化(Generalization) 【泛化关系】：是一种继承关系,它指定了子类如何特化父类的所有特征和行为例如：老虎是动物的一种. ...
【转载】组合模式-系统菜单的设计
t194978的博客
03-13 1411
1. 系统菜单的设计 「系统菜单」应该是所有ERP系统都必备的一个基础模块，反正我是没见过哪个ERP系统是没有菜单设计的。典型的设计就是一个「树状结构」，数据库表用一个parent_id来构建整棵菜单树。 既然「菜单设计」如此重要，那么今天就来讲讲如何利用「组合模式」来优雅的设计系...
【转载】观察者模式
t194978的博客
03-13 915
1. 买家支付完成后的N个通知 随着电商的大热，网上购物已经深入寻常百姓家了，现在的年轻人，甚至是长辈老人都已经习惯于网购了，随着用户「支付成功」的一声提醒，电商背后就开始忙碌起来了。今天就通过支付的例子来理解「观察者模式」的强大之处。 真正的电商系统不是一篇文章可以说的清楚的，...
设计模式原则 java
10-13
设计模式原则是指在软件设计过程中，为了提高代码的可读性、可复用性、可维护性等方面而遵循的一些准则。常见的设计模式原则包括单一职责原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则和迪米特法则。 ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值