流程設計的合理編程模式是什麼

㈠ 編程模式是什麼意思啊

模式這個概念被廣泛使用。一位仁兄的文章中說，國外已經把模式這個概念推向日常生活中的許多領域。具體情況怎麼樣，我沒有機會去考證，但是從西方人崇尚務實的精神推測，我想出現這種勢頭很合理。

我理解，模式是一種歸納整理已有經驗的方式。比如設計模式，就系統整理了一些通用幽雅的設計經驗。

作為程序員，」掌握某種技術」和」能合理地使用該技術解決實際問題」並不是一回事。前者偏向理論，後者側重實踐。前者得到人們的一致重視，而後者一直被忽略。我參與的項目中，經常出現這種情況，新加入項目組的程序員得不到這方面的培訓，需要自己花費很大的精力來尋找使用特定技術實現特定應用的方式。這樣降低了開發效率，使程序代碼晦澀難懂，可讀性差，而且代碼隱藏BUG的幾率大，影響了系統的穩定性和質量。而項目中經驗豐富的程序員和編程高手們，掌握了大量的經驗，但是這些經驗都是個人技巧，很少拿出來交流。這種狀況使高手們的編程方式各不相同，所以他們編寫的代碼可讀性也不高。而且由於缺少系統的交流和整理，高手們的編程模式也難免存在一些不盡合理的地方，甚至可能潛伏了一些影響系統穩定性的錯誤步驟。我覺得有必要把這個問題提出來和大家討論，論題就叫編程模式，希望能引起大家的關注。

把編程模式定義為：合理地使用特定技術解決實際問題的經驗。編程模式這個概念應該被明確地提出來，在程序員間系統地交流、討論、整理。每個項目組在編碼之前，都可以歸納出一組針對自己開發環境的編程模式，要求程序員參考這些模式進行編碼，質量檢查人員以這些模式為標准進行質量檢查。當然編程模式需要不斷地補充和完善，這個不斷改進的過程需要項目組所有人員的共同智慧。關注這個問題，我們的軟體代碼的質量和可讀性將大大提高。我們就可以在軟體開發水平上邁出踏踏實實的一步。

現在常被我們掛在嘴邊的一個話題就是「印度軟體業」，有人說它好，有人罵他爛，不過印度軟體既然被國際社會承認，我想它在質量上應該還過得去。靜下心來比較一下，印度和我們的主要區別之一在於軟體業的基礎——程序員。讓一群印度程序員用同一種編程語言解決同一個問題，會發現他們的程序幾乎一模一樣，變數命名、程序結構、處理思路等就象是抄襲下來的，可以說他們在使用相同的編程模式。站在軟體工程的角度看，所有的程序員都以相同的編程模式作為模板編碼，是保證代碼質量的一條途徑，畢竟所有的軟體系統都是建立再代碼之上的，基礎不牢，上層建築再花哨也沒有用。軟體工程是一個側重應用和實踐的領域，國外的工程方法更多地來自實踐經驗，所以可操作性很強。但是傳到國內以後就變味了，許多人更願意把它抽象成純理論去研究，最後出來的理論，只能看，不好使。

這或許還涉及到一個心態的問題，業內的氣氛比較浮，有點急功近利。關注軟體開發的基礎問題,相信可以提高個人和整體的水平。

㈡ 編程模式指的是什麼

各種網站上面最常見的就是23種設計模式
我就說幾個好了，簡單工廠模式，工廠模式，裝飾者模式，責任鏈模式等等
我把別人的貼過來算了。。。

設計模式主要分三個類型:創建型、結構型和行為型。
其中創建型有：
一、Singleton，單例模式：保證一個類只有一個實例，並提供一個訪問它的全局訪問點
二、Abstract Factory，抽象工廠：提供一個創建一系列相關或相互依賴對象的介面，而無須指定它們的具體類。
三、Factory Method，工廠方法：定義一個用於創建對象的介面，讓子類決定實例化哪一個類，Factory Method使一個類的實例化延遲到了子類。
四、Builder，建造模式：將一個復雜對象的構建與他的表示相分離，使得同樣的構建過程可以創建不同的表示。
五、Prototype，原型模式：用原型實例指定創建對象的種類，並且通過拷貝這些原型來創建新的對象。
行為型有：
六、Iterator，迭代器模式：提供一個方法順序訪問一個聚合對象的各個元素，而又不需要暴露該對象的內部表示。
七、Observer，觀察者模式：定義對象間一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知自動更新。
八、Template Method，模板方法：定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中，TemplateMethod使得子類可以不改變一個演算法的結構即可以重定義該演算法得某些特定步驟。
九、Command，命令模式：將一個請求封裝為一個對象，從而使你可以用不同的請求對客戶進行參數化，對請求排隊和記錄請求日誌，以及支持可撤銷的操作。
十、State，狀態模式：允許對象在其內部狀態改變時改變他的行為。對象看起來似乎改變了他的類。
十一、Strategy，策略模式：定義一系列的演算法，把他們一個個封裝起來，並使他們可以互相替換，本模式使得演算法可以獨立於使用它們的客戶。
十二、China of Responsibility，職責鏈模式：使多個對象都有機會處理請求，從而避免請求的送發者和接收者之間的耦合關系
十三、Mediator，中介者模式：用一個中介對象封裝一些列的對象交互。
十四、Visitor，訪問者模式：表示一個作用於某對象結構中的各元素的操作，它使你可以在不改變各元素類的前提下定義作用於這個元素的新操作。
十五、Interpreter，解釋器模式：給定一個語言，定義他的文法的一個表示，並定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。
十六、Memento，備忘錄模式：在不破壞對象的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。
結構型有：
十七、Composite，組合模式：將對象組合成樹形結構以表示部分整體的關系，Composite使得用戶對單個對象和組合對象的使用具有一致性。
十八、Facade，外觀模式：為子系統中的一組介面提供一致的界面，fa?ade提供了一高層介面，這個介面使得子系統更容易使用。
十九、Proxy，代理模式：為其他對象提供一種代理以控制對這個對象的訪問
二十、Adapter,適配器模式：將一類的介面轉換成客戶希望的另外一個介面，Adapter模式使得原本由於介面不兼容而不能一起工作那些類可以一起工作。
二十一、Decrator，裝飾模式：動態地給一個對象增加一些額外的職責，就增加的功能來說，Decorator模式相比生成子類更加靈活。
二十二、Bridge，橋模式：將抽象部分與它的實現部分相分離，使他們可以獨立的變化。
二十三、Flyweight，享元模式

㈢ java 流程式代碼適合什麼設計模式

總體來說設計模式分為三大類：
創建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
二、設計模式的六大原則
1、開閉原則（Open Close Principle）
開閉原則就是說對擴展開放，對修改關閉。在程序需要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程序的擴展性好，易於維護和升級。想要達到這樣的效果，我們需要使用介面和抽象類，後面的具體設計中我們會提到這點。
2、里氏代換原則（Liskov Substitution Principle）
里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承復用的基石，只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規范。—— From Bai 網路
3、依賴倒轉原則（Dependence Inversion Principle）
這個是開閉原則的基礎，具體內容：真對介面編程，依賴於抽象而不依賴於具體。
4、介面隔離原則（Interface Segregation Principle）
這個原則的意思是：使用多個隔離的介面，比使用單個介面要好。還是一個降低類之間的耦合度的意思，從這兒我們看出，其實設計模式就是一個軟體的設計思想，從大型軟體架構出發，為了升級和維護方便。所以上文中多次出現：降低依賴，降低耦合。
5、迪米特法則（最少知道原則）（Demeter Principle）
為什麼叫最少知道原則，就是說：一個實體應當盡量少的與其他實體之間發生相互作用，使得系統功能模塊相對獨立。
6、合成復用原則（Composite Reuse Principle）
原則是盡量使用合成/聚合的方式，而不是使用繼承。

㈣ MVC編程模式是什麼

MVC模式：它是Java裡面常用23的設計模式中的一種軟體設計模式 MVC英文即Model-View-Controller，即把一個應用的輸入、處理、輸出流程按照Model、View、Controller的方式進行分離，這樣一個應用被分成三個層――模型層、視圖層、控制層。 視圖(View)代表用戶交互界面，對於Web應用來說，可以概括為HTML界面，但有可能為XHTML、XML和Applet。隨著應用的復雜性和規模性，界面的處理也變得具有挑戰性。一個應用可能有很多不同的視圖，MVC設計模式對於視圖的處理僅限於視圖上數據的採集和處理，以及用戶的請求，而不包括在視圖上的業務流程的處理。業務流程的處理交予模型(Model)處理。比如一個訂單的視圖只接受來自模型的數據並顯示給用戶，以及將用戶界面的輸入數據和請求傳遞給控制和模型。

模型(Model)：就是業務流程/狀態的處理以及業務規則的制定。業務流程的處理過程對其它層來說是黑箱操作，模型接受視圖請求的數據，並返回最終的處理結果。業務模型的設計可以說是MVC最主要的核心。目前流行的EJB模型就是一個典型的應用例子，它從應用技術實現的角度對模型做了進一步的劃分，以便充分利用現有的組件，但它不能作為應用設計模型的框架。它僅僅告訴你按這種模型設計就可以利用某些技術組件，從而減少了技術上的困難。對一個開發者來說，就可以專注於業務模型的設計。MVC設計模式告訴我們，把應用的模型按一定的規則抽取出來，抽取的層次很重要，這也是判斷開發人員是否優秀的設計依據。抽象與具體不能隔得太遠，也不能太近。MVC並沒有提供模型的設計方法，而只告訴你應該組織管理這些模型，以便於模型的重構和提高重用性。我們可以用對象編程來做比喻，MVC定義了一個頂級類，告訴它的子類你只能做這些，但沒法限制你能做這些。這點對編程的開發人員非常重要。

業務模型還有一個很重要的模型那就是數據模型。數據模型主要指實體對象的數據保存（持續化）。比如將一張訂單保存到資料庫，從資料庫獲取訂單。我們可以將這個模型單獨列出，所有有關資料庫的操作只限制在該模型中。

控制(Controller)可以理解為從用戶接收請求, 將模型與視圖匹配在一起，共同完成用戶的請求。劃分控制層的作用也很明顯，它清楚地告訴你，它就是一個分發器，選擇什麼樣的模型，選擇什麼樣的視圖，可以完成什麼樣的用戶請求。控制層並不做任何的數據處理。例如，用戶點擊一個連接，控制層接受請求後, 並不處理業務信息，它只把用戶的信息傳遞給模型，告訴模型做什麼，選擇符合要求的視圖返回給用戶。因此，一個模型可能對應多個視圖，一個視圖可能對應多個模型。

㈤ 編程好的思路。

我認為編程，重要的不是如何華麗的代碼，而是能夠將用戶需求轉化為機器語言的能力
你的很多思想，是剛開始做程序員的普遍想法，開始思考通過模塊化設計能夠更省力，更快捷的完成工作，程序運行效率還要高。
如果你在大軟體公司工作過，就不會有這種困惑了。因為對於具有一定規模的軟體公司，已經在相當的時間內積累起很豐富的模塊和庫資源，程序員們只需要根據項目的不同象選擇自助餐一樣給拼接到一起，就有了基本框架。
最重要的還是做好用戶需求到需求說明，再到系統框架設計這個工作，會少走很多彎路。
細化到編寫程序，我覺得很重要的一點就是要求公司裡面的程序員要有絕對規范的編程習慣，不然在團隊協作的時候會出很多問題，做出來的基礎庫也經不起時間的考驗。
還有就是你說的模塊化的東西不是萬能的，和你經常從事的項目領域密切相關，你用著很順手，別人可能用不了。比如你是做信息系統的，那麼一個好的查詢分析模塊很多地方都能用，用戶信息管理就要根據復雜程度做幾套，比如能夠定期更換密碼的，比如許可權是要細化到列的，比如只是一個簡單的用戶密碼。根據項目的不同選用。

有些人鼓吹自動化編程，利用商業化的系統模板進行配置。我認為對於企業應用還是可以的，但是對於軟體開發就不可取了。因為提供模板的單位水平如何你並不知道，裡面是否存在大量bug你也不清楚，只是演示做的漂亮。一旦你用了這個東西，在你的項目中出現問題，你debug是查不到具體原因的，苦果只能自己吃，這是個建議，有點離題，但是怕你思路到了一定程度就推崇這種方法。
最後一點，大部分的項目都是需要資料庫作為後台支持的，一定要注意處理好資料庫設計的問題，不然很容易因為庫設計的不合理造成程序復雜，或者是在使用一段時間後效率嚴重降低，造成程序重新返工，就說這么多，希望你能有所收獲

㈥ 形成良好的程序設計風格的原則是什麼

形成良好的復程序設計風格的原制則是：

1、源程序文檔化；

2、數據說明的次序規范化，說明語句中變數安排有序化，使用注釋來說明復雜數據的結構；

3、程序編寫要做到清晰第一、效率第二，先保證程序正確再要求提高速度，避免不必要的轉移；

4、對所有的輸入數據都要進行檢驗，確保輸入數據的合法性。

(6)流程設計的合理編程模式是什麼擴展閱讀：

程序設計風格指一個人編製程序時所表現出來的特點，習慣邏輯思路等。 在程序設計中要使程序結構合理、清晰，形成良好的編程習慣，對程序的要求不僅是可以在機器上執行，給出正確的結果，而且要便於程序的調試和維護，這就要求編寫的程序不僅自己看得懂，而且也要讓別人能看懂。

隨著計算機技術的發展，軟體的規模增大了，軟體的復雜性也增強了。為了提高程序的可閱讀性，要建立良好的編程風格。

風格就是一種好的規范，當然我們所說的程序設計風格肯定是一種好的程序設計規范，包括良好的代碼設計，函數模塊，介面功能以及可擴展性等，更重要的就是程序設計過程中代碼的風格，包括縮進，注釋，變數及函數的命名，泛型和容易理解。