Question

我只是尝试了解SOLID原则，但在旧的（不是SOLID）代码中实现新结构却陷入困境。

我有Room.Class

public class Room {
   private String roomCode;
   private String roomDescription;
   // getter/setter
}

现在我需要为roomDescription翻译。我开始创建interface

public interface ITranslation {    
    String findTranslation();    
}

和implementation

public class RoomDescriptionTranslation implements ITranslation {

@Override
public String findTranslation() {
    return "translated Room";
}

在现有代码中，有一个服务类可以使用Rooms和codes创建一些descriptions。这些Rooms也在视图中使用（作为jsp bean）。

新要求是在视图上包含已翻译的描述。

所以对我来说，问题是我应该在哪里实现现有Rooms的翻译逻辑。

我应该在创建Rooms的现有serivce类中实现它吗？
或者RoomDescriptionTranslation是Room内的字段吗？
或者我应该创建一个只有description被翻译的新服务类？

只需要一个指针指向正确的方向。

Answer 1

它可能是第一个或第三个选项，但不是我认为的第二个选项。我认为一个重要的问题，一般来说，设计任何类都是这样的：

对于属性 p 和类 C ， p 属性 C ？< /强>

所以，在你的情况下，问题变成：翻译房间的财产？从语义上讲，它听起来并非如此。

然后，您可以在客房服务课上提出相同的问题。答案取决于您如何定义服务类。同样，另一个有助于确定属性是否属于某个类的规则是：

描述此课程的单词或短语是什么？

这就是OOP中的类以及SOLID中的S的概念。有一次，你问这个问题，可以为你的课程描述一个单一的目的，然后你可以回去问第一个问题，某个属性是否属于这个类。

现在，如果您的服务类是“处理所有与房间相关的操作”（不是说这是正确的，但如果是这种情况），那么您可以再添加一个操作，即翻译。但是，如果不是，那么你可以创建一个新的服务，翻译。

考虑到这一切，我更倾向于使用新的翻译服务，因为它看起来像

独立的东西

可以轻松扩展（与其他选项相比），例如添加更多语言

不需要更改现有代码

同样，可能还有其他因素会影响整个事情。

Answer 2

我会创建一个模型TranslatedRoom extends Room，仅用于从SOLID中查看此L，并且在这个新模型中会考虑翻译。

当然，如果可以重构为视图等创建模型的服务。

还有一件事（也许是来自SOLID的S）如果我们只需要在这个/这些视图中显示已翻译的房间，这个想法是好的。

Answer 3

如果要翻译文本，则应使用java中已存在的国际化解决方案。

在您的解决方案中，您将产生痛苦的维护问题，并且您将返回的每个字符串都将被if包围。

在旧代码

3 个答案: