OO Design Recommendations for J2EE Applications

 

OO Design Recommendations for J2EE Applications

j2ee应用推荐的oo设计

It's possible to design a J2EE application so badly that, even if it contains beautifully written Java code at an individual object level, it will still be deemed a failure. A J2EE application with an excellent overall design but poor implementation code will be an equally miserable failure. Unfortunately, many developers spend too much time grappling with the J2EE APIs and too little ensuring they adhere to good coding practice. All of Sun's J2EE sample applications seem to reflect this.

In my experience, it isn't pedantry to insist on adherence to good OO principles: it brings real benefits.

以我的经验来看，并不需要迂腐的遵守良好的j2ee设计原则：它真的带来了好处。

Important

OO design is more important than any particular implementation technology (such as J2EE, or even Java). Good programming practices and sound OO design underpin good J2EE applications. Bad Java code is bad J2EE code.

oo设计比其他特别的实现技术（如j2ee，或者甚至java）更重要。好的编程实践和好的oo设计支撑着好的j2ee应用。坏的java代码是坏的j2ee代码。

Some "coding standards" issues – especially those relating to OO design – are on the borderline between design and implementation: for example, the use of design patterns.

一些“代码标准”问题-特别是与oo设计相关的-介于设计和实现之间：

The following section covers some issues that I've seen cause problems in large code bases, especially issues that I haven't seen covered elsewhere. This is a huge area, so this section is by no means complete. Some issues are matters of opinion, although I'll try to convince you of my position.

下面的小节覆盖了一些在大型代码库中我曾经遇见的问题，特别是在其他地方我没有遇见的。这是一个巨大的区域，所以这个章节绝不彻底。一些问题是个人看法，尽管我将试图说服你。

Take every opportunity to learn from the good (and bad) code of others, inside and outside your organization. Useful sources in the public domain include successful open source projects and the code in the core Java libraries. License permitting, it may be possible to decompile interesting parts of commercial products. A professional programmer or architect cares more about learning and discovering the best solution than the buzz of finding their own solution to a particular problem.

抓住每个机会从其他地方的好的代码中学习，在你团体里外。有用的源代码在公众领域包含成功的开源项目和核心java包的代码。如果许可允许，你可以反编译对商业产品的感兴趣部分。比起对一个特定的问题查找他们自己的解决方案，一个高级程序员或者架构师更关心学习和发现最好的解决方案。

Achieving Loose Coupling with Interfaces

用接口降低耦合

The "first principle of reusable object-oriented design" advocated by the classic Gang of Four design patterns book is: "Program to an interface, not an implementation". Fortunately, Java makes it very easy (and natural) to follow this principle.

“第一原则可重用oo设计”被经典的4人帮设计模式书籍主张。“对接口编程，不要对具体的实现”。幸运的是，java使它简单而自然的运用这个原则。

Important

重要

Program to interfaces, not classes. This decouples interfaces from their implementations. Using loose coupling between objects promotes flexibility. To gaim maximum flexibility, declare instance variables and method parameters to be of the least specific type required.

面向接口编程，而不是类。这解耦了接口和他们的实现。在对象之间使用松耦合提升了可扩展性。为了获得最大化的可扩展性，声明实例变量和方法参数应该给最大化的类型要求。

Using interface-based architecture is particularly important in J2EE applications, because of their scale. Programming to interfaces rather than concrete classes adds a little complexity, but the rewards far outweigh the investment. There is a slight performance penalty for calling an object through an interface, but this is seldom an issue in practice.

基于接口的架构在j2ee中是特别重要的，由于他的规模。面向接口编程而不是具体的类增加了一点点的复杂度，但是好处远远大于投入。这里有一点点轻微的性能丢失通过接口引用一个对象。但是在实际中这不是一个问题。

A few of the many advantages of an interface-based approach include:

这个大量的基于接口编程的优点包括：

• The ability to change the implementing class of any application object without affecting calling code. This enables us to parameterize any part of an application without breaking other components.

• 改变任何应用对象的实现类而不需要影响调用代码的能力。这可以使得我们参数化任何部分的应用程序而不需要打破其他的组件。

• Total freedom in implementing interfaces. There's no need to commit to an inheritance hierarchy. However, it's still possible to achieve code reuse by using concrete inheritance in interface implementations.

• 完全自由的实现接口。这儿不需要指定一个继承层次。然而，它任然可能完成代码重用用具体的继承层次在接口实现中。

• The ability to provide simple test implementations and stub implementations of application interfaces as necessary, facilitating the testing of other classes and enabling multiple teams to work in parallel after they have agreed on interfaces.

• 提供简单的测试实现和应用接口存根实现的必要能力，促进其他的类的测试和是多个团队平行的工作在他们同意了接口后。

Adopting interface-based architecture is also the best way to ensure that a J2EE application is portable, yet is able to leverage vendor-specific optimizations and enhancements.

采用基于接口的架构也是最好的方式确保j2ee应用是可移植的，也可以基于特定的供应商优化和改进。

Interface-based architecture can be effectively combined with the use of reflection for configuration (see below).

基于接口的架构能有效的与反射结合。

Prefer Object Composition to Concrete Inheritance

尽量使用结合而不是继承

The second basic principle of object-oriented design emphasized in the GoF book is "Favor object composition over class inheritance". Few developers appreciate this wise advice.

在gof的书中被强调的oo设计的第2个基本原则是“支持对象组合超过类继承”。大量的开发者欣赏这个睿智的忠告。

Unlike many older languages, such as C++, Java distinguishes at a language level between concrete inheritance (the inheritance of method implementations and member variables from a superclass) and interface inheritance (the implementation of interfaces). Java allows concrete inheritance from only a single superclass, but a Java class may implement any number of interfaces (including, of course, those interfaces implemented by its ancestors in a class hierarchy). While there are rare situations in which multiple concrete inheritance (as permitted in C++) is the best design approach, Java is much better off avoiding the complexity that may arise from permitting these rare legitimate uses.

不像许多年老的语言，例如c++，java区分一个语言层次在类继承（从父类中继承方法和成员变量）和接口继承（实现接口）。java仅仅允许单继承，但是java类可以实现任意数量的接口（包含，当然，在一个类的层次上这些接口被实现）。 然而有很少的情形下有多类继承（例如在c++中允许）是最好的设计方式，java更好的避免了允许这些罕见的合法使用的复杂性。

