針對實現編程是什麼原則

1. java面向對象設計有哪些原則

甚至還有經驗豐富的Java程序員沒有聽說過OOPS和SOLID設計原則，他們根本不知道設計原則的好處，也不知道如何依照這些原則來進行編程。 眾所周知，Java編程最基本的原則就是要追求高內聚和低耦合的解決方案和代碼模塊設計。查看Apache和Sun的開放源代碼能幫助你發現其他Java設計原則在這些代碼中的實際運用。Java DevelopmentKit則遵循以下模式：BorderFactory類中的工廠模式、Runtime類中的單件模式。 原則1:DRY（Don'trepeatyourself） 即不要寫重復的代碼，而是用"abstraction"類來抽象公有的東西。如果你需要多次用到一個硬編碼值，那麼可以設為公共常量；如果你要在兩個以上的地方使用一個代碼塊，那麼可以將它設為一個獨立的方法。SOLID設計原則的優點是易於維護，但要注意，不要濫用，plicate不是針對代碼，而是針對功能。這意味著，即使用公共代碼來驗證OrderID和SSN,二者也不會是相同的。使用公共代碼來實現兩個不同的功能，其實就是近似地把這兩個功能永遠捆綁到了一起，如果OrderID改變了其格式，SSN驗證代碼也會中斷。因此要慎用這種組合，不要隨意捆綁類似但不相關的功能。 原則2:封裝變化 在軟體領域中唯一不變的就是"Change",因此封裝你認為或猜測未來將發生變化的代碼。OOPS設計模式的優點在於易於測試和維護封裝的代碼。如果你使用Java編碼，可以默認私有化變數和方法，並逐步增加訪問許可權，比如從private到protected和notpublic.有幾種Java設計模式也使用封裝，比如Factory設計模式是封裝"對象創建",其靈活性使得之後引進新代碼不會對現有的代碼造成影響。 原則3:開閉原則 即對擴展開放，對修改關閉。這是另一種非常棒的設計原則，可以防止其他人更改已經測試好的代碼。理論上，可以在不修改原有的模塊的基礎上，擴展功能。這也是開閉原則的宗旨。 原則4:單一職責原則 類被修改的幾率很大，因此應該專注於單一的功能。如果你把多個功能放在同一個類中，功能之間就形成了關聯，改變其中一個功能，有可能中止另一個功能，這時就需要新一輪的測試來避免可能出現的問題。 原則5:依賴注入或倒置原則 這個設計原則的亮點在於任何被DI框架注入的類很容易用mock對象進行測試和維護，因為對象創建代碼集中在框架中，客戶端代碼也不混亂。有很多方式可以實現依賴倒置，比如像AspectJ等的AOP（AspectOrientedprogramming）框架使用的位元組碼技術，或Spring框架使用的代理等。 原則6:優先利用組合而非繼承 如果可能的話，優先利用組合而不是繼承。一些人可能會質疑，但我發現，組合比繼承靈活得多。組合允許在運行期間通過設置類的屬性來改變類的行為，也可以通過使用介面來組合一個類，它提供了更高的靈活性，並可以隨時實現。《EffectiveJava》也推薦此原則。 原則7:里氏代換原則（LSP） 根據該原則，子類必須能夠替換掉它們的基類，也就是說使用基類的方法或函數能夠順利地引用子類對象。LSP原則與單一職責原則和介面分離原則密切相關，如果一個類比子類具備更多功能，很有可能某些功能會失效，這就違反了LSP原則。為了遵循該設計原則，派生類或子類必須增強功能。 原則8:介面分離原則 採用多個與特定客戶類有關的介面比採用一個通用的涵蓋多個業務方法的介面要好。設計介面很棘手，因為一旦釋放介面，你就無法在不中斷執行的情況下改變它。在Java中，該原則的另一個優勢在於，在任何類使用介面之前，介面不利於實現所有的方法，所以單一的功能意味著更少的實現方法。 原則9:針對介面編程，而不是針對實現編程 該原則可以使代碼更加靈活，以便可以在任何介面實現中使用。因此，在Java中最好使用變數介面類型、方法返回類型、方法參數類型等。《EffectiveJava》和《headfirstdesignpattern》書中也有提到。 原則10:委託原則 該原則最典型的例子是Java中的equals（）和hashCode（）方法。為了平等地比較兩個對象，我們用類本身而不是客戶端類來做比較。這個設計原則的好處是沒有重復的代碼，而且很容易對其進行修改。 總之，希望這些面向對象的設計原則能幫助你寫出更靈活更好的代碼。理論是第一步，更重要的是需要開發者在實踐中去運用和體會。

2. 如何理解「針對介面編程，而不是針對實現編程」

通過介面來調用一個類及其方法，而不是直接建立類實體來調用類。
比如將來你要頌知把這個被調用的類換成一個別的實現類時，你就不用去把調用過它的野好消類一個個改掉了，因為它們調襪碼的是介面，介面沒變，在配置里把介面的實現類換成新的類，就全部都替換掉了
這就是解耦，提高可維護性

3. 程序設計原則也是衡量編程工作質量的指標

程序設計原則也是衡量編程工作質量的指標。

程序設計是給出解決特定問題程序的過程，是軟體構造活動中的重要組成部分；程序設計往往以某種程序設計語言為工具，給出這種語言下的程序。

4、介面隔離原則：使用多個隔離介面，比使用單個介面要好。經常提到的降低耦合，降低依賴，主要也是通過這個原則來達到目的。

5、迪米特法則：一個實體應當盡芹握可能少的與其他實體之間發生相互作用。

6、開閉原則：程序的設計應該是不約束擴展，即擴展開放，但又不能修改已有功能，即修改關閉。

7、合成/聚合復用原則：在一個新的對象裡面使用一些已有的對象，使之成為新對象的一部分，新的對象通過這些對象的委派達到復用已有功能的目的。

