組織代碼，分段文件的邏輯佈局

Question

我已經足夠了解編程，現在已經有10年左右的時間了。我沒有受過正規教育，儘管我已經閱讀了很多關於各種語言的主題的書籍。我現在主要關注的語言將是PHP，至少對於我現在正在做的事情的規模而言。

我已經使用了一些OOP類了一段時間，但從來沒有深入瞭解幕後的原則。我還沒有達到我希望成爲表達明智的水平，但是我最近讀的這本書The OOP Thought Process讓我想提高自己的編程技能。

隨着新概念的推動，我開始了一個新項目。我編寫了一些可重用的類，用於處理用戶身份驗證，用戶配置文件，數據庫接口以及我在大多數項目中定期使用的其他內容。

現在我已經將典型的亂碼意大利麪代碼分解成了一些有組織的文件，在確保文件都包含在需要的時候，我一直有一些問題，如何在邏輯上劃分腳本進入課堂，以及如何分割我應該讓每個班級。

我真正要求的是建議或建議閱讀，它不關注代碼的特定功能和格式，而是關注比單純的愛好項目更大的邏輯佈局。

我想學習如何正確地做事情，雖然我仍然在某些領域學習，但除了僅僅是創意和試驗/錯誤之外，這是我不知道的。主要是錯誤。

感謝您的回覆。這個地方很棒。

Answer 1

我會嘗試從以前的項目中體驗我的經驗，也許他們會幫助你。

如果您嘗試對項目進行細分，請嘗試查找可能對自己有用的組件。如果你寫了例如一個數據庫層，考慮如何使數據庫層與應用程序的其餘部分無關（除了實用程序類和配置）。如果你編寫了一個訪問數據庫層的RichClient，試着把你需要的東西放在它裏面，當你從一個Web層訪問它的時候，你還需要它。現在你有一個在命令行客戶端甚至可能有用的組件。

或者如果你想從較低層次看到這一點，請將你的應用程序拆分成小單元，並且不要讓這些單元具有循環依賴關係！ !!如果兩個組件具有循環依賴關係，則它們不能被分割，並且應該是單個組件。我知道，我有時會違反這條規則，因爲您無法始終堅持這條規則，但瞭解應用程序的構建塊是一個很好的規則。模型 - 視圖 - 控制模式（Model-View-Control Pattern，MVC）是一種應用程序的另一種流行劃分規則，它規定模型（數據類），控件（程序的邏輯）和視圖（圖形用戶接口）應該分成不同的包。雖然我堅持這一點，我會這樣分開我的代碼。在每個包中，我有不同的模型，視圖和控件類，但是模型類並不知道關於控制層的任何內容，而控制層也不知道關於GUI的任何信息。由於GUI開發總是單調乏味，因此經常是應用程序中測試最少的部分（至少在單元測試中），將其從控件中分離出來使編寫buisiness邏輯變得更容易。事實上，它可以讓你專注於你必須做的事情，這是完成工作，你在buisiness邏輯編碼。如果這部分工作，你可以花時間爲它寫一個漂亮的GUI。當然，圖形用戶界面和易用性通常會將他們自己的要求帶到控制中，但至少它的鬆散耦合。

在我目前的大型項目中，我們有一些組件，我們現在將其視爲獨立產品，這些組件被真正的產品使用。這使得負責人能夠更輕鬆地測試和編寫獨立組件，併爲每個人提供更穩定的組件。

只是我2¢。