本文以“家庭”為例子，演示如何使用面向對象思維去編寫代碼。

這是一篇文字較多的文章，建議您仔細閱讀，因為它將完整展示構建一個面向對象代碼的過程，當然這個思想過程是我個人的過程，每個人有自己思考的方式方法，我的僅供參考。

一、編寫面向對象，首先要構思

構思一般隨意，你可以在自己腦海中構思，也可以借助專業的UML來構思，又或者借助紙筆構思，總之，一切隨意，只要你喜歡。

那么下面這張圖，是我在紙上畫的構思：

 

 

二、形成你的思路

通過構思，你可以慢慢的理清、形成自己的代碼思路。

回到“家庭”這個例子，我當時是這么思考的：

家庭，就要有家庭成員，所以，我可能會有一個IMember的接口。

然后我想到家庭成員之間存在一定的關系，比如父與子、母與子等關系，于是有了IRelation接口。

接著我就想到了家庭屬性，家庭應該是獨特的，自己的定義，所以就有了Family，有了Family，我就想到了應該抽象成IFamily，而IFamily很可能會有家庭名稱、人員列表等屬性或者方法定義。

再然后我回顧之前的思路，想到關系會有多種類型，它可能會是個枚舉，所以就有RelationTypes枚舉對象。

那有了關系，可能需要一個關系管理類來管理它。所以，我就有了RelationManager類。

最后我又思考到了家庭成員，每個成員都有自己的個性。而個性是復雜，不一定是單一的，比如有些成員好動而熱情，比如爸爸面冷心熱等。于是我想個性應該是個具有Flags標簽的枚舉，允許一個成員具有多重個性。

三、檢查回顧，并理解你的需求是否滿足

我們在工作中，對于一個功能開發項，它首要保證的是實現業務需求，所以，我們在做了簡單的建模后(構思即是建模的過程)，需要結合實際，看是否滿足需要。

那么我們看“家庭”這個例子，由于我是舉例子，所以它目前的簡單建模可能是正確的。暫時也不需要加其它的需求了。

但現在覺得沒有問題的建模，在實際編寫代碼后，可能會面臨實際項目中，我們尚未考慮到的點，這時就需要不斷迭代建模。直到你的思維準確為止。

四、關于對象的方法或者屬性

我個人的習慣是簡單建模出整體框架后，就開始寫代碼了。

可能有的人，做事較為細致，在構建階段，就會想要事先定義好每一個對象的方法或者屬性，這也是可以的。看您習慣和喜歡。

五、編碼，我們先寫關系代碼

1.先定義成員關系接口

 

 

2.定義成員關系類型的枚舉

 

 

​

3.定義關系創建接口

 

 

​

這里要稍微注意下，這與我的簡單建模規劃的關系思想有些不同，增加了關系創建接口。所以說，我們在實際編碼過程中，針對業務的情況會有偏移，需要進行重構建模。

4.定義成員關系接口的實現類

 

 

​

這里要特別注意的是，我這里將實現類定義成internal，這就意味著，除了我們自己外，外部調用我們api的人，也就是外部程序員引用我們的dll的話，是無法直接new一個Relation對象的，因為我們把它定義成了內部類。這樣就可以規范外部調用者的行為，指定了他如果想要實例化這個Relation類的話，必須通過其它途徑來實現。

5.定義關系創建類

 

 

​

這個就是別人想要創建關系時，所必須通過的途徑。因為他無法實例化Relation類，只能通過我的RelationBuilder對象的Create()方法來創建，這就規范了使用我們api的人的行為。

六、編碼，我們編寫家庭成員和個性的代碼

1.家庭成員的接口定義

 

 

​

我們會看到家庭成員接口只定義了全名和性別2個屬性，但是家庭成員是有個性的，為什么不放在一起寫呢?這就是面向對象的接口隔離原則，你可以參考我的前面文章，有一篇單獨講“接口隔離原則”的。

2.家庭成員的個性枚舉，注意個性是多重的，所以，我們的枚舉要定義成Flags

 

 

​

3.然后我們定義一個家庭成員的個性接口

 

 

​

4.最后，我們來定義家庭成員的實現類Member.cs

 

 

​

注意看這個成員實現類，它實現了兩個接口，分別是IMember和ICharacter。我們定義了它的構造函數，帶有fullName和sex兩個參數，所有public的公開屬性都是只讀的，這意味著別人只能訪問而無法修改。開放了設置個性的方法SetCharacter()。

好了，由于篇幅很長了，所以，關于家庭的接口，我就不再繼續寫了。相信你通過上面兩個例子，也已經學會了，如何去編寫面向對象的代碼思路了。

如果你能學會并運用這個思路，那么我很為你高興。