4. 策略模式實際上應用了什麼設計原則

1.Petshop中策略模式的應用
至於在程序中的應用，我也是個新手，不知道何時需要這種模式，可以參考下petshop中的策略模式，理解下在真實項目中如何使用。我對petshop中策略模式的理解就是裡面處理訂單時可能有同步和非同步插入數據兩種方式，具體用那種方式直接在配置文件中修改即可。
看文字不如看圖片，自己畫了畫UML圖，不會用工具但是意思差不多。
這是IBLLStrategy類庫中的腔信介面IBLLStrage，為了同步非同步插入訂單的實現，如果有新的訂單插入方式，可以繼承此介面這兩個類是處理同步非同步的訂單類。
繼承於IBLLStrage，分別實現自己的插入方法。在BLL層中的order類中
private static readonly PetShop.IBLLStrategy.IOrderStrategy orderInse
rtStrategy = LoadInsertStrategy();LoadInsertStrategy
方正型法決定了實例化
的是同步傳送訂單還是非同步傳送訂單。在BLL邏輯層中，Order訂單中會改變的是insert方法，所以根據設計原則，把需要改變的獨立出來。
2.控制台小應用程序
實例描述，模擬鴨子應用，由於後期需要可能有N種鴨子，鴨子可不可以飛，怎樣飛，鴨子可不可以叫，怎麼叫，如果僅僅寫兩個介面Ifly和Iquack，子類要麼繼承，要麼不繼承，對飛的行為無法控制，因為飛的動作和叫的方式千變萬化。

設計原則
1.找出應用中可能需要變化之處，把他們獨立出來，不要和那些不需要變化的代碼混合在一起（此例子中鴨子的行為屬於變化）
2.針對介面編程，而不是針對實現編程針對介面編舉圓猜程是真正的意思是針對超類型編程，利用多態，程序可以針對超類型編程，聲明一個類時通常是一個超類或者是一個介面，這也意味著聲明類時，不用理會以後執行的真正對象，舉例Animal是一個抽象類，有兩個子類Dog和Cat
繼承Animal針對實現的編程是:
Cat c = new Cat();
c.meow();
//
貓叫的方式
Dog d = new Dog();
d.bark();
//

狗叫的方式針對介面的編程是：
Animal a = new Dog();
a.makeSound();
//makeSound中會調用bark();
Animal a = new Cat();
a.makeSound();
//makeSound中會調用meow();
3.多用組合，少用繼承根據讀headfirst策略模式做的c#的例子。

策略模式：定義了演算法族，分別封裝起來，讓他們之間可以相互替換，次模式讓演算法的變化獨立於使用演算法的客戶。

5. DRY編程原則 是什麼

DRY 全稱：Don't Repeat Yourself （摘自wikipedia），是指編程過程中不寫重復代碼，將能夠公共的部分抽象出來，封裝成工具類或者用「abstraction」類來抽象公有的東西，降低代碼的耦合性，這樣不僅提高代碼的靈活性、健壯性以及可讀性，也方便後期的維護或者修改。

(5)針對實現編程是什麼原則擴展閱讀：

DRY原則特指在程序設計以及計算中避免重復代碼，因為這樣會降低靈活性、簡潔性，並且可能導致代碼之間的矛盾，DRY是Andy Hunt 和 Dave Thomas's 的《 The Pragmatic Programmer 》書中的核心原則。

參考資料：DRY原則--網路

6. 編程原理是什麼

簡單的說，編程就是為了藉助於計算機來達到某一目的或解決某個問題，而使用某種程序設計語言編寫程序代碼，並最終得到結果的過程。
計算機雖然功能十分強大。可以供你上網、打游戲、管理公司人事關系等等，但是沒有程序，它就等於是一堆廢鐵，不會理會我們對它下達的「命令」。於是，我們要馴服它，只有通過一種方式——程序，這也是我們和計算機溝通的唯一方式。

那程序到底是什麼呢？
程序也就是指令的集合，它告訴計算機如何執行特殊的任務。

打個比方說，它好比指導你烹調菜品的菜譜或指揮行駛一路到達目的地的交警（或者交通路標）。沒有這些特殊的指令，就不能執行預期的任務。計算機也一樣，當你想讓計算機為你做一件事情的時候，計算機本身並不能主動為我們工作，因此我們必須對它下達指令，而它根本不會也不可能聽懂人類自然語言對事情的描述，因此我們必須使用程序來告訴計算機做什麼事情以及如何去做？甚至對最簡單的任務也需要指令，例如如何取得擊鍵，怎樣在屏幕上放一個字母，怎樣在磁碟中保存文件等等。
這么麻煩，連這些東西編程都要考慮！怪不得人家說編程好難！你錯了，其實許多這樣的指令都是現成的，包含在處理晶元中內置於操作系統中，因此我們不必擔心它們工作，他們都是由處理器和操作系統來完成的，並不需要我們來干預這些過程。

上面講到的計算機本身不會主動的做任何事情。因此我們要通過程序的方式來讓計算機為我們「效勞」。而這個過程就是我們「編」出來的。編程可以使用某一種程序設計語言來實現，按照這種語言的語法來描述讓計算機要做的事情。

我們這里所講的語法和外語中的語法完全兩碼事，這里講的語法只是讀你的程序書寫做出一寫規定而已。

寫出程序後，再由特殊的軟體將你的程序解釋或翻譯成計算機能夠識別的「計算機語言」，然後計算機就可以「聽得懂」你的話了，並會按照你的吩咐去做事了。因此，編程實際上也就是「人給計算機出規則」這么一個過程。
隨計算機語言的種類非常的多，總的來說可以分成機器語言，匯編語言，高級語言三大類。
電腦每做的一次動作，一個步驟，都是按照已經用計算機語言編好的程序來執行，程序是計算機要執行的指令的集合，而程序全部都是用我們所掌握的語言來編寫的。所以人們要控制計算機一定要通過計算機語言向計算機發出命令。

