在旧代码中使用SOLID原则实现新功能

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"; 
} 

在现有的代码中有与codes和descriptions产生了一些Rooms服务类。这些Rooms也被用在视图中（作为jsp bean）。

新的要求是在视图上有翻译的描述。

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

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

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

Answer 1

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

对于财产p和类Ç，是p的Ç的属性？

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

然后，你可以问客房服务类相同的问题。答案取决于你如何定义你的服务类。再一次，有助于确定属性是否属于某个类别的另一个规则是：

什么是描述此类的单个单词或短语？

这就是关于OOP中的类以及SOLID中的S的概念。有一次，你问这个问题，可以为你的班级描述一个单一目的，那么你可以回过头去问第一个问题，即某个属性是否属于这个班级。

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

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

1. 东西独立
2. 反而容易伸长（相比其他选项）比如增加更多的语言
3. 不要求改变现有的代码

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

Answer 2

我会创建一个模型TranslatedRoom extends Room仅用于查看来自SOLID的这个L，并且在这个新模型的内部会关注翻译。

当然，如果有可能重构服务，创建视图等模型

还有一件事（也许是由固体S）这个想法是好的，如果我们只需要在这个展示翻译室/这些观点。

Answer 3

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

在您的解决方案中，您将创建令人痛苦的维护问题，您将返回的每个字符串将被if包围。