2017-09-24 86 views
1

單一職責原則(SRP): -在課堂上應用單一責任原則?

每個班級都應該承擔一個責任。基本上,應該有一個單一的理由來改變。我不確定 最後的聲明究竟意味着什麼。我的解釋是,設計類的方式應該有一個單一的理由來改變,因爲每種方法都是一種行爲,因此也是一種理由。那是對的嗎?如果不是什麼確切的原因定義?

考慮一個股票交易所繫統,其中大部分開發者提出設計,其中StockService.java同時具有買入和賣出方法。這裏將有兩方面的原因(買入和賣出),以改變這一類

public class StockService { 

    private String name = "ABC"; 
    private int quantity = 10; 

    public void buy(){ 
     System.out.println("Stock [ Name: "+name+", 
     Quantity: " + quantity +" ] bought"); 
    } 
    public void sell(){ 
     System.out.println("Stock [ Name: "+name+", 
     Quantity: " + quantity +" ] sold"); 
    } 

    // other methods related to socks 
} 

要遵循SRM原則,我需要拿出單獨的類,其中StockBuyService.java(含團購相關的方法)和StockSellService(含賣出相關方法)。是嗎 ?

+1

的方法的數量是不相關的因素。參見[適用於功能單一職責原則]關於軟件工程SE(https://softwareengineering.stackexchange.com/questions/275646/is-the-single-responsibility-principle-applicable-to-functions)。它與用例中的角色或角色有關,而與方法的數量無關。 – MatsLindh

回答

0

不一定。當您考慮該課程的目的是StockService時,buy()sell()方法合在一起。從名稱來看,期望庫存服務處理來自投資者的交易請求是合理的,並且這些交易請求可以是buy()sell()。 (事實上​​,使用單一方法trade()的庫存服務可能會違反界面隔離原則,具體取決於實施方式。)

可能存在將此類內部的買賣分開的情況,那就是如果你必須一起處理所有類型的交易,還要爲每種類型實施不同的規則或規定。在這種情況下,您可能會考慮使用戰略模式,該模式使用多態性來實現基於正在發生的交易類型的規則。但是你的樣本班級沒有涉及到這些細節,所以按照YAGNI principle,你還沒有。

但是,既然您提出了這個問題,那麼這個名稱可能不夠清楚。 (在重構實踐中,這被稱爲代碼異味。)現在是審查它的好時機,並問自己該類是否被正確命名。這是真正的股票服務嗎?如果這個班級被命名爲StockTradingService,你會不確定嗎?你能想出一個更清晰的名字,更清楚地表達這個班級服務的目的嗎?我不是說這是一個壞名字,或者它必須改變;我只是說,你應該認識到,不得不提出這個問題應該在你的腦海裏提出一點「謹慎」的標誌。

0

首先,正如@MatsLindh所評論的,評估SRP時,方法的數量並不是一個因素。

讓我們來調查StockService!如果您希望您的StockService承擔一項責任,那麼您應該發現通常意味着您必須在適當的服務抽象層上定義一個簡單目標。

例如,StockService的目標可以是管理交易,換句話說,描述交易的流程。在這種情況下,會的StockService是這樣的:

public class StockService{ 
    PriceService priceService; 
    AccountService accountService; 
    Stock stock 

    public void buy(int amount){ 
    int fullPrice = getFullPrice(amount); 
    if(accountService.hasEnoughMoney(fullPrice){ 
     accountService.buyStock(stock, amount, fullPrice) 
    } 
    } 
    public void sell(int amount){ 
    accountService.sellStock(stock,amount) 
    } 
    private int getFullPrice(int amount){ 
    return amount * priceService.getPrice(stock); 
    } 
} 

正如你可以看到類只有一個責任:管理貿易。它不知道任何細節(如何執行支票或購買)。 更改班級的唯一原因是交易流量發生變化。

在我看來,SRP就是發現抽象的適當水平,以確定一個目標,實現儘可能少的代碼或邏輯儘可能覆蓋目標,讓其他班做休息。