Java程序員應該了解的10個面向對象設計原則

2019-11-06 06:38:15

字體：大中小

來源：轉載

供稿：網友

一、題前話

本人一直崇尚一個原則，“我思，故我在！”。一直以來忙于編碼，但是不甚如人意（寫了較多重復性、耦合性太強的代碼）。行有行規，面向對象編程的java語言也不例外，遵循其相關原則，才能高效快速的編寫高性能的代碼。那么期間過程學習很重要，從一開始的基礎知識學習，到大量的編寫代碼，回過頭來再將學習的理論和實踐相結合，每一個環節都很重要，這樣才能成為高手，特別是最后一環（將理論與實踐相結合——重構之前不符合理論原則的代碼，反過來加深理論的理解）。

二、正題

一般對Java面向對象編程的高度概括是——三大基本特性（封裝、繼承、多態）和五大基本原則（SOLID）

1）三大特性是：封裝,繼承,多態

所謂封裝，也就是把客觀事物封裝成抽象的類，并且類可以把自己的數據和方法只讓可信的類或者對象操作，對不可信的進行信息隱藏。封裝是面向對象的特征之一，是對象和類概念的主要特性。簡單的說，一個類就是一個封裝了數據以及操作這些數據的代碼的邏輯實體。在一個對象內部，某些代碼或某些數據可以是私有的，不能被外界訪問。通過這種方式，對象對內部數據提供了不同級別的保護，以防止程序中無關的部分意外的改變或錯誤的使用了對象的私有部分。

所謂繼承是指可以讓某個類型的對象獲得另一個類型的對象的屬性的方法。它支持按級分類的概念。繼承是指這樣一種能力：它可以使用現有類的所有功能，并在無需重新編寫原來的類的情況下對這些功能進行擴展。通過繼承創建的新類稱為“子類”或“派生類”，被繼承的類稱為“基類”、“父類”或“超類”。繼承的過程，就是從一般到特殊的過程。要實現繼承，可以通過“繼承”（Inheritance）和“組合”（Composition）來實現。繼承概念的實現方式有二類：實現繼承與接口繼承。實現繼承是指直接使用基類的屬性和方法而無需額外編碼的能力；接口繼承是指僅使用屬性和方法的名稱、但是子類必須提供實現的能力；

所謂多態就是指一個類實例的相同方法在不同情形有不同表現形式。多態機制使具有不同內部結構的對象可以共享相同的外部接口。這意味著，雖然針對不同對象的具體操作不同，但通過一個公共的類，它們（那些操作）可以通過相同的方式予以調用。

2）五大基本原則單一職責原則SRP(Single Responsibility PRinciple)是指一個類的功能要單一，不能包羅萬象。如同一個人一樣，分配的工作不能太多，否則一天到晚雖然忙忙碌碌的，但效率卻高不起來。開放封閉原則OCP(Open－Close Principle) 一個模塊在擴展性方面應該是開放的而在更改性方面應該是封閉的。比如：一個網絡模塊，原來只服務端功能，而現在要加入客戶端功能，那么應當在不用修改服務端功能代碼的前提下，就能夠增加客戶端功能的實現代碼，這要求在設計之初，就應當將服務端和客戶端分開，公共部分抽象出來。替換原則(the Liskov Substitution Principle LSP) 子類應當可以替換父類并出現在父類能夠出現的任何地方。比如：公司搞年度晚會，所有員工可以參加抽獎，那么不管是老員工還是新員工，也不管是總部員工還是外派員工，都應當可以參加抽獎，否則這公司就不和諧了。依賴原則(the Dependency Inversion Principle DIP) 具體依賴抽象，上層依賴下層抽象接口。假設B是較A低的模塊，但B需要使用到A的功能，這個時候，B不應當直接使用A中的具體類：而應當由B定義一抽象接口，并由A來實現這個抽象接口，B只使用這個抽象接口：這樣就達到了依賴倒置的目的，B也解除了對A的依賴，反過來是A依賴于B定義的抽象接口。通過上層模塊難以避免依賴下層模塊，假如B也直接依賴A的實現，那么就可能造成循環依賴。

接口分離原則(the Interface Segregation Principle ISP) 模塊間要通過抽象接口隔離開，而不是通過具體的類強耦合起來

三、正正題

下面的總結10個面向對象基本原則總結的也不錯，記錄如下

面向對象設計原則是OOPS（Object-Oriented Programming System，面向對象的程序設計系統）編程的核心，但大多數Java程序員追逐像Singleton、Decorator、Observer這樣的設計模式，而不重視面向對象的分析和設計。甚至還有經驗豐富的Java程序員沒有聽說過OOPS和SOLID設計原則，他們根本不知道設計原則的好處，也不知道如何依照這些原則來進行編程。眾所周知，Java編程最基本的原則就是要追求高內聚和低耦合的解決方案和代碼模塊設計。查看Apache和Sun的開放源代碼能幫助你發現其他Java設計原則在這些代碼中的實際運用。Java Development Kit則遵循以下模式：BorderFactory類中的工廠模式、Runtime類中的單件模式。你可以通過Joshua Bloch的《Effective Java》一書來了解更多信息。我個人偏向的另一種面向對象的設計模式是Kathy Sierra的Head First Design Pattern以及Head First Object Oriented Analysis and Design。雖然實際案例是學習設計原則或模式的最佳途徑，但通過本文的介紹，沒有接觸過這些原則或還在學習階段的Java程序員也能夠了解這10個面向對象的設計原則。其實每條原則都需要大量的篇幅才能講清楚，但我會盡力做到言簡意賅。原則1：DRY（Don't repeat yourself） 即不要寫重復的代碼，而是用“abstraction”類來抽象公有的東西。如果你需要多次用到一個硬編碼值，那么可以設為公共常量；如果你要在兩個以上的地方使用一個代碼塊，那么可以將它設為一個獨立的方法。SOLID設計原則的優點是易于維護，但要注意，不要濫用，duplicate 不是針對代碼，而是針對功能。這意味著，即使用公共代碼來驗證OrderID和SSN，二者也不會是相同的。使用公共代碼來實現兩個不同的功能，其實就是近似地把這兩個功能永遠捆綁到了一起，如果OrderID改變了其格式，SSN驗證代碼也會中斷。因此要慎用這種組合，不要隨意捆綁類似但不相關的功能。原則2：封裝變化 在軟件領域中唯一不變的就是“Change”，因此封裝你認為或猜測未來將發生變化的代碼。OOPS設計模式的優點在于易于測試和維護封裝的代碼。如果你使用Java編碼，可以默認私有化變量和方法，并逐步增加訪問權限，比如從private到protected和not public。有幾種Java設計模式也使用封裝，比如Factory設計模式是封裝“對象創建”，其靈活性使得之后引進新代碼不會對現有的代碼造成影響。原則3：開閉原則 即對擴展開放，對修改關閉。這是另一種非常棒的設計原則，可以防止其他人更改已經測試好的代碼。理論上，可以在不修改原有的模塊的基礎上，擴展功能。這也是開閉原則的宗旨。原則4：單一職責原則 類被修改的幾率很大，因此應該專注于單一的功能。如果你把多個功能放在同一個類中，功能之間就形成了關聯，改變其中一個功能，有可能中止另一個功能，這時就需要新一輪的測試來避免可能出現的問題。原則5：依賴注入或倒置原則 這個設計原則的亮點在于任何被DI框架注入的類很容易用mock對象進行測試和維護，因為對象創建代碼集中在框架中，客戶端代碼也不混亂。有很多方式可以實現依賴倒置，比如像aspectJ等的AOP（Aspect Oriented programming）框架使用的字節碼技術，或Spring框架使用的代理等。原則6：優先利用組合而非繼承 如果可能的話，優先利用組合而不是繼承。一些人可能會質疑，但我發現，組合比繼承靈活得多。組合允許在運行期間通過設置類的屬性來改變類的行為，也可以通過使用接口來組合一個類，它提供了更高的靈活性，并可以隨時實現?！禘ffective Java》也推薦此原則。 原則7：里氏代換原則（LSP） 根據該原則，子類必須能夠替換掉它們的基類，也就是說使用基類的方法或函數能夠順利地引用子類對象。LSP原則與單一職責原則和接口分離原則密切相關，如果一個類比子類具備更多功能，很有可能某些功能會失效，這就違反了LSP原則。為了遵循該設計原則，派生類或子類必須增強功能。原則8：接口分離原則 采用多個與特定客戶類有關的接口比采用一個通用的涵蓋多個業務方法的接口要好。設計接口很棘手，因為一旦釋放接口，你就無法在不中斷執行的情況下改變它。在Java中，該原則的另一個優勢在于，在任何類使用接口之前，接口不利于實現所有的方法，所以單一的功能意味著更少的實現方法。原則9：針對接口編程，而不是針對實現編程 該原則可以使代碼更加靈活，以便可以在任何接口實現中使用。因此，在Java中最好使用變量接口類型、方法返回類型、方法參數類型等?！禘ffective Java》和《head first design pattern》書中也有提到。原則10：委托原則 該原則最典型的例子是Java中的equals() 和 hashCode() 方法。為了平等地比較兩個對象，我們用類本身而不是客戶端類來做比較。這個設計原則的好處是沒有重復的代碼，而且很容易對其進行修改?？傊?，希望這些面向對象的設計原則能幫助你寫出更靈活更好的代碼。理論是第一步，更重要的是需要開發者在實踐中去運用和體會。