計算機所能識別的語言只有機器語言，即由構成的代碼。但通常人們編程時，不採用機器語言，因為它非常難於記憶和識別。

目前通用的編程語言有兩種形式：匯編語言和高級語言。

匯編語言的實質和機器語言是相同的，都是直接對硬體操作，只不過指令採用了英文縮寫的標識符，更容易識別和記憶。它同樣需要編程者將每一步具體的操作用命令的形式寫出來。

匯編程序的每一句指令只能對應實際操作過程中的一個很細微的動作，例如移動、自增，因此匯編源程序一般比較冗長、復雜、容易出錯，而且使用匯編語言編程需要有更多的計算機專業知識，但匯編語言的優點也是顯而易見的，用匯編語言所能完成的操作不是一般高級語言所能實現的，而且源程序經匯編生成的可執行文件不僅比較小，而且執行速度很快。

高級語言是目前絕大多數編程者的選擇。和匯編語言相比，它不但將許多相關的機器指令合成為單條指令並且去掉了與具體操作有關但與完成工作無關的細節，例如使用堆棧、寄存器等，這樣就大大簡化了程序中的指令。由於省略了很多細節，所以編程者也不需要具備太多的專業知識。

高級語言主要是相對於匯編語言而言，它並不是特指某一種具體的語言，而是包括了很多編程語言，如目前流行的VB、VC、FoxPro、Delphi等，這些語言的語法、命令格式都各不相同。

(1)解釋類：執行方式類似於我們日常生活中的「同聲翻譯」，應用程序源代碼一邊由相應語言的解釋器「翻譯」成目標代碼(機器語言)，一邊執行，因此效率比較低，而且不能生成可獨立執行的可執行文件，應用程序不能脫離其解釋器，但這種方式比較靈活，可以動態地調整、修改應用程序。

(2)編譯類：編譯是指在應用源程序執行之前，就將程序源代碼「翻譯」成目標代碼(機器語言)，因此其目標程序可以脫離其語言環境獨立執行，使用比較方便、效率較高。但應用程序一旦需要修改，必須先修改源代碼，再重新編譯生成新的目標文件(*．OBJ)才能執行，只有目標文件而沒有源代碼，修改很不方便。現在大多數的編程語言都是編譯型的，例如Visual Basic、Visual C++、Visual Foxpro、Delphi等。
這個問題其實很簡單。前面我們講到，程序是人與計算機進行溝通的唯一方式，因此我們要讓計算機為我們服務，就必須有程序，而程序從哪裡來?當然是由我們編寫出來了。或許你又會問到另一個問題：現在要什麼程序有什麼程序，我幹嘛還要編程呢?這你就錯了，現在的程序雖然很多，需要什麼樣的程序直接到網上不需要很長時間就可以找到類似的，而且有可能就是你所需要的。但是，就好比去買衣服，雖然賣衣服的到處都是，但是哪一件是為你「量身定做」的呢！
程序還能夠做很多事情不同的程序可以完成不同的事情。從大的方面到管理國家的財務，小的方面管理家庭的帳務。

又如，如果你想要你的計算機能播放動畫，那麼你的計算機中也要有相應的動畫播放程序，下面所示的就是一個F1ssh動畫播放器。我們將會在後面的章節具體講述這個程序的編制過程。
隨著計算機的飛速發展，總會有那麼一天將不會編程的人列為「文盲」。你不希望吧?那麼就好好的學習一種程序設計語言吧。

編程會過時嗎

編程會過時嗎?這個問題，讓我先問你一個問題：計算機會消失嗎?這兩者答案是一樣的。知道了計算機會不會消失，就知道了編程會不會過時。

編程工具會過時，而編程卻不會過時

計算機系統由可以看見的硬倒：系統和看不見的軟體系統組成。要使計算機能夠正常的工作，僅僅有硬體系統是不行的，沒有軟倒系統(即沒有程序)的計算機可以說只是—堆廢鐵，什麼事情都幹不了。例如當你撰寫—篇文章的時候，你需要在操作系統中用文字編輯軟體來實現文字的輸入，但如果沒有這些文字輸入軟體的話，你是否想過如何向計算機中輸入文章呢?很難想像出如何在一個沒有任何軟體的計算機(我們稱之為裸機)上進行文字的輸入。而這些軟體其實就是通常我們所說的程序。

編程會過時嗎?我們從另一個角度來考慮這個問題，計算機有——天會消失嗎?如果有一天當世界上所有的事情處理都用不到計算機了，那麼計算機將會很快的消失，那時編程不僅過時了，而且也會隨之消失了。但是計算機會消失嗎?當然不會，如今計算機應用到每一領域，為人類的發展做出了不可估量的貢獻。試想一下如果有一天全世界的計算機突然消失了，那麼這個世界將變成什麼樣子，或許和全世界都停電了一樣恐怖，甚至還會有更大的損失。計算機的存在必須要有軟體系統來維持。因此編程永遠不會、也不可能會過時。

計算機程序設計語言發展到今天，已經從最原始的機器語言發展到如今可視化的集成開發環境，甚至集多種語言在同一開發平台上，像微軟的NET平台。回頭看看程序設計語言的發展史，不難看出對於編程來說，只會出現編程工具的過時，不會出現編程本身的過時。

不斷變化的技術需要不斷變化的程序員

