- 浏览: 77054 次
文章分类
- 全部博客 (89)
- web service (9)
- subversion (1)
- JBOSS (3)
- interview (23)
- jQery (2)
- ExtJs (0)
- Axis (0)
- Design pattern (3)
- Agile (2)
- mutithread (0)
- Core Java (24)
- programming methods (1)
- SSH (7)
- jee design (1)
- OO (4)
- books (8)
- other (1)
- JSF (7)
- seam (2)
- Weblogic (4)
- JPA (1)
- ADF (1)
- Spring (5)
- Tomcat (1)
- DWR (2)
- JEE (3)
- Servlet (1)
- EJB (1)
- JDBC (3)
最新评论
-
iloveflower:
呵呵。好好学习。。。。。。。。。。。。
java 读书 -
Eric.Yan:
看了一点,不过是电子版的……你这一说到提醒我了,还要继续学习哈 ...
java 读书
What are Software Design Principles?
Software design principles represent a set of guidelines that helps us to avoid having a bad design. The design principles are associated to Robert Martin who gathered them in "Agile Software Development: Principles, Patterns, and Practices". According to Robert Martin there are 3 important characteristics of a bad design that should be avoided:
Rigidity - It is hard to change because every change affects too many other parts of the system.
Fragility - When you make a change, unexpected parts of the system break.
Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application.
*******************************************************
Open Close Principle
Software entities like classes, modules and functions should be open for extension but closed for modifications.
OPC is a generic principle. You can consider it when writing your classes to make sure that when you need to extend their behavior you don�t have to change the class but to extend it. The same principle can be applied for modules, packages, libraries. If you have a library containing a set of classes there are many reasons for which you�ll prefer to extend it without changing the code that was already written (backward compatibility, regression testing, �). This is why we have to make sure our modules follow Open Closed Principle.
When referring to the classes Open Close Principle can be ensured by use of Abstract Classes and concrete classes for implementing their behavior. This will enforce having Concrete Classes extending Abstract Classes instead of changing them. Some particular cases of this are Template Pattern and Strategy Pattern.
Dependency Inversion Principle
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
Dependency Inversion Principle states that we should decouple high level modules from low level modules, introducing an abstraction layer between the high level classes and low level classes. Further more it inverts the dependency: instead of writing our abstractions based on details, the we should write the details based on abstractions.
Dependency Inversion or Inversion of Control are better know terms referring to the way in which the dependencies are realized. In the classical way when a software module(class, framework, �) need some other module, it initializes and holds a direct reference to it. This will make the 2 modules tight coupled. In order to decouple them the first module will provide a hook(a property, parameter, �) and an external module controlling the dependencies will inject the reference to the second one.
By applying the Dependency Inversion the modules can be easily changed by other modules just changing the dependency module. Factories and Abstract Factories can be used as dependency frameworks, but there are specialized frameworks for that, known as Inversion of Control Container.
Interface Segregation Principle
Clients should not be forced to depend upon interfaces that they don't use.
This principle teaches us to take care how we write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well. For example if we create an interface called Worker and add a method lunch break, all the workers will have to implement it. What if the worker is a robot?
As a conclusion Interfaces containing methods that are not specific to it are called polluted or fat interfaces. We should avoid them.
Single Responsibility Principle
A class should have only one reason to change.
In this context a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it. When we need to make a change in a class having more responsibilities the change might affect the other functionality of the classes.
Single Responsibility Principle was introduced Tom DeMarco in his book Structured Analysis and Systems Specification, 1979. Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.
Liskov's Substitution Principle
Derived types must be completely substitutable for their base types.
This principle is just an extension of the Open Close Principle in terms of behavior meaning that we must make sure that new derived classes are extending the base classes without changing their behavior. The new derived classes should be able to replace the base classes without any change in the code.
Liskov's Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on Object Oriented Programming Systems Languages and Applications, in Data abstraction and hierarchy
Creational Patterns
Singleton
Factory
Factory Method
Abstract Factory
Builder
Prototype
Object Pool
Behavioral Patterns
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
Strategy
Template Method
Visitor
Null Object
Structural Patterns
Adapter
Bridge
Composite
Decorator
Flyweight
Proxy
Software design principles represent a set of guidelines that helps us to avoid having a bad design. The design principles are associated to Robert Martin who gathered them in "Agile Software Development: Principles, Patterns, and Practices". According to Robert Martin there are 3 important characteristics of a bad design that should be avoided:
Rigidity - It is hard to change because every change affects too many other parts of the system.
Fragility - When you make a change, unexpected parts of the system break.
Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application.
*******************************************************
Open Close Principle
Software entities like classes, modules and functions should be open for extension but closed for modifications.
OPC is a generic principle. You can consider it when writing your classes to make sure that when you need to extend their behavior you don�t have to change the class but to extend it. The same principle can be applied for modules, packages, libraries. If you have a library containing a set of classes there are many reasons for which you�ll prefer to extend it without changing the code that was already written (backward compatibility, regression testing, �). This is why we have to make sure our modules follow Open Closed Principle.
When referring to the classes Open Close Principle can be ensured by use of Abstract Classes and concrete classes for implementing their behavior. This will enforce having Concrete Classes extending Abstract Classes instead of changing them. Some particular cases of this are Template Pattern and Strategy Pattern.
Dependency Inversion Principle
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
Dependency Inversion Principle states that we should decouple high level modules from low level modules, introducing an abstraction layer between the high level classes and low level classes. Further more it inverts the dependency: instead of writing our abstractions based on details, the we should write the details based on abstractions.
Dependency Inversion or Inversion of Control are better know terms referring to the way in which the dependencies are realized. In the classical way when a software module(class, framework, �) need some other module, it initializes and holds a direct reference to it. This will make the 2 modules tight coupled. In order to decouple them the first module will provide a hook(a property, parameter, �) and an external module controlling the dependencies will inject the reference to the second one.
By applying the Dependency Inversion the modules can be easily changed by other modules just changing the dependency module. Factories and Abstract Factories can be used as dependency frameworks, but there are specialized frameworks for that, known as Inversion of Control Container.
Interface Segregation Principle
Clients should not be forced to depend upon interfaces that they don't use.
This principle teaches us to take care how we write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well. For example if we create an interface called Worker and add a method lunch break, all the workers will have to implement it. What if the worker is a robot?
As a conclusion Interfaces containing methods that are not specific to it are called polluted or fat interfaces. We should avoid them.
Single Responsibility Principle
A class should have only one reason to change.
In this context a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it. When we need to make a change in a class having more responsibilities the change might affect the other functionality of the classes.
Single Responsibility Principle was introduced Tom DeMarco in his book Structured Analysis and Systems Specification, 1979. Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.
Liskov's Substitution Principle
Derived types must be completely substitutable for their base types.
This principle is just an extension of the Open Close Principle in terms of behavior meaning that we must make sure that new derived classes are extending the base classes without changing their behavior. The new derived classes should be able to replace the base classes without any change in the code.
Liskov's Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on Object Oriented Programming Systems Languages and Applications, in Data abstraction and hierarchy
Creational Patterns
Singleton
Factory
Factory Method
Abstract Factory
Builder
Prototype
Object Pool
Behavioral Patterns
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
Strategy
Template Method
Visitor
Null Object
Structural Patterns
Adapter
Bridge
Composite
Decorator
Flyweight
Proxy
发表评论
-
OO Design books -good website
2012-06-07 03:13 660I’m always on the search on goo ... -
Differences Between Scrum and Extreme Programming
2012-04-05 22:52 813http://blog.mountaingoatsoftwar ... -
Jolt Awards books
2012-04-05 22:01 12021990 Annotated C++ Reference M ... -
Refactoring
2012-04-03 11:00 0Replace Method with Method Obje ... -
State Pattern
2012-04-03 00:06 686The pattern encapsulates state ... -
java 读书
2012-03-29 23:57 848Thinking in java Java Algorith ... -
用例子说明面向对象和面向过程的区别
2012-03-22 02:28 606java是一门面向对象的 ... -
11 Most influential Books Every Programmer/Developer must read
2012-03-14 03:49 703Every programmer needs to learn ... -
5 Best Core java books you must read as a developer
2012-03-14 03:43 872If you want success in JAVA, yo ... -
top 6 Agile books & 5 Best software Architecture books you must read
2012-03-14 03:26 689Below listed books are highly r ... -
5 Best Design Pattern Books you must read as a Software Developer
2012-03-14 03:12 878By - Sachin | 6/07/2010 | Label ...
相关推荐
OO Design Principles & Metrics
oo设计的原则。 Single Responsibility Principle (SRP) Open/Closed Principle (OCP) Liskov Substitution Principle (LSP) a.k.a. Design by Contract Dependency Inversion Principle (DIP) Interface ...
Talking about OO design principles, essentials...
You want to learn the real OO design principles and why everything your boss told you about inheritance might be wrong (and what to do instead). You want to learn how those principles will help the ...
You want to learn the real OO design principles and why everything your boss told you about inheritance might be wrong (and what to do instead). You want to learn how those principles will help the ...
8 Originality is Overrated: design principles 375 9 The Software is Still for the Customer: iteration and testing 423 10 Putting It All Together: the ooa&d lifecycle 483 Appendix I: leftovers 557 ...
描述oo原则,Some Object-Oriented Design Principles介绍,为学习OODesign原则的提供资料参考
Aspect-Oriented Programming By Design Chapter 5. Tool-Based Aspect-Oriented Programming PART 4 DI Containers Chapter 1. Di Container Introduction Chapter 2. The Autofac Di Container Chapter 3. The ...
domain object modeling, responsibility-driven design, essential OO design, layered architectures, \"Gang of Four\" design patterns, GRASP, iterative methods, an agile approach to the Unified Process ...
软件设计原理 面向对象的设计 单一责任 依赖倒置原则 “高级模块不应依赖于低级模块。 两者都应依赖抽象。 抽象不应依赖细节。 细节应该取决于抽象。...” [Robert Martin,OO设计质量指标,第2版(1994)]。
This project demonstrates examples in java and basic principles of 23 design patterns of OO programming.这个项目包含了面向对象23种设计模式的一些例子和基本原理说明。updates no finish yet还未完全更新...
6 面向对象原理 (Object-oriented principles) 7 设计模式 (Design patterns) 8 怎样设计的问题:日期和时间处理 (Design how-to: date and time handling) Part 2: 测试和重构 (Testing and refactoring) 9 测试...
But many developers have not mastered its underlying concepts and principles—relying on methodology and process instead of fully exploiting the power of object thinking in software design....
Para que服务OO? 依存模型 OsprincípiosSOLID 莫斯洛斯普林西比斯合唱团 佩剑军刀:历史的固体 Conhecendo o Cotuba 练习:Gerando um电子书 练习:阿布林多·科迪戈·杜科布洛-日蚀 练习:Gerando um ebook ...
Chapter 19 - Three Design Principles Chapter 20 - Using A UML Modeling Tool Appendix A - Project Approach Strategy Checkoff List Appendix B - ASCII Table Appendix C - Answers To Self Test ...
This brief book explains the advantages of the object model, inheritance, both classical and ...What are and how to use OO principles in JavaScript How to use Constructors with JavaScript and more
" Unlike Perl, Python is a product of the fully object-oriented (OO) era, and its constructs reflect design principles that aspire beyond keystroke shortcuts of the succinct-but-often-arcane Perl....
What are and how to use OO principles in JavaScript How to use Constructors with JavaScript and more Audience This book is for both intermediate and advanced JavaScript and Web development ...
These case studies incrementally introduce key skills, essential OO principles and patterns, UML notation, and best practices. You won't just learn UML diagramsyou'll learn how to apply UML in the ...