初始化抽象类的成员而没有子类具有写访问权

问题描述

限时删除！！

我有一个抽象类：

public abstract class AbstractCommand {

    private static State state;
}

意图

• 状态类 State 的对象由某些控制类提供，提供每个 AbstractCommand所需的数据子类


• 每个子类都需要对其进行读取访问


• 不允许子类更改字段



Intention

• An object of class State is provided by some "controlling classes", providing data that is needed by each AbstractCommand subclass
• Each subclass needs read access to it
• The subclasses are not allowd to change the field

字段状态应该由程序的控制类初始化，以便子类（定义命令）可以使用它（只读）。子类在内部定义，应该用作用户的接口。此用户不应具有对状态的写权限。

The field state should be initialized by the "controlling classes" of the program so that subclasses (that define commands) can use it (read-only). The subclasses are defined internally and should be used as an interface for the user. This user should not have write access to state.



• 在 AbstractCommand 中添加公共 setState（）方法将使其生效所有子类以及用户都可以访问的


• 对字段进行最终处理将迫使对象的创建在抽象类中进行，而控制类将不得不使用该类对象，而且它是不可替代的


• Adding a public setState() method in AbstractCommand would make it accessible to all subclasses and with that to the user
• Making the field final would force the creating of the object to take place in the abstract class and the "controlling classes" would have to use this object, furthermore it would not be replacable

您如何处理这样的事情？

How do you handle something like this?

由于某些答案建议使用软件包可见性的解决方案，我想知道这样做是否做得很好：

Because some answers suggested solutions using package visibility I wonder if this would do a good job:

在同一包中有一个类，该类通过委派从控制类（从包外部）到抽象类的调用来提供所需的信息。

Have a class in the same package that provides the required information by delegating a call from the "controlling classes" (from outside the package) to the abstract class.

听起来也有些模糊，但是您怎么看？

Sounds a little fuzzy, too but what do you think?

推荐答案

我只能提供模糊解决方案。

I can only offer fuzzy solutions.

一些解决方案优先：

Some solutions first:

都可以

private static final State state = Controller.initState();

或使用控制权反转，依赖项注入， @注入。那也将允许单元测试。 Web上肯定有开源的DI容器（春季，还是Pico容器还在附近？）。

Or use inversion of controll, dependency injection, @Inject. That would allow unit tests too. There certainly are open source DI containers out there in the web (Spring, or is Pico container still around?). Or requesting beans from some DI container.

如果两者都为时过早，请进行惰性评估（部分静态初始化已经是惰性的）。有时会看到一个内部类：

If both are too early, go for lazy evaluation (partly the initialisation of statics is already lazy). Sometimes one will see an inner class:

private static class Singleton {
    private static final State state = Controller.initState();
}

可能带有getInstance。

Possibly with a getInstance.

我的选择：

My choice:

某种程度上没有静力学，但吸气剂却是单例的。一个带有控制器的bean框架。

Somehow no statics, but getters to singletons. A bean frame work with controllers.

Singletons而不是static。

Singletons instead of statics.

静态（静态函数）在之前的eclipse 3富客户端中大量使用，例如

Statics (static functions) where abundantly used in the prior eclipse 3 rich client, like

IPreferenceStore store = IDEWorkbenchPlugin.getDefault().getPreferenceStore();
boolean autoPrint = store.getBoolean(AUTO_PRINT);

现在可以通过OSGi容器和注释进行依赖注入：

Now alternatively with dependency injection by the OSGi container and annotations:

@Inject @Preference(AUTO_PRINT)
boolean autoPrint;

来自：Eclipse 4，M. Teufel和J. Helming的Rich Clients

除了更短之外，类之间的耦合更少，并且单元测试可以更容易地编写，因为我们可以像我们喜欢的那样填充autoPrint，并且不需要

Besides being shorter, there is less coupling between classes, and unit tests can more easily be written, as we can fill in autoPrint like we like, and do not need to meddle with the filling class.

如果有人犹豫加了这样一个容器的开销，最简单的方法是为多个静态变量提供替代方案，使应用程序上下文，您可以在其中查找Java对象POJO bean。也许有一个XML文件支持：

If one hesitates adding the overhead of such a container, the easiest way is to have alternatives to several statics is having one global application context, where you can lookup java objects, POJO beans. Maybe backed by an XML file:

State state = ApplicationContext.lookup(State.class, "state");

<bean name="state" class="org.anic.State" value="sleepy" depends="firstThis"/>
<bean name="firstThis .../>

注意，则不再需要具有 static 状态。

Mind, there no longer is a need to have a static state.

Spring框架具有这种XML方法。

The Spring framework has such an XML approach.

优点是集中式初始化，可以考虑序列和不同的工厂/创建方法。

The advantage being a centralized initialisation, where sequence and different factory / creation methods are thinkable.

（抱歉，您的回答很混乱。）

这篇关于初始化抽象类的成员而没有子类具有写访问权的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

1403页，肝出来的..