糟糕的OOP有很多類只有1或2種方法

這是一個壞設計的標誌，你有很多隻有1或2種方法的類嗎？糟糕的OOP有很多類只有1或2種方法

我想學習OOP設計並創建了一個小應用程序（很小）。

它已經結束了相當多的類實現接口，只包含1或2個方法。

它感覺很好分離，但它似乎不好，類有這麼幾個方法。

我知道每種情況都會有所不同，但從一般觀點來看，這種情況不好嗎？

應用的一小部分來確定時間表喂狗（跛我知道）：

所以我試圖實施的策略模式在這裏：

class DogFeedController 
{ 
    protected $strategy = null; 

    public function __construct(iDogFeedStrategy $strategy) { 
     $this->strategy = $strategy; 
    } 

    public function getFeedingSchedule() { 
     $morningFeeds = $this->strategy->generateMorningFeeds(); 
     $eveningFeeds = $this->strategy->generateEveningFeeds();  
    } 

} 


class GeneralFeedStrategy implements iDogFeedStrategy 
{ 
    public function generateMorningFeeds() { 
     //do stuff here 
    } 

    public function generateEveningFeeds() { 
     //do stuff here 
    } 
}

來源

2012-08-23 Marty Wallace

這真的取決於。很高興看到一些具體的例子。 –

我已經更新了應用程序中的一個小例子，其中突出顯示了我正在談論的內容。 –

@ user1189880它確實**不**突出一件事:)。有一個或兩個公共職能的課程是一件好事。但是他們不能太久（因爲他們會變得很難理解），所以只要有可能和需要 - 從私有功能中提取一些相關的邏輯。 – dantuch

如果它太多，你必須測量自己。面向對象是以有意義和現實世界的方式分離邏輯的好方法，但它也可能達到對可維護性產生負面影響的一個點，並且在這一點上應用不正確。

想想應用程序的去向。它總是會成爲一個小應用程序？如果是這樣，你不需要創建很多非常通用的接口。嘗試將它們合併，如果只有一個類正在實現該接口，則可能完全刪除該接口。

如果您預計您的應用程序將大幅增長，則接口可能實際上有助於您在將來維護和添加功能。例如，如果您創建了一個管理只有汽車停車位的汽車的應用程序，那麼如果您預計增長到不同類型的車輛（例如，摩托車只佔用一半的停車位），您可能需要創建一個通用汽車界面。也就是說，在項目開始時，您不應該試圖涵蓋所有可能的需求變化，並且使代碼太抽象。衡量需求變化的風險可以幫助您預測需要抽取哪些代碼。

如果您是團隊中的軟件工程師，請繪製您的設計圖並向同事展示以獲取他們的意見。

最後，請注意code smells。

來源

2012-08-23 17:29:16 Samuel

我覺得這個問題你應該問你自己是。這個班級是負責它在做什麼？能夠識別和分離責任是OOP的基石。例如，您可以使用只有一種方法創建隨機密碼的Security類。

我認爲（這是我的觀點），如果隨機密碼僅用於註冊表中，而不是創建該類的私有方法，那麼我會將該方法分爲新類Security，因爲我不喜歡認爲這不是Register類的責任。

此外，由於你的應用程序是一個小應用程序，因此每個類只有幾個方法可能是完全正常的。

編輯：看到您的代碼我可以提出一些建議，但請記住，我看不到整個圖片。

如果你還沒有，你應該閱讀關於MVC pattern，你可能沒有在你的應用程序的意見，但分離控制器與模型是一個很好的做法。您的DogFeedController似乎是一個控制器，GeneralFeedStrategy模型。我喜歡用他們的名字來結束我的課程名稱。例如，UserController,UserView和UserModel。我認爲這讓事情變得清晰，但這又是我的看法。

我沒有看到有iDogFeedStrategy的觀點，但我再次看不到整個圖片。接口的基本用法是確保一組類，不管它們有多不同，它們將具有相同的API並且封裝實現接口的每個類的細節。

來源

2012-08-23 17:25:20 eversor

控制器不是mvc意義上的控制器。也許糟糕的措辭部分，也許經理或發電機將是一個更好的詞來形容它。 iDogFeedStrategy是我試圖實現的策略模式的一部分，GeneralFeedStrategy是一個具體的例子 –

@ user1189880好的，我知道了，那麼你展示的這個部分看起來很好編程。儘管如果沒有所有的代碼，仍然很難評估它.... – eversor

除了關注點分離之外，面向對象的另一個重要方面是類內聚。班級應該「拉動自己的體重」，而不是讓許多其他的東西稱之爲「吸氣者」，並對信息做些什麼。如果你想要多態行爲，或者你計劃將來擴展你的應用程序，可以創建接口。不要爲了分離而創建接口。如果接口不是由兩個或多個子類實現的，請將其除掉。（您也可以使用接口來應用依賴性倒置原則，以打破依賴性循環）

OOP中的設計決策應始終有意識地解決特定問題。否則，保持簡單。

來源

2012-08-23 17:41:29 ryan0

從一般的觀點來看，兩個級別太大或者相反太小都被認爲是不好的做法，並且被稱爲所謂的Code Smells。這兩個我指的是大班（又名上帝對象）和懶惰類（又名吃白食）。

下面是從Wikipedia的定義和Coding Horror：

大班：已經長得太大的一類。

與長方法一樣，大類很難閱讀，理解和排除故障。這個班級是否包含太多的責任？大班可以重組或分成小班嗎？

和

懶類：一類是確實太少了。

類應該拉他們的重量。每增加一個班級都會增加項目的複雜性。如果你的班級沒有足夠的資金來支付自己的費用，它是否可以被摺疊或合併到另一個班級中？

在另一方面，有一個叫接口分離原則的面向對象設計一個原則，指出：「客戶端不應該被迫依賴於它們不使用方法」。在你的情況下，使用更少方法的接口實際上符合這個原則。

總結以上，你的設計是非常正確的。使用較少方法的接口是很好的，以便實現這些接口的類不必實現所有方法以及它們不使用的方法。至於班級，我相信他們最終會變得更大。請記住，實現一個接口並不意味着您不能擁有比在已實現的接口中定義的方法更多的方法。也就是說，試着在那裏放更多的邏輯。

更多關於固體，面向對象的設計原則，可以在Wikipedia上找到。

PS。代碼嗅覺是糟糕設計的症狀，SOLID就是治療。

來源

2012-08-23 18:22:16 zafarkhaja

由於這有利於可維護性，因此偏好大量具有複雜關係的小物體，而這些小物體具有簡單的關係，並且它爲將來的更改做好了準備。

您的設計對我來說看起來非常好，甚至更多考慮到您現在開始編程，並且初學者總是採取其他方式。

來源

2015-05-19 15:48:28

糟糕的OOP有很多類只有1或2種方法

回答

相關問題