在Java中大班分解 [英] Big class decomposition in Java

问题描述

我刚开始学习Java，是好奇的是它在Java中有什么好的做法好对象分解？让我描述一个问题。在大的软件项目中它总是一个很大的类，如核心，或往往有很多方法的，意在更小的类之间的调解人UI。例如，如果用户点击了一些窗口中的按钮，这个窗口的类将消息发送到UI类。这种UI类捕获该消息，并（通过调用它的成员对象之一法）做与应用程序用户界面的东西，或通过发布消息到应用核心如果是像退出应用程序或启动网络采取相应的行动连接。

I have just started to learn Java and is curious is it any good practice in Java for good object decomposition? Let me describe a problem. In big software project it's always a big classes like 'core' or 'ui' that tends to have a lot of methods and are intended as a mediators between smaller classes. For example, if user clicks a button on some window, this window's class sends a message to 'ui' class. This 'ui' class catches this message and acts accordingly by doing something with application user interface ( via calling method of one of it's member objects ) or by posting message to application 'core' if it's something like 'exit application' or 'start network connection'.

这样的对象是非常难以掰开，因为它们是一个许多小应用对象之间的光介质。但有在应用程序中的类与方法成千上万也不是很方便，如果事件这样的方法是微不足道的任务委派从一个对象到另一个。 C＃允许打破类实现成多个源文件解决了这样的问题：你可以把上帝对象，你选择的任何方式，它会工作

Such objects is very hard to break apart since they are a mere mediators between a lots of small application objects. But having a classes in application with hundreds and thousands of methods is not very handy, event if such methods are trivial task delegation from one object to another. C# solves such problem by allowing to break class implementation into multiple source files: you can divide god object any way you choose, and it will work.

在Java的划分这些对象的任何做法？

Any practices by dividing such objects in Java?

推荐答案

开始打破这么大的天体与众不同的是，首先找到那些相互关联的大对象管理的字段或属性的一个很好的子集的一种方法和不与其他字段或对象的属性进行交互。然后，创建只使用领域一个新的，更小的物体。也就是说，移动的所有的从大班到新的小班逻辑。在原来的大班，创建只是简单地传递沿请求委派方法。这是只涉及改变大目标的第一步。它不降低的方法的数量，但是它可以大大减少在大类所需要的逻辑的数量。

One way to begin breaking such a large object apart is to first find a good subset of fields or properties managed by the large object that are related to each other and that don't interact with other fields or properties of the object. Then, create a new, smaller object using only those fields. That is, move all logic from the large class to the new smaller class. In the original large class, create a delegation method that simply passes the request along. This is a good first step that only involves changing the big object. It doesn't reduce the number of methods, but it can greatly reduce the amount of logic needed in the large class.

在几轮这样做，你就可以开始通过直接在较新的，更小的物体指向其他对象，而不是通过previously，巨大的对象，那是在中间要除去一些代表团一切。

After a few rounds of doing this, you can begin to remove some of the delegation by pointing other objects directly at the newer, smaller objects, rather than going through the previously-huge object that was in the middle of everything.

请参阅维基百科的委托模式例如讨论。

作为一个简单的例子，如果你有一个人员对象在公司重新present人员，那么你可以创建一个工资的对象跟踪有关工资的价值，收视对象跟踪员工评级，颁奖对象，以保持奖项跟踪该人赢了，等等。

As a simple example, if you have a personnel object to represent staff at a company, then you could create a payroll object to keep track of payroll-related values, a ratings object to keep track of employee ratings, an awards object to keep track of awards that the person has won, and so on.

要机智，如果你开始了一个大的类包含以下方法，每个包含业务逻辑的，许多其他的方法之一：

To wit, if you started out with one big class containing the following methods, each containing business logic, among many other methods:

...
public boolean isManagement() { ... }
public boolean isExecutive() { ... }
public int getYearsOfService() { ... }
public Date getHireDate() { ... }
public int getDepartment() { ... }
public BigDecimal getBasePay() { ... }
public BigDecimal getStockShares() { ... }
public boolean hasStockSharePlan() { ... }
...

那么这个大的对象可以在其构造函数中，创建一个新创建的对象 StaffType 及新创建的对象 PayInformation 及新创建的对象 StaffInformation ，初步这些方法中的大物体看起来像：

then this big object could, in its constructor, create a newly created object StaffType and a newly created object PayInformation and a newly created object StaffInformation, and initially these methods in the big object would look like:

// Newly added variables, initialized in the constructor (or as appropriate)
private final StaffType      staffType;
private final PayInformation payInformation;
private final PayInformation payInformation;

...

public boolean isManagement() { return staffType.isManagement(); }
public boolean isExecutive() { return staffType.isExecutive(); }
public int getYearsOfService() { return staffInformation.getYearsOfService(); }
public Date getHireDate() { return staffInformation.getHireDate(); }
public int getDepartment() { return staffInformation.getDepartment(); }
public BigDecimal getBasePay() { return payInformation.getBasePay(); }
public BigDecimal getStockShares() { return payInformation.getStockShares(); }
public boolean hasStockSharePlan() { return payInformation.hasStockSharePlan(); }
...

，其中曾经是在大对象的全部逻辑已经移动到这三个新较小的物体。随着这一变化，你可以把这个大目标分成较小的部分，而无需接触任何东西，它利用了大的对象。然而，当你做到这一点随着时间的推移，你会发现，大对象的某些客户可能只需要可分组成部分之一的访问。对于这些客户，而不是他们使用大对象，并委托给特定的对象，就可以直接使用小的对象。但即使永远不会发生这个重构，你已经被无关的项目的业务逻辑分离成不同类别提高的东西。

where the full logic that used to be in the big object has been moved to these three new smaller objects. With this change, you can break the big object into smaller parts without having to touch anything that makes use of the big object. However, as you do this over time, you'll find that some clients of the big object may only need access to one of the divisible components. For these clients, instead of them using the big object and delegating to the specific object, they can make direct use of the small object. But even if this refactoring never occurs, you've improved things by separating the business logic of unrelated items into different classes.

这篇关于在Java中大班分解的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！