從二十世紀60年代以後，計算機得到了突飛猛進的發展。似乎歷史上沒有任何一門科學的發展速度超過了計算機的發展，無論硬體、軟體、還是網路都以驚人的速度向前發展。計算機的硬體發展速度遵循「摩爾定律」每十八個月速度翻一倍(實際現在已超過了這個速度)。 軟體的發展速度和硬體一樣，二十世紀九十年代中國的軟體業還不是很成熟，而現在大大小小 的軟體企業四處聳立，共享軟體網上隨處可見。不斷發展的技術需要不斷變化的程序員，例如，如今Visual Basic可以快速構Windows下的應用程序，程序設計方面的技術不斷發展著，不斷引進新的概念、新的方法，如從結構化的C開始，當面向對象的思想被提出後，出現了C++，微軟在C++的基礎上為使用戶構建win32應用程序更加方便，推出了Visual C++。這也就需要程序員也要不斷的更新自己的技術。

計算機科學與別的學科很不一樣，不像語言學、歷史學那樣，幾乎是永久不變的東西。計算機科學要求不斷的更新自己的知識，否則很快就會被淘汰，即便是編程亦是如此。

編寫程序是一件很有趣的事情，因為編寫程序可以干很多高級的事情。例如我們在後面的章節中介紹如何使用Visual Basic編寫Flash動畫播放器，以及如何編寫下載軟體管理器等。如果你願意的話，你完全可以編寫出比這些更高級的程序來。

隨著計算機軟體業的發展，誕生了「程序員」這個職位。於是便形成了一種理念，編寫程 序的人就是程序員，因此編程是程序員的事情。但程序員並不是一開始就是程序員，他們也是從現在我們的位置慢慢成為程序員的。

編寫程序是一件很有趣的事情，因為編寫程序可以干很多高級的事情。例如我們在後面的章節中介紹如何使用Visual Basic編寫Flash動畫播放器，以及如何編寫下載軟體管理器等。如果你願意的話，你完全可以編寫出比這些更高級的程序來。

編程也可以作為——種愛好或興趣，如果你對它感興趣學起來就容易多了!因為如果對編程感興趣的話，就會多看些有關方面的書、多編些小程序上機實踐，這些對於學習編程的幫助是非常大的，而且隨著學習的進程不斷的推進就會覺得它並不是很困難，相反卻是很容易的。

總之，在學習編程時一定要堅持不懈，只要有信心、有毅力就一定能學好；不能因為一些似是而非的觀念就動搖了自己的信心。

我們一起來編程

面對擺在面前的計算機該如何操作，相信這個問題已經不再是困擾大家的首要問題了。現在軟體的種類那麼多，在選用的時候「電腦發燒友」的心裡是否也想過有一天自己能編寫一款屬於自己的軟體呢?想學習編程的朋友在選擇程序語言時會不會因為不知道如何選擇而大感頭痛呢?在不知如何下手的時候，朋友們的心中是不是會產生「我是不是可以編程」的思想呢?但是又有哪個程序員是不經過學習就能成功的呢!其實編寫程序並不是人們所想像的那麼困難、那麼復雜，每個有心致力於學習計算機的朋友都是可以嘗試的!

選擇適合自己的程序語言的必要性

目前常用的基本程序語言的種類比較繁多，比較簡單的有：Pascal、c語言、qBasic、 Fortran、Visual Basic等等。但前幾種都是在DOS下進行編程的工具，Visual Basic是在 Windows下進行應用程序設計的編程工具，現在一般的計算機用戶幾乎都不再使用DOS了，因此我們通常會選擇Visual Basic作為初學者的編程工具。Visual Basic是Windows應用程序設計中最容易上手的編程工具，學習步驟也比較容易被初學者接受。對於剛開始學習編程的初學者來說，還是選擇Visual Basic，學習編程語言不能想像著一步登天，一步一個腳印的學習才是最佳方法。

堅定自己學習編寫程序的信心

編寫程序並不是具有專業知識的人員才有的專利，每個學習計算機的人都可以編寫程序，每個人的靈感不同，在編寫程序的思路和作法上又有區別。但共同的想法就是編寫成功的程序。學習編程是一個漫長的過程，其中要付出艱辛的努力和汗水，不過成功者的喜悅又不是別人所能體會的。克服學習中的困難，努力去實踐，要有一個思想：別人能做到的事情自己也一定可以做到。計算機的普及讓更多的人有了學習的機會，也讓更多的人參與到編程人員的隊伍中來，每個人都有編程的權利，機遇給予每個人都是平等的。拿出自己必勝的信心，在編程的道路工勇於進取，相信成功就會在眼前。
三、我可以編程嗎
隨著計算機軟體業的發展，誕生了「程序員」這個職位。於是便形成了一種理念，編寫程 序的人就是程序員，因此編程是程序員的事情。但程序員並不是一開始就是程序員，他們也是從現在我們的位置慢慢成為程序員的。

編寫程序是一件很有趣的事情，因為編寫程序可以干很多高級的事情。例如我們在後面的章節中介紹如何使用Visual Basic編寫Flash動畫播放器，以及如何編寫下載軟體管理器等。如果你願意的話，你完全可以編寫出比這些更高級的程序來。

編程也可以作為——種愛好或興趣，如果你對它感興趣學起來就容易多了!因為如果對編程感興趣的話，就會多看些有關方面的書、多編些小程序上機實踐，這些對於學習編程的幫助是非常大的，而且隨著學習的進程不斷的推進就會覺得它並不是很困難，相反卻是很容易的。

總之，在學習編程時一定要堅持不懈，只要有信心、有毅力就一定能學好；不能因為一些似是而非的觀念就動搖了自己的信心。

四、我們一起來編程

面對擺在面前的計算機該如何操作，相信這個問題已經不再是困擾大家的首要問題了。現在軟體的種類那麼多，在選用的時候「電腦發燒友」的心裡是否也想過有一天自己能編寫一款屬於自己的軟體呢?想學習編程的朋友在選擇程序語言時會不會因為不知道如何選擇而大感頭痛呢?在不知如何下手的時候，朋友們的心中是不是會產生「我是不是可以編程」的思想呢?但是又有哪個程序員是不經過學習就能成功的呢!其實編寫程序並不是人們所想像的那麼困難、那麼復雜，每個有心致力於學習計算機的朋友都是可以嘗試的!

選擇適合自己的程序語言的必要性

目前常用的基本程序語言的種類比較繁多，比較簡單的有：Pascal、c語言、qBasic、 Fortran、Visual Basic等等。但前幾種都是在DOS下進行編程的工具，Visual Basic是在 Windows下進行應用程序設計的編程工具，現在一般的計算機用戶幾乎都不再使用DOS了，因此我們通常會選擇Visual Basic作為初學者的編程工具。Visual Basic是Windows應用程序設計中最容易上手的編程工具，學習步驟也比較容易被初學者接受。對於剛開始學習編程的初學者來說，還是選擇Visual Basic，學習編程語言不能想像著一步登天，一步一個腳印的學習才是最佳方法。

堅定自己學習編寫程序的信心

編寫程序並不是具有專業知識的人員才有的專利，每個學習計算機的人都可以編寫程序，每個人的靈感不同，在編寫程序的思路和作法上又有區別。但共同的想法就是編寫成功的程序。學習編程是一個漫長的過程，其中要付出艱辛的努力和汗水，不過成功者的喜悅又不是別人所能體會的。克服學習中的困難，努力去實踐，要有一個思想：別人能做到的事情自己也一定可以做到。計算機的普及讓更多的人有了學習的機會，也讓更多的人參與到編程人員的隊伍中來，每個人都有編程的權利，機遇給予每個人都是平等的。拿出自己必勝的信心，在編程的道路工勇於進取，相信成功就會在眼前。

7. 嵌入式系統在硬體設計，操作系統的選擇，以及軟體的設計要遵循哪些原則

要把軟體做得非常靈活又要便於維護是一個很困難的事情。靈活的軟體他的結構就復雜，維護起來就困難。有得必有失，關鍵就在於如何處理這兩者，使得大於失。軟體的設計開發應遵循以下六大原則：1. OCP全稱：「Open-Closed Principle」 開放－封閉原則說明：對擴展開放，對修改關閉。優點：按照OCP原則設計出來的系統，降低了程序各部分之間的耦合性，其適應性、靈活性、穩定性都比較好。當已有軟體系統需要增加新的功能時，不需要對作為系統基礎的抽象層進行修改，只需要在原有基搜高礎上附加新的模塊就能實現所需要添加的功能。增加的新模塊對原有的模塊完全沒有影響或影響很小，這樣就無須為原有模塊進行重新測試。如何實現「開-閉」原則在面向對象設計中，不允許更改的是系統的抽象層，而允許擴展的是系統的實現層。換言之，定義一個一勞永逸的好漏燃抽象設計層，允許盡可能多的行為在實現層被實現。解決問題關鍵在於抽象化，抽象化是面向對象設計的第一個核心本質。 對一個事物抽象化，實質上是在概括歸納總結它的本質。抽象讓我們抓住最最重要的東西，從更高一層去思考。這降低了思考的復雜度，我們不用同時考慮那麼多的東西。換言之，我們封裝了事物的本質，看不到任何細節。在面向對象編程中，通過抽象類及介面，規定了具體類的特徵作為抽象層，相對穩定，不需更改，從而滿足「對修改關閉」；而從抽象類導出的具體類可以改變系統的行為，從而滿足「對擴展開放」。對實體進行擴展時，不必改動軟體的源代碼或者二進制代碼。關鍵在於抽象。2. LSP全稱：「Liskov Substitution Principle」 里氏代換原則說明：子類型必須能夠替換它們的基類型。一個軟體實體如果使用的是一個基類，那麼當把這個基類替換成繼承該基類的子類，程序的行為不會發生任何變化。軟體實體察覺不出基類對象和子類對象的區別。優點：可以很容易的實現同一父類下各個子類的互換，而客戶端可以毫不察覺。3. DIP全稱：「Dependence Inversion Principle」依賴倒置原則說明：要依賴於抽象，不要依賴於具體。客戶端依賴於抽象耦合。抽象不應當依賴於細節；細節應當依賴於抽象；要針對介面編程，不針對實現編程。優點：使用傳統過程化程序設計所創建的依賴關系，策略依賴於細節，這是糟糕的，因為策略受到細節改變的影響。依賴倒置原則使細節和策略都依賴於抽象，抽象的穩定性決定了系統的穩定性。怎樣做到依賴倒置？以抽象方式耦合是依賴倒轉原則的關鍵。抽象耦合關系總要涉及具體類從抽象類繼承，並且需要保證在任何引用到基類的地方都可以改換成其子類，因此，里氏代換友虛原則是依賴倒轉原則的基礎。在抽象層次上的耦合雖然有靈活性，但也帶來了額外的復雜性，如果一個具體類發生變化的可能性非常小，那麼抽象耦合能發揮的好處便十分有限，這時可以用具體耦合反而會更好。層次化：所有結構良好的面向對象構架都具有清晰的層次定義，每個層次通過一個定義良好的、受控的介面向外提供一組內聚的服務。依賴於抽象：建議不依賴於具體類，即程序中所有的依賴關系都應該終止於抽象類或者介面。盡量做到：1、任何變數都不應該持有一個指向具體類的指針或者引用。2、任何類都不應該從具體類派生。3、任何方法都不應該覆寫它的任何基類中的已經實現的方法。4. ISP全稱：「Interface Segregation Principle」 介面隔離原則說明：使用多個專一功能的介面比使用一個的總介面總要好。從一個客戶類的角度來講：一個類對另外一個類的依賴性應當是建立在最小介面上的。過於臃腫的介面是對介面的污染，不應該強迫客戶依賴於它們不用的方法。優點：會使一個軟體系統功能擴展時，修改的壓力不會傳到別的對象那裡。如何實現介面隔離原則不應該強迫用戶依賴於他們不用的方法。1、利用委託分離介面。2、利用多繼承分離介面。5. CARP or CRP全稱：「Composite/Aggregate Reuse Principle」 合成/聚合復用原則 or 「Composite Reuse Principle」 合成復用原則說明：如果新對象的某些功能在別的已經創建好的對象裡面已經實現，那麼盡量使用別的對象提供的功能，使之成為新對象的一部分，而不要自己再重新創建。新對象通過向這些對象的委派達到復用已有功能的。簡而言之，要盡量使用合成/聚合，盡量不要使用繼承。優點：1) 新對象存取成分對象的唯一方法是通過成分對象的介面。2) 這種復用是黑箱復用，因為成分對象的內部細節是新對象所看不見的。3) 這種復用支持包裝。4) 這種復用所需的依賴較少。5) 每一個新的類可以將焦點集中在一個任務上。6) 這種復用可以在運行時間內動態進行，新對象可以動態的引用與成分對象類型相同的對象。7) 作為復用手段可以應用到幾乎任何環境中去。缺點:就是系統中會有較多的對象需要管理。6. LOD or LKP全稱：「Law of Demeter」 迪米特原則 or 「Least Knowledge Principle」 最少知識原則說明：對象與對象之間應該使用盡可能少的方法來關聯，避免千絲萬縷的關系。如何實現迪米特法則迪米特法則的主要用意是控制信息的過載，在將其運用到系統設計中應注意以下幾點：1) 在類的劃分上，應當創建有弱耦合的類。類之間的耦合越弱，就越有利於復用。2) 在類的結構設計上，每一個類都應當盡量降低成員的訪問許可權。一個類不應當public自己的屬性，而應當提供取值和賦值的方法讓外界間接訪問自己的屬性。3) 在類的設計上，只要有可能，一個類應當設計成不變類。4) 在對其它對象的引用上，一個類對其它對象的引用應該降到最低。

