軟體架構設計原則一切都是為了下面這兩點,別忘了。
這一篇文章我們將要來談談 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 來看,它事實上可以分為兩種角色 :
那如果往這裡思考是不是,就感覺可以拆兩個呢 ? 不過這也只是我自已的想法。