软件架构设计原则一切都是为了下面这两点,别忘了。
这一篇文章我们将要来谈谈 ISP 介面隔离原则。
它的定义如下 :
不应该强迫 client 依赖他们不需要的方法
这个原则事实上很好理解,重点我自已觉得可以条列成以下几项 :
然後在来想想,如果没有这个原则可能会发生什麽事情呢 ?
这里我们简单说个平常应该不少人会用到的范例模式,就是一个 service 层的某个东东,里面包了一大陀的方法,只要是和 Cart 购物车有关的都丢里面。
// Bad
class CartService {
add(product: any): void{
console.log('A product add to cart')
}
remove(product: any): void{
console.log('A product remove to cart')
}
checkout(): void {
console.log('checkout the cart')
}
}
const cartService = new CartService()
cartService.add('A')
cartService.remove('B')
cartService.checkout()
// Good
interface ICartItemOperator{
add(product: any): void
remove(product: any): void
}
interface ICartPurchase{
checkout(): void
}
class CartService implements ICartItemOperator, ICartPurchase{
add(product: any): void{
console.log('A product add to cart')
}
remove(product: any): void{
console.log('A product remove to cart')
}
checkout(): void {
console.log('checkout the cart')
}
}
const cartService: ICartItemOperator = new CartService()
cartService.add('A')
cartService.remove('B')
老样子,来问一下三个问题,来加深记忆
事实上 ISP 原则让我想到谍报组织的建立基础,就是只让需要知道情报的人知道它『 需要知道 』的情报,这也避免了某位情报人员知道人它不需要知道的情报,而发生无法预期的错误。
感觉这个 ISP 可以用在更多领域。
事实上我觉得 ISP 介面隔离原则,很接近 SRP 单一职则原则,记不记得 SRP 的定义为 :
一个 『 类别 』只有一个『 角色 』引起『 变化 』
这里事实上可以将 client 当成『 角色 』也就是使用这个物件的地方,以上述范例 CartService 来看,它事实上可以分为两种角色 :
那如果往这里思考是不是,就感觉可以拆两个呢 ? 不过这也只是我自已的想法。
昨天介绍了velero的概念,今天来配置一套velero出来看看吧。 配置velero非常的简单,只...
今天开始做我们的 Telegram Bot! Telegram Telegram 是一个通讯软件,就...
时间飞逝,已到第14天了 明天就一半ㄌ,好感动眼睛流汗 今天我们要干大事!!! 要来解 REVERS...
前言 今天我们要来讲 ROS 中最为核心的部分,ROS 提供了 四种通讯方式,分别为 Topic、S...
Laravel 路由 基本路由 首先看到rotues资料夹里的web.php,会看到这些程序码 Ro...