業務抽象及分層

因為碰到了關于業務抽象和業務分層的一些問題，确實也發現自己在這方面的邏輯思維稍微薄弱了一些，記錄一下抽象和分層的一些思路。

抽象的目的

首先我們做抽象是為了簡化事物，對一種概念或者一種現象進行過濾，去除掉我們不需要的資訊或者多餘的資訊，隻保留其本質。

當然，因為目的的不同，我們的抽象是需要分層次，拿維基百科上的例子來說：

1. 我的12月1日的《舊金山紀事報》
2. 12月1日的《舊金山紀事報》
3. 《舊金山紀事報》
4. 一份報紙
5. 一個出版品

比如說，我們隻想了解這份《舊金山紀事報》的日期和報名，并不想知道是誰的，就會抽象成第2個選項，同理，若我隻想知道這件事物是什麼，将會層層抽到至最簡單最容易了解的層級，一個出版品,，其餘的資訊對我來說都是無用的。

開發中的抽象

在軟體開發中，其實分層就是抽象，不論是底層的作業系統還是往上的程式設計語言都會涉及到分層抽象。

開發中最經典的mvc模型，核心其實就是抽象的分層，軟體開發本身就是不斷抽象的過程。我們把業務需求抽象成資料模型、子產品、服務和系統，面相對象開發時我們抽象出類和對象，面向過程開發時我們抽象出方法和函數。

抽象的原則

1.單一職責原則（Single Responsibility Principle, SRP）

       單一職責是指一個子產品應該隻做一件事，并把這件事做好。其實對照應抽象的定義，可以發現這個原則本身就是抽象的核心展現。如果一個類包含了很多方法，或者一個方法特别長，就要引起我們的特别注意了。例如下面這個 Employee 類，既有業務邏輯（calculatePay）、又有資料庫邏輯（saveToDb），那它其實至少做了兩件事情，也就不符合單一職責原則，當然也就不是一個好的抽象。

2.開放封閉原則（Open/Closed Principle, OCP）

       開放封閉原則是指對擴充開放，對修改封閉。當需求改變時，我們可以擴充子產品以滿足新的需求；但擴充時，不應該需要修改原子產品的實作。

3.依賴倒置原則（Dependency Inversion Principle, DIP）

       依賴倒置原則是指高層子產品不應該依賴于低層子產品的實作，兩者都應該依賴于抽象。抽象不應該依賴于細節，細節應該依賴與抽象。前面提到，“軟體領域的任何問題，都可以通過增加一個間接的中間層來解決” ，DIP 就是最典型的增加中間層的方式，也是我們需要解耦兩個子產品的最重要的方法之一。

4.裡氏替換原則（Liskov Substitution Principle, LSP）

       裡氏替換原則是指子類必須能夠替換成它們的基類。

5.接口隔離原則（Interface Segregation Principle, ISP）

       接口隔離原則是指用戶端不應該被迫依賴它們不使用的方法。