Concrete inheritance is enthusiastically embraced by most developers new to OO, but has many disadvantages. Class hierarchies are rigid. It's impossible to change part of a class's implementation; by contrast, if that part is encapsulated in an interface (using delegation and the Strategy design pattern, which we'll discussed below), this problem can be avoided.

类继承对于大部分的刚开始接触oo的人是受欢迎的，但是也有很多缺点。类继承是死板的。他不可能改变部分代码的实现：相反的，如果这个部分被封装在一个接口中（用委托和策略设计模式，我们将在后面讨论），这个问题将被避免。

Object composition (in which new functionality is obtained by assembling or composing objects) is more flexible than concrete inheritance, and Java interfaces make delegation natural. Object composition allows the behavior of an object to be altered at run time, through delegating part of its behavior to an interface and allowing callers to set the implementation of that interface. The Strategy and State design patterns rely on this approach.

对象组合比类继承更具有扩展性，java接口早就了委托的特性。对象组合允许一个对象的行为在运行期被改变，通过委托它部分的行为给一个接口并且允许调用者去设置这个接口的实现，策略和状态设计模式依靠这个途径。

To clarify the distinction, let's consider what we want to achieve by inheritance.

为了解释这个区别，我们用继承来完成我们想要的。

Abstract inheritance enables polymorphism: the substitutability of objects with the same interface at run time. This delivers much of the value of object-oriented design.

抽象继承具有多态性：可替代的对象在运行期有相同的接口。这道出了oo设计的价值。

Concrete inheritance enables both polymorphism and more convenient implementation. Code can be inherited from a superclass. Thus concrete inheritance is an implementation, rather than purely a design, issue. Concrete inheritance is a valuable feature of any OO language; but it is easy to overuse. Common mistakes with concrete inheritance include:

类继承确保了多态和更方面的实现。代码能被继承从一个父类。类继承是一种实现方式，比起纯粹的设计问题。类继承对于任何oo语言来说都是一个有价值的特性;但是也很容易被滥用。用类继承的普遍的错误包含：

• Forcing users to extend an abstract or concrete class, when we could require implementation of a simple interface. This means that we deprive the user code of the right to its own inheritance hierarchy. If there's normally no reason that a user class would need it's own custom superclass, we can provide a convenient abstract implementation of the method for subclassing. Thus the interface approach doesn't preclude the provision of convenient superclasses.

• 强迫用户去扩展一个抽象类或具体类，当我们能要求一个简单的接口实现时。这意味着我们剥夺了用户代码的权利对它自己的类继承。如果通常没哟原因一个用户类将需要它自己的超类，我们将提供一个方便的抽象实现方法为子类。因此接口途径并没有预先包含便利的父类的规范。

• Using concrete inheritance to provide helper functionality, by subclasses calling helper methods in superclasses. What if classes outside the inheritance hierarchy need the helper functionality? Use object composition, so that the helper is a separate object and can be shared.

• 用类继承去提高帮助功能，用子类调用在父类中的帮助方法。如果这个类在这个继承体系的外部需要这个帮助功能呢？用对象组合，以至于这个帮助类是一个分离的对象能被分享。

• Using abstract classes in place of interfaces. Abstract classes are very useful when used correctly. The Template Method design pattern (discussed below) is usually implemented with an abstract class. However, an abstract class is not an alternative to an interface. It is usually a convenient step in the implementation of an interface. Don't use an abstract class to define a type. This is a recipe for running into problems with Java's lack of multiple concrete inheritance. Unfortunately, the core Java libraries are poor examples in this respect, often using abstract classes where interfaces would be preferable.

• 用抽象类代替接口。抽象类是非常有用的当我们考虑正确。这个模板方法设计模式（在下面讨论）通常用一个抽象类实现。然而，，一个抽象类不是唯一的选择去替换接口。它通常是一个便利的步骤在接口的实现中。不要用一个抽象类去定义一个类型。这是因为java缺乏多继承。不幸的是，java核心包在这方面的例子太少了，经常用抽象类在接口可能是更好的地方。

Interfaces are most valuable when kept simple. The more complex an interface is, the less valuable is modeling it as an interface, as developers will be forced to extend an abstract or concrete implementation to avoid writing excessive amounts of code. This is a case where correct interface granularity is vital; interface hierarchies may be separate from class hierarchies, so that a particular class need only implement the exact interface it needs.

接口保持简单是最有价值的。这个接口越复杂，这个接口的构造价值将越小。开发者将被迫去继承一个抽象或者具体的实现去避免大数量的代码。正确的接口粒度也是重要的；接口继承可能从类继承中分离，以至于一个特定的类仅仅实现它需要的类。

Important

重要

Interface inheritance (that is, the implementation of interfaces, rather than inheritance of functionality from concrete classes) is much more flexible than concrete inheritance.

接口继承（实现接口，而不是从类中继承具体的功能）更有可扩展性比类继承。

Does this mean that concrete inheritance is a bad thing? Absolutely not; concrete inheritance is a powerful way of achieving code reuse in OO languages. However, it's best considered an implementation approach, rather than a high-level design approach. It's something we should choose to use, rather than be forced to use by an application's overall design.

这意味者类继承是一个坏事情？完全不是；类继承是一个又力量的方式去完成代码重用在oo语言中。然而，它最好被认作一个实现途径，而不是一个高级设计方式。它是我们可以选择去用的，而不是被迫去用通过一个应用的过度设计。

转载于:https://www.cnblogs.com/sqtds/archive/2012/11/22/2783647.html