還有個單一職責原則：
SRP簡介（SRP--Single-Responsibility Principle）： 就一個類而言，應該只專注於做一件事和僅有一個引起它變化的原因。所謂職責，我們可以理解他為功能，就是設計的這個類功能應該只有一個，而不是兩個或更多。也可以理解為引用變化的原因，當你發現有兩個變化會要求我們修改這個類，那麼你就要考慮撤分這個類了。因為職責是變化的一個軸線，當需求變化時，該變化會反映類的職責的變化。 使用SRP注意點： 1、一個合理的類，應該僅有一個引起它變化的原因，即單一職責；
2、在沒有變化徵兆的情況下應用SRP或其他原則是不明智的；
3、在需求實際發生變化時就應該應用SRP等原則來重構代碼；
4、使用測試驅動開發會迫使我們在設計出現臭味之前分離不合理代碼；
5、如果測試不能迫使職責分離，僵化性和脆弱性的臭味會變得很強烈，那就應該用Facade或Proxy模式對代碼重構； SRP優點： 消除耦合，減小因需求變化引起代碼僵化性臭味

8. J2ME程序設計原則是什麼

J2ME程序設計原則：
1、使用面向對象編程。
雖然使用面向過程編程可以減小文件的尺寸，但是為了以後維護的方便和利於擴展，還是要使用面向對象編程。

2、使用MVC模式
將模型、界面和控制分離。現在很多的程序將三者合一，但是如果你做的程序比較大的話，還是建議你進行分離。

3、自動存儲用戶設定
使用RMS來存儲用戶的信息，例如存儲用戶上次輸入的用戶名、密碼、用戶對於系統的設定等，這樣不僅可以薯漏衫減少用戶的輸入，而且對用戶友好。很多程序甚至做了自動登陸等。

4、一些系統設置允許用戶關閉。如背景音樂、背景燈顯示等。
5、將低級用戶界面的繪制動作放在一個獨立的線程裡面去。
6、在需要大量時間才能完成的工作時，給用戶一個等待界面。

J2ME（Java 2 micro Edition）是一種高度優化的Java運行環境,針對市面上的大量消費類電子設備,例如Papers、cellularphones(蜂窩電話), screen-phones(可視電話?)、digital set-top boxes(數字機頂盒)、car navigation systems(汽車導航系統)等等。 J2ME技術在1999年的JavaOne Developer Conference大會上推出。J2ME技術將Java語言的與平台無關的特性移植到小型電子設備上,允許移動無線設備之間共享應用程序。

J2ME開發數腔步驟
1. 系統要求
v Pentium 100以上CPU
v 64MB 內存
v Windows NT Workstation 4.0(Service Pack 3)或Windows 98
v 6 MB自由搜搭硬碟空間
v Java 2 SDK, Standard Version, 版本1.2.2或者更高

2. 安裝Java 2 SDK
在使用Motorola SDK之前必須安裝JDK，Standard Edition。
請從 http://java.sun.com/procts/jdk 下載JDK，並按照Sun的指導安裝到PC中。

3. 安裝Motorola SDK
安裝之前請先卸載以前版本的Motorola SDK：
1. 選擇"開始à設置à控制板"
2. 選擇"添加/刪除程序"
3. 查找到"Motorola SDK Components for the J2ME Platform"

9. 設計可復用的面向對象軟體(設計模式可復用面向對象軟體的基礎pdf)

如何設計可復用的面向對象軟體。必須要找到相關的對象，以適當的粒度將它們歸類，再定義類的介面和繼承層次，建立對象之間的基本關系。你的設計應該對手頭的問題有針對性，同時對將來的問題和需求也要有足夠的通用性。每一個設計模式系統的命名、解釋和評價了面向對象系統中一個重要的和重復出現的櫻肢設計。設計模式使人們可以更加簡單方便的復用成功的設計和體系結構。