四、英文原文

Object Oriented Design Principles are core of OOP programming, but I have seen most of the Java programmers chasing design patterns likeSingleton pattern, Decorator pattern or Observer pattern, and not putting enough attention on learningObject oriented analysis and design. It's important to learn basics of Object oriented programming like Abstraction, Encapsulation, Polymorphism and Inheritance. But, at the same time, it's equally important to know object oriented design principles, to create clean and modular design. I have regularly seen Java programmers and developers of various experience level, who either doesn't heard about theseOOP and SOLID design principle, or simply doesn't know whatbenefits a particular design principle offers, or how to apply these design principle in coding. Bottom line is, always strive for highly cohesive and loosely couple solution, code or design. Looking open source code from Apache and Sun are good examples of learning Java and OOPS design principles. They show us, how design principles should be used in coding and Java programs. Java Development Kit follows several design principle like Factory Pattern inBorderFactory class, Singleton pattern inRuntime class, Decorator pattern on variousjava.io classes. By the way if you really interested more on Java coding practices then read Effective Java by Joshua Bloch , a gem by the guy who wrote Java Collection API. If you are interested in learning object oriented principles and patterns, then you can look at my another personal favoriteHead First Object Oriented Analysis and Design. This an Excellent book and probably the best material available in object oriented analysis and design, but it often shadowed by its more popular cousin Head First Design Pattern by Eric Freeman. Later is more about how these principle comes together to create pattern you can use directly to solve known problems. These books helps a lot to write better code, taking full advantage of various Object oriented and SOLID design principles.

Object oriented design principles and pattern in Java programming

Though best way of learning any design principle or pattern is real world example and understanding the consequences of violating that design principle, subject of this article is IntroducingObject oriented design principles for Java Programmers, who are either not exposed to it or in learning phase. I personally think each of these OOPS and SOLID design principle need an article to explain them clearly, and I will definitely try to do that here, but for now just get yourself ready for quick bike ride on design principle town :)

DRY (Don't repeat yourself)

Our first object oriented design principle is DRY, as name suggestDRY (don't repeat yourself) means don't write duplicate code, instead useAbstraction to abstract common things in one place. If you have block of code in more than two place consider making it a separate method, or if you use a hard-coded value more than one time make thempublic final constant. Benefit of this Object oriented design principle is in maintenance. It's important not to abuse it, duplication is not for code, but for functionality . It means, if you used common code to validateOrderID and SSN it doesn’t mean they are same or they will remain same in future. By using common code for two different functionality or thing you closely couple them forever and when your OrderID changes its format , your SSN validation code will break. So beware of such coupling and just don’t combine anything which uses similar code but are not related.

Encapsulate What Changes

Only one thing is constant in software field and that is "Change", So encapsulate the code you expect or suspect to be changed in future. Benefit of this OOPS Design principle is that Its easy to test and maintain proper encapsulated code. If you are coding in Java then follow principle of making variable and methods private by default and increasing access step by step e.g. from private to protected and not public. Several ofdesign pattern in Java uses Encapsulation, Factory design pattern is one example of Encapsulation which encapsulate object creation code and provides flexibility to introduce new product later with no impact on existing code.

Open Closed Design Principle

Classes, methods or functions should be Open for extension (new functionality) and Closed for modification. This is another beautiful SOLID design principle, which prevents some-one from changing already tried and tested code. Ideally if you are adding new functionality only than your code should be tested and that's the goal ofOpen Closed Design principle. By the way, Open Closed principle is "O" from SOLID acronym. Single Responsibility Principle (SRP)Single Responsibility Principle is another SOLID design principle, and represent "S" on SOLID acronym. As per SRP, there should not be more than one reason for a class to change, or a class should always handle single functionality. If you put more than one functionality in one Class in Java it introduce coupling between two functionality and even if you change one functionality there is chance you broke coupled functionality, which require another round of testing to avoid any surprise on production environment.

Dependency Injection or Inversion principle

Don't ask for dependency it will be provided to you by framework. This has been very well implemented in Spring framework, beauty of thisdesign principle is that any class which is injected by DI framework is easy to test with mock object and easier to maintain because object creation code is centralized in framework and client code is not littered with that.There are multiple ways to implemented Dependency injection like using byte code instrumentation which some AOP (Aspect Oriented programming) framework like AspectJ does or by using proxies just like used in Spring. See thisexample of IOC and DI design pattern to learn more about this SOLID design principle. It represent "D" on SOLID acronym.

Favor Composition over Inheritance

Always favor composition over inheritance ,if possible. Some of you may argue this, but I found that Composition is lot more flexible thanInheritance. Composition allows to change behavior of a class at run-time by setting property during run-time and by using Interfaces to compose a class we usepolymorphism which provides flexibility of to replace with better implementation any time. Even Effective Java advise to favor composition over inheritance. Seehere to learn more about why you Composition is better than Inheritance for reusing code and functionality.

Liskov Substitution Principle (LSP)

According to Liskov Substitution Principle, Subtypes must be substitutable for super type i.e. methods or functions which uses super class type must be able to work withobject of sub class without any issue". LSP is closely related to Single responsibility principle andInterface Segregation Principle. If a class has more functionality than subclass might not support some of the functionality ,and does violated LSP. In order to followLSP SOLID design principle, derived class or sub class must enhance functionality, but not reduce them. LSP represent "L" on SOLID acronym.

Interface Segregation principle (ISP)

Interface Segregation Principle stats that, a client should not implement aninterface, if it doesn't use that. This happens mostly when one interface contains more than one functionality, and client only need one functionality and not other.Interface design is tricky job because once you release your interface you can not change it without breaking all implementation. Another benefit of this design principle in Java is, interface has disadvantage to implement all method before any class can use it so having single functionality means less method to implement.

Programming for Interface not implementation

Always program for interface and not for implementation this will lead to flexible code which can work with any new implementation of interface. So use interface type on variables, return types of method or argument type of methods in Java. This has been advised by many Java programmer including in Effective Java and Head First design pattern book.

Delegation principle

Don't do all stuff by yourself, delegate it to respective class. Classical example of delegation design principle isequals() and hashCode() method in Java. In order to compare two object for equality we ask class itself to do comparison instead of Client class doing that check. Benefit of this design principle is no duplication of code and pretty easy to modify behavior.Here is nice summary of all these OOP design principles : Object oriented and SOLID design principle in Java

Object oriented and SOLID design principle in Java

All these object oriented design principle helps you write flexible and better code by striving high cohesion and low coupling. Theory is first step, but what is most important is todevelop ability to find out when to apply these design principle. Find out, whether we are violating any design principle and compromising flexibility of code, but again as nothing is perfect in this world, don't always try to solve problem with design patterns and design principle they are mostly for large enterprise project which has longer maintenance cycle.Recommended books to learn Object Oriented analysis, design and patterns :Head First Design Pattern by Eric Freeman [see here ]Head First Object Oriented Analysis and Design by O'Rielly [see here]

Read more: http://javarevisited.blogspot.com/2012/03/10-object-oriented-design-principles.html#ixzz4aWzMOH00 （需要翻墻）

參考：http://www.iteye.com/news/24488

http://www.cnblogs.com/hnrainll/archive/2012/09/18/2690846.html

上一篇：Java定時器timer.schedule的一些問題

下一篇：java基礎---->Java Collections Framework 概述