各位前輩，請問在開發App時，您們是怎麼設計自己的類的？

01-05

我最近自學了iOS，於是躍躍欲試想自己做個應用練練手。寫出來了一個小demo，不過感覺亂七八糟的，打算重寫。在這期間我看了斯坦福的iOS公開課，我覺得白鬍子老頭在裡面設計程序的方法特別贊，可是當我拿起紙筆想設計一下自己的class的時候，發現這一切很繁瑣，而且總會遺漏些什麼。
所以想在這裡問問各位前輩，您們在做一個程序的前期，是如何設計自己的class的呢？
小弟在此謝過了。

開發經驗不是很充足的時候，對一個程序的設計更適合採用自下而上的方法，先實現再設計，邊實現邊設計。關心這個程序的一個方面，用粗糙但跑得起來的代碼先實現這個方面，然後一點點地改善，直到自己覺得沒有特別可改善的餘地。然後用同樣的辦法把注意力放到一個不同的方面，在做單個方面的代碼實現時，不因為總擔心整體設計是否合理或者最優而煩惱，不求一次完成設計，事實上對有經驗的開發來說碰到不熟悉的問題也很少能一次完成設計。

開始的時候別在意設計錯誤，在不在意你可能都會犯，重要的是能從錯誤當中汲取經驗。只管耐心地嘗試不同的實現，嘗試多了，更「好」的設計思路會自然呈現。

當你開發過幾次類似的App，有類似的領域知識，你已經駕輕就熟的時候，就可以自上而下了地先設計再實現了，這個時候再去參考程序設計的理論書籍參考意義更大，因為你需要從理論的角度什麼是更「好」的設計，有哪些可能性自己還沒有嘗試過，這是知識補缺的好時機。

有興趣去讀這本書吧程序員修鍊之道:從小工到專家

足夠抽象、面向介面、及時消滅相似的代碼。

類名方法名一定要好看，用起來心情才會愉悅。

謝邀！

OOP 初學者、小白都應該找一本 OOAD（Object Oriented Analysis and Design，面向對象分析與設計）大師的經典名著認真學習一下，例如這本 Craig Larman 的 Applying UML and Patterns（有中文版《UML 和模式應用》，簡稱 AUP）：

如何用面向對象設計一個程序，經典推薦？ - 張恂老師的回答

這書有點厚 700 多頁，所以要有足夠的耐心和信心，不惜花半年（或更長時間）慢讀、精讀，反覆地閱讀。徹底讀懂後，相信你的編程水平肯定會上一個新台階！

如何設計自己的class的呢？

如何設計類？30 年來軟體工程界已經終結出了許多成熟的設計流程、方法、原則、模式和技巧，這些設計經驗通常被歸納成 OOP 的設計模式（Design Patterns），如經典的 GoF 23 種設計模式。不過 GoF 20 年前的那本《設計模式》原著並不適合小白閱讀，對於初學者而言太老、太難了。

類設計的一個最基本任務是：確定用幾個類來實現當前的功能，如何在這幾個類之間進行職責分配，任務劃分。其中有一批最基礎、最簡單的設計模式和原則叫 GRASP（General Responsibility Assignment Software Patterns or Principles，通用軟體職責分配模式/原則）。

Wikipedia: GRASP (object-oriented design)

GRASP 和幾個常用的 GoF 基本設計模式正是 Larman 大師 AUP 這書的核心內容之一。小白應該先掌握這些基本的類設計原則和技巧。學完了這些基礎內容，你就不會再問「如何設計類」了。

千萬別還沒寫出功能就想著如何去設計類，使用這個那個的設計模式之類的，這就屬於過度設計了，絕對會把自己坑死。

你沒有踩過足夠的坑，是不可能知道如何設計好一個類的。先把功能實現了，等你寫煩了某些重複的東西，或者覺得寫的很蛋疼，再想去想設計。

沒有人能一開始就寫出完美的代碼，都是不斷的踩坑不斷改進。

重用兩次以上的代碼必須封裝。

框架是逐年累積的

我的做法是公共方法都要盡量抽取出來，業務邏輯作為一個層和繪製view盡量分開，網路請求獨自封裝出來

簡單就是 Global（公共方法，宏定義，類別和第三方開源，網路請求封裝，分享封裝）功能模塊（分三個文件夾controller view model）model處理數據請求封裝和定義model和做簡單數據轉換 controller處理業務邏輯和數據請求和布局各類view

以上是框架的積累，具體如何有效率的寫業務模塊，我的建議是先按自己想法寫代碼實現出來，然後審視自己代碼，抽取共用部分出來

如分享功能，開始的時候要測試，先寫在一個controller，迅速排除各種坑（微博回調，qq頭像不一致，微信不會返回昵稱等問題），然後一看，對哦，share可以抽取出來，單獨寫個shareManager，定義分享方法，把block放出來。後來一想，乾脆把彈出的share UI也一併集成，一鍵調用