每一個模式描述了一個在我們周圍不斷重復發生的問題，以及該問題的解決方案的核心。這樣你就可以一次又一次的使用該解決方案而不做重復性的勞動。設計模式有四個基本要素：模式名稱、問題、解決方案、效果。

按照模式的目的性准則，模式可以分為創建型模式、結構型模式和行為型模式。創建擾頌型模式與對象的創建有關；結構型模式處理類和對象的組合；行為型模式對類和對象怎樣交互和怎樣分配職責進行描述。

按照模式的范圍准則，模式可以分為類模式和對象模式。類模式處理類和子類的關系，這些關系通過繼承建立，是靜態的，在編譯時就確定下來。對象模式是處理對象之間的關系，這些關系在運行時刻是可以變化的，更具動態性。

創建型類模式將對象的創建工作部分延遲到子類。創建型對象模式則是將它延遲到另一個對象中。

結構型類模式使用繼承機制來組合類。結構型對象模式則描述了對象的組裝方式。

行為型類模式使用繼承描述演算法和控制流。行為型對象模式描述使用一組對象怎樣協作完成單個對象無法完成的任務。

設計模式採用多種方法解決面向對象設計者經常碰到的問題。下面給出怎樣使用設計模式。

1、尋找合適的對象。面向對象的程序由對象組成，對象包括數據以及對數據進行的操作。對象在收到客戶的請求後，執行相應的操作。面向對象設計最困難的地方是把系統分解成對象集合。一般的方法是寫出一個問題的描述，挑出名詞和動詞，進而創建相應的類和操作。

2、決定對象的粒度。我們可以根據需要把一個大的對象，分解成許多小粒度的對象。

3、指定對象的介面。對象操作的型構，是指為對象聲明的每一個操作指定操作名、作為參數的對象和返回值。所有對象型構的集合稱為介面。對象介面描述了該對象所能接受的全部請求的集合，任何匹配對象介面的請求都可以發送給該對象。類型是用來標識特定介面的一個名字。在面向對象系統中，介面是基本的組成部分。對象只有通過它們的介面才能與外部聯系。但是，對象介面與其功能實現是分離的，也就是說兩個相同介面的對象可以有完全不一樣的實現。

4、描述對象的實現。對象的創建是通過類來決定的。類指定了對象的內部數據和操作。理解對象的類和對象的類型之間的差別非常重要。一個對象的類定義了對象是怎樣實現的，但對象類型則描緩頌鄭述了對象所能接受的所有客戶請求。同時還要區分類繼承和介面繼承，類繼承根據一個對象的實現來定義另一個類的實現。而介面繼承則是描述了一個對象什麼時候能被用來替代另一個對象。可復用的面向對象設計要遵循如下原則：針對介面編程，而不是針對實現編程。不將變數聲明為某個特定的具體類的實例對象，而是讓它遵從抽象類所定義的介面。這樣做有兩個好處。一是，客戶無須知道他們使用對象的特定類型，只需知道對象有客戶所期望的介面。二是，客戶無須知道他們使用的對象是用什麼類來實現的，只需知道定義介面的抽象類。

5、運用復用機制。面向對象系統中功能復用的兩種最常用技術是類繼承和對象組合。類繼承是指要產生的類是通過其它類來產生的。這種生成子類的復用稱為白箱復用，在生成過程中父類的內部細節對子類是完全可見的。對象組合是指新的功能是通過組裝和組合對象來獲得。這種復用成為黑箱復用。面向對象設計的第二原則是：優先使用對象組合，而不是類繼承。委託是一種組合方法，它使組合具有與繼承同樣的復用能力。在委託方式下，有兩個對象參與處理一個請求，接受請求的對象將操作委託給它的代理者。委託是對象組合的特例，它告訴你對象組合作為一個代碼復用機制可以替代繼承。

6、關聯運行時刻和編譯時刻的結構。一個面向對象系統運行時刻的結構與它的代碼結構相差較大。代碼結構在編譯時刻就被確定下來了，它由繼承關系固定的類組成。運行時刻的結構是由快速變化的通信對象網路組成。聚合意味著一個對象擁有另一個對象，也就意味著它們具有相同的生命周期。相識意味著一個對象僅僅知道另一個對象的類型。

7、設計應支持變化。一個健壯的系統，在設計時一定要考慮，在其生命周期內會發生怎樣的變化。

10. 為建立良好的編程風格應遵循什麼原則

