班级互动设计模式

发布于 2024-09-27 10:38:10 字数 614 浏览 5 评论 0原文

我在决定两个类应该如何交互时遇到了一些麻烦，而且我遇到的问题似乎会经常出现，所以我想知道是否有人知道解决我的问题的设计模式（或任何类型的解决方案）。

基本上我有两节课。 A 类负责向用户显示信息，B 类负责存储数据。 A类需要从B类获取数据，根据A类的内部状态格式化数据，并输出数据。例如，B 类包含英语字符串，而 A 类在对它们进行任何进一步处理之前，始终会将这些字符串翻译成 A 类实例变量指定的语言。

我可以为此提出两种可能的解决方案，但它们看起来都不是很干净。

将 B 类作为 A 类的实例变量。在 A 类中编写函数，从 B 类中获取数据并将其格式化以供 A 类中的其他函数使用。这个解决方案看起来不太好，因为它不能阻止 A 类直接访问 B 类中的数据而不对其进行格式化。
创建一个扩展类 B 的类 C。使类 C 成为类 A 的实例变量。类 C 将覆盖类 B 的 Getter，以便格式始终应用于数据。然而，为了格式化数据，C 类需要了解 A 类的内部状态。这可以通过将指向类 A 的指针传递到类 C 的构造函数中来完成。然后，类 C 可以调用类 A 中的函数来计算类 A 的内部状态。

如果这令人困惑，请告诉我，我可以提供一个更具体的例子。

谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

我要还你自由 2024-10-04 10:38:10

在替代方案#1中，我不认为“阻止A类直接访问B类中的数据而不对其进行格式化”是一个问题。任何类都可能无法完成它所说的事情，这并不需要一个糟糕的设计就能做到这一点。所以我认为这不是一个合理的担忧。 A 是唯一知道其内部状态的东西，因此它应该提供转换输出的逻辑。

一种替代方案是使用策略模式之类的东西，这可能会根据您的需求进行过度设计。基本上，B 接受格式化数据的策略，并且在该函数（A 将提供的）中，您可以依赖 A 的状态。

像这样：

interface FormattingStrategy {
    public String format(String input);
}

class B {
    public String getFormattedStringA(FormattingStrategy formatter)...
}

class A {

    public void someMethod() {
         String a = getFormattedStringA(new FormattingStrategy() {
             public String format(String input) {
                 if (someAState) {
                    //...
                 }
             }
         };
    }
}

该策略可以是 A 的实例变量。这使 B 与 A 完全解耦，仅与 FormattingStrategy 接口耦合。

In alternative #1, I don't think "stopping Class A from directly accessing the data in Class B without formatting it" is a concern. Any class can fail to do what it says it does, it doesn't take a bad design to do that. So I don't think that's a valid concern. A is the only thing that knows its internal state, so it should be providing the logic to transform the output.

One alternative to that, which may be overengineered for your needs, is to use something like the Strategy pattern. Basically, B accepts a strategy to format data, and in that function (that A would provide) you could rely on A's state.

Something like this:

interface FormattingStrategy {
    public String format(String input);
}

class B {
    public String getFormattedStringA(FormattingStrategy formatter)...
}

class A {

    public void someMethod() {
         String a = getFormattedStringA(new FormattingStrategy() {
             public String format(String input) {
                 if (someAState) {
                    //...
                 }
             }
         };
    }
}

The strategy could be an instance variable of A. This keeps B completely decoupled from A, only coupled to the FormattingStrategy interface.

回复收藏 0 原文

弄潮 2024-10-04 10:38:10

听起来像：

回复收藏 0 原文

我ぃ本無心為│何有愛 2024-10-04 10:38:10

你犯的一个错误是类 A、B、C 的命名，你不应该这样做。更好的方法是像更真实的对象一样命名你的类，例如职业或真实的事物，因为你可以从名称中得到解决方案。如果你提到模式...
它们的名称如下：Model-View、Fabrique、Decorator、Observer。挖它吗？
解决你的问题：包含数据的类是你的“模型”，显示数据的类是你的“视图”
如果您处理语言，也许可以看看解释器模式。但我必须承认我并不真正理解这个问题，这对我来说听起来有点困惑

回复收藏 0 原文

~没有更多了~