如此，你的代碼就會逐步的簡潔易用也很好復用

想像自己在親手設計一個。。額，公司

每個類，就是一個部門，專門搞一類事情

數據處理類，專門處理數據

UI的專門負責UI

有的部門事多，越來越大

事情也越來越多

於是按照事務種類再分

相當於部門拆分

打個比方

所有公司基本都有個綜合部？（全局靜態class）

全公司無論哪個部門都可以找他

人事的事，電腦問題，報銷，雜事。。。

公司越做越大，綜合部忙不過來

於是可以拆分出

人事部，IT部。。。

專門負責一個類型的事

要是覺得有些事

自己公司招人做太費勁

成本高，做的還一般，維護麻煩

還不如外包（用第三方庫）

只需談好需求，對接對接就完事（熟悉使用方法）

本來就是會遺漏的，優秀的程序員一直在重構。

類設計是一種直覺，而不是一種規則。別相信理清所有設計之後，你就能在紙上實現出來。那個時候的直覺強大到無需編碼已經在腦子中編譯通過了。

新手入門，忘記類這個概念，因為你什麼都不懂，設計出來的東西能用？所有的設計都有自己的思想，如果沒有思想談何設計？

所以忘記設計這麼一回事，直接實現。

寫完之後回頭再來研究這個哪裡有問題哪裡更好，怎麼做才能最好。

首先你了解了整個工程，因為你寫完了。所以才能說我有一種想法，這種設計能解決什麼問題，任何設計都有取捨，你捨棄了什麼，解決了什麼，這是要不斷的推翻重來後你才能得知的。程序不是臆想出來的，而是進化出來的。

斯坦福那個課程，建議有另外一門編程語言(除了C)經驗的人看。

少年你聽說過重構嗎？

沒寫過足夠多的項目，沒被那些坑折騰過，你是很難下意識就知道怎麼去設計一個類的。

自己寫個獨立的 App，維護上一兩年，就知道怎麼設計類了，當然，多看些經典開源項目哦

最基礎的是命名規範，命名規範，命名規範。重要的事說三遍。剛開始就培養自己的命名！

新手剛開始心態一定放低，不要要求自己直接寫出大牛版的代碼。好的代碼設計都是一層一層進化出來的。

OC語言是面向對象的語言，所以一般遵循面向對象的幾個原則就好，最常用的就是一個封裝，繼承在OC少用或者不用。

考慮那些屬性語言暴露給別人，哪些不需要暴露給別人。

以前寫的代碼不斷修正，去掉不需要的屬性方法。

可以從外向里設計或者從裡向外設計。從外向里就是外界需要什麼功能就開發什麼功能

從裡向外就是類似AFNetworking和SDWebimage的框架為使用者提供儘可能多的功能。

先跑起來，然後再將一些核心的概念，通常是名詞作為類（無所謂了，反正是你自己的設計）。第三輪就是優化介面啥的，如果可以的話可以加入合適的設計模式。我沒搞過啥大的項目，都是自己寫著玩的小工具。我覺得這取決於你的軟體面向的群體，如果面向自己或者應用，隨心所欲就可以了。如果要給其它人使用，就應該考慮一下別人的感受了。還有一點就是，我喜歡在紙上畫畫草圖，理理思路，我覺得還是挺有效的。

正常，寫多了就好了。。。

這個純屬看經驗說話，經驗多了，腦子一轉就出來了。

講點實際的，沒有全局的設計的話，想到哪裡就設計哪裡，修修改改個不停。

推薦你一本書《Head first 設計模式》

提個建議，摸透每個ide生成類名的規則，起名要想清楚，不然對於強迫症來說，看見類名就想刪工程了（尤其說VS這種坑比工具）。然後畫畫流程圖什麼的，我從來沒覺得不畫流程圖就是大神，畫了流程圖就是民工。想三遍再下手，不然就是一直在重構，重構……然後發現由於類框架限制，還不好加東西……

1.類不一定簡單但是層數要少

oo泥潭就是因為層數多強耦合

2.用好介面

1，2都做到你會發現java objc c# delphi用著爽

這幾種語言沒本質不同

上面兩招是把oo向面向過程靠近

軟體復用除了oo繼承還可以函數復用和copypaste嘛

用好了做技術總監沒問題的

我也才剛開始做app，給你點建議

class想怎麼寫就怎麼寫，不要怕漏東西，因為你不可能一開始就把所有東西都想到。個人認為作為新手應該注意的點：

1.每個類，變數，方法名字要簡潔易懂。

2.多做註解。

3.嘗試多用func，如果不太會可以先按自己的思路寫，再寫成func。

4.可以先做一個app練練手，做完就會熟練多了。

不過，新手可以在知乎多看大神吹吹牛增長眼界。