一、程序內部文檔應具備的規則
1、標識符應含有含義鮮明的文字。
含義鮮明的文字，能正確地提示程序對象所代表的實體。這對於幫助閱讀者理解程序是非常重要的。如果用縮寫的形式，那麼縮寫規則應該一致，並且應該給每個名字加註解。在VB中，主要有如下的約定：
（一）對象命名約定
應該使用一致的前綴來命名對象，使人們容易識別對象的類型。例如我們常用控制項CommandButton(命令按鈕)可用cmd做為其前綴。Form以frm,Image以 img ,Label以 lbl,List Box 以lst,PictureBox以 pic,Timer以 tmr，等等，在我們編程的過程中，我們看到下面的名稱cmdExit我們就知道這一定是一個命令按鈕了。如果是第三方提供的控制項，我們的說明最好要清晰地標出製造商的名稱，以區別於我們的常用控制項。
（二）常量和變數命名約定
除了控制項以外，常量和變數也是我們編程過程中經常遇到的，我們和他們打交道也是通過名字。
（1）給變數加范圍前綴
變數按其作用范圍可分做三類，過程級，模塊級和全局，所以我們在編程的過程中應將三者加以區別。我們在使用變數時，為了更好地體現代碼重用和可維護原則，其定義范圍應盡量縮小，這樣將使我們的應用程序更加容易理解和易於控制。在VB應用程序中，只有當沒有其他方便途徑在窗體間共享數據時才使用全局變數。當使用全局變數時，在一個單一模塊中聲明它們，並按功能分組，給模塊取一個有意義的名字。較好的編碼習慣是盡可能地定模塊化的代碼。除了全局變數，過程和函數應該僅對傳遞給它們的的對象操作。在過程中使用的全局變數應該在過程起始處的聲明部分標識出來。變數的作用范圍前綴如下：全局 g(global) ,模塊級 m(model)，本地過程不需要使用。例如：gintFlag,表示全局整型變數，mstrPassword,可表示模塊級字元型變數。
（2）聲明所有變數原則。聲明所有變數將會節省編程時間，鍵入錯誤將大大減少，我們可在程序開始寫上如下語句：
Option Explicit
該語句要求在程序中聲明所有變數。
（3）變數數據類型聲明。可通過下面的前綴來做為變數的數據類標志。
Boolean bln
Byte byt
Double dbl
Integer int
String str
（4）常量。常量的命名，可遵循與變數命名大體相同的原則。
（5）對變數和過程名作出描述。變數或過程名的主體應該使用大小寫混合的形式，並且應該足夠長以描述它的作用。而且，函數名應以一個動詞開頭。如JudgeDialog。

2、適當的註解
註解是程序員和程序讀者通信的重要手段，正確的註解非常有助於對程序的理解。VB中代碼註解約定如下：所有的過程和函數都應該以描述這段過程的功能的一段簡明的注釋開始，說明該程序是干什麼的，至於是如何做的，也就是編程的細節，最好不要包括。因為可能日後我們要修改程序，這樣做會帶來不必要的注釋維護工作，如果不修改，將提供誤導信息，可能成為錯誤的注釋。因為代碼本身和後面程序中的注釋將起到相應的說明作用。
過程中的注釋塊應該包括如下標題：
小節描述內容
目的該過程完成什麼
假設列出每個外部變數、控制項、打開文件或其他不明顯元素
效果列出每個被影響的外部變數、控制項或文件及其作用（只有當它不明顯時）
輸入每一個可能不明顯的參數。
返回函數返回值的說明
格式化代碼
（1）標準的，基於製表位的嵌套應該包括一個嵌注釋，來描述該變數的使用。
（2）變數、控制項及過程的命名應該足夠清楚，使得只有復雜的執行細節才需要嵌入注釋。
（3）.bas 模塊包含包含工程的VB一般常量聲明，在其起始處，應包括程序的綜述，列舉主要數據對象，過程、演算法、對話、資料庫及系統需求。

3、程序的視覺組織
程序的視覺組織可用階梯式，結構化的程序風格對於我們實際編程也很有意義，可極大地改善代碼的可讀性。主要有代碼注釋和一致性縮進。

---------------------------------------------------------------------------------------------------------
二、數據說明
數據結構的組織和復雜程序是在設計期間就已經確定了的，然而數據說明的風格卻是在寫程序時確定的。為了使數據更容易理解和維護，有一些比較簡單的原則應該遵循。
1、數據說明的次序應該標准化。有次序就容易查閱。因此能夠加速測試、調試和維護的過程。當多個變數名在一個語句中說明時，應按字母順序排列這些變數。
2、數據結構復雜時，應加以說明其特點和實現方法。

---------------------------------------------------------------------------------------------------------
三、語句構造
語句構造原則:每個語句應該簡單而直接，不能為了提高效率而使程序變得過分復雜。下述規則的使用有助於語句簡單明了。
1、不要為了節省空間把多行語句寫在一行；
2、盡量避免復雜的條件測試；
3、盡量減少對「非」條件的測試；
4、避免大量使用循環嵌套和條件嵌套；
5、利用括弧使邏輯表達式或算術表達式的運算次序清晰直觀。

---------------------------------------------------------------------------------------------------------
四、輸入輸出
1、對所有輸入數據都進行檢驗；
2、檢查輸入項重要組合的合法性；
3、保持輸入格式簡單；
4、使用數據結束標志，不要要求用戶指定輸入數據的數目
5、明確提示互動式輸入的請求，詳細說明可用的選擇或邊界數值；
6、當語言對格式有嚴格要求時，應保持輸入格式一致
7、設計良好的輸出報表；
8、給所有輸出加標志；

---------------------------------------------------------------------------------------------------------
五、效率
效率三原則：
1、效率是性能的要求，需求分析時就應確定；
2、效率是靠設計提高的；
3、程序的效率和程序的簡單程序是一致的。
（一）運行時間
（1）寫程序前先簡化算術和邏輯表達式；
（2）他細研究嵌套的循環，以確定是否有語句從內層移到外層；
（3）盡量避免使用多維數組；
（4）盡量避免使用指針和復雜的表；
（5）使用執行時間短的算術運算；
（6）不要混合使用不同的數據類型；
（7）盡量使用整數運算和布爾表達式
（二）存儲器效率
（三）輸入輸出效率
如果用戶是為了給計算機提供輸入信息或為了理解計算機輸入的信息，所需花費的腦力勞動是經濟的，那麼，人和計算機之間的通信效率就高。簡單清晰是關鍵。

---------------------------------------------------------------------------------------------------------
六、小結
其實風格是非常重要的，程序的外表是我們交流中不可缺少的東西。象我們常說的紅顏命薄而歸疚於外表太靚，也常聽一些才子佳人的悲劇故事，提醒我們外表美而引出的一見鍾情的浪漫不可取。可讓人細想，才子佳人產生悲劇雖多，可也讓人找到過心動和美好的感覺，做為一個人，活了一輩子，連那種感覺都未體驗到，豈不比悲劇更加令人覺得可悲！編程亦然。