您是否推薦用於dot net中小型數據庫應用的程序方法學軟件開發？

Question

作爲軟件開發行業的新進入者，我試圖用不同的方式來發展我的編程技巧。我發現的一種方式是通過閱讀其他作者的代碼而得到的許多建議。

當我開始開發時，我想爲任何應用程序使用面向對象的設計範例。首先，我從小型數據庫編程項目開始，例如酒店管理，工資單，銷售應用程序等。然而，在我搜索互聯網上的源代碼的過程中，我發現很多程序員在程序化的過程中爲這些小型應用程序開發了他們的源代碼。雖然他們使用vb dot net或C＃（面向對象的語言），但他們試圖遵循程序，比如他們在一個類中定義了所有全局方法和變量，然後他們調用特定表單爲特定操作訪問該方法。

E.g.圖書館管理中的應用設計可能看起來像這樣

//one global class for whole method and variable definition 
Class globals { 
//define public variable and public function such as 
//connection to db code 
Public void storebooks() 
{//code for storing books to db 
} 
Public void storeusers 
{ //code for storing users to db 
} 
. 
. 
//code for searching books …etc 
} 

然後形式用於其操作就像在VB6模塊聲明一個特定的全局方法和變量。

我的問題是，當我試圖做的應用程序，我嘗試通過定義類對象，屬性...等方法使用oop方法。 那麼我在正確的方向嗎？我應該使用面向對象的方法（儘管很小）開發這些類型的應用程序，或者我應該堅持我在網上找到的上述類型代碼（程序方式）？

請詳細解釋何時使用oop方法以及何時使用程序（如果適用的話）。我的目的也是發展自己的軟件開發技能的畢業生

感謝

Answer 1

程序開發實際上沒有錯。你可以用它編寫出好的和可維護的應用程序。但是，您經常看到的是將過程實踐應用於OO語言。

一個原因可能是程序員只是來自非OO語言，比如C，並試圖使他的知識適應新的語言。也可以是應用程序非常簡單，以至於程序方法最適合。

我認爲一個有效的方法是確定你想創建什麼樣的應用程序。如果您知道您可以選擇所需的平臺和語言。但是，這並非總是可行的，因爲平臺和語言已經被定義（由管理層等）。

編寫純粹的面向對象應用程序並不像看起來那麼容易。特別是找出你的域名模型（你的應用設計的基礎）可能很困難。但是，一旦你有我的經驗這個模型，創建一個面向對象的應用程序是相當容易的，無論大小。當然瞭解所有流程（用例，流程/過程（！））能夠定義模型中的關係非常重要。

面向對象的巨大缺陷在於設計。數百個帶有繼承的類和類似的東西。這樣做會導致臃腫的應用程序出現不值得這樣的功能。

爲了使這個長話短：讓自己清楚面向對象的性質和其他範式的本質，並考慮什麼是最適合你想要建立的應用程序。作爲一種實踐，您還可以創建一個包含面向對象和過程的應用程序，並瞭解您可以從中學到什麼。

說到自己我幾乎總是在C＃（或Java）中使用OO來應用程序，也是簡單的應用程序。模型的深度也取決於複雜性和可維護性。通常我用幾個選項進行原型設計，然後決定我的最終設計（建議：始終繪製/設計模型！）。儘管如此，我仍然不相信OO範式適合所有人。

Answer 2

雖然辯論「OOP VS過程編程」還活着，我懷疑這樣的小項目真正的方法分析服用。

許多執行簡單ERP項目的程序員都有程序背景（Visual Basic < = 6，甚至COBOL），但並不真正瞭解面向對象模型。因此，他們使用面向對象的語言作爲某種「面向組件」的系統（即它們只使用預製對象而不是程序邏輯）。

結果是，這些小軟件是維護的噩夢。然而，即使正確應用了OOP，它們仍然是一場噩夢，因爲通常這個程序沒有設計，缺乏正式的規範，並且有瘋狂的時間表等等。所以程序員就落在了「代碼第一，稍後思考」的方法論中。

Answer 3

Wrox Publishing出版了一本名爲「Refactoring in Visual Basic」的書，用於研究演變爲面向對象設計的程序開發。

它舉例說明了如何快速將程序性解決方案編碼爲小的可管理問題，以便讓客戶要求進行修訂和日益複雜的改進，而這些改進反過來會受益於面向對象開發的自主性。

儘管本書不一定是各種開發策略和實現的概述，但它通過迭代迭代過程對比了不同的技術。