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#通过允许将类实现分解为多个源文件来解决这个问题:你可以按照你选择的任何方式划分god对象，它会起作用.

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.

这样做几轮后，您可以通过将其他对象直接指向更新的、较小的对象，而不是通过位于一切中间的先前巨大的对象来开始移除一些委托.

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.

参见维基百科的委托模式讨论示例.

举一个简单的例子，如果你有一个人事对象来代表公司的员工，那么你可以创建一个工资对象来跟踪与工资相关的值，一个评级对象来跟踪员工评级，一个奖励对象跟踪此人获得的奖项等.

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 StaffInformation staffInformation;
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屋！