这是一种反模式吗？如果是这样，为什如果不是为什么不呢？

我正在处理一些代码，我们正在创建对象模型，但模型具有通用键。例如这是一种反模式吗？如果是这样，为什如果不是为什么不呢？

class myContact { 
var key; 
var value; 
}

然后在代码实例它们如下

myContact = new myContact() 
myContact.key = 'address' 
myContact.value = '123 my address' 

myContact2 = new myContact() 
myContact2.key = 'secondAddress' 
myContact2.value = '123 my other address'

，然后将它们连接到一个父对象像

myBank = new company(); 
myBank.addContact(myContact); 
myBank.addContact(myContact2);

以我为模型是这样的感觉错如此松散地定义。但是，您从课程名称中知道这将是某种联系信息。

与此同时，我可以看到为什么这可能是有用的，就好像我们想在未来添加一种不同类型的联系人一样，这种方法使得这很容易实现。

任何人都可以向我解释，如果这是好的做法？不好的做法和原因？

我最初的想法：

良好做法

容易在未来扩展接触的类型。
易于通过myBank的联系信息循环并获取数据。

坏实践

如果您想更新您通过具有循环特定联系人类型找到正确的钥匙。
我从来没有写过这样的代码，这就是为什么它觉得不好的做法即使它是完全可以接受的。
贫血模型，没有真正的需要成为一个类。
没有定义的密钥，因此我们无法轻松删除或添加联系人，而无需再次搜索全部联系人。
没有定义联系人是或应该是什么。

任何想法将不胜感激。

编辑：添加一些想法，因为我一个人

来源

2012-05-28 Alan Hollis

我正在慢慢回答我自己的问题，同时使用这种类型的模型.... –

走在我看来，没有什么不好用“自定义字段”。它在所有允许用户定义自己的字段的系统（例如jira，电话簿等）中相当受欢迎。通常有一些基本的，预定义的字段/键，例如姓名，ID，电子邮件等，这些字母/键用于例如用于搜索或认证。在这个代码中我唯一不喜欢的是贫血模型。如果你创建一个类myClass（改变这个名字！），然后公开访问它的所有字段，那么为什么你需要一个类？类是关于封装。

来源

2012-05-28 23:44:54 piotrek

关于封装和搜索的好处。我认为这就是上面的代码对我来说正在下降的地方。我已经做了一些研究，我相信这将属于http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model？你会同意吗？ –

可能。但是当您只能看到一个类和两个示例时，很难谈论实体属性值模型。当然，最好是用银行对象来收集'Contact'，而不是用Map'String，String'的银行，所以我不是说你应该删除这个类，但是要知道它是什么。如果它仅为传输值服务器，则使用结构而不是类（公共字段，不允许使用人工获取器和设置器等）。如果不知道项目未来的计划，很难提供更好的建议 – piotrek

对我来说，这感觉不对，因为模型是如此松散定义。

“医生，当我这样做的时候会感到痛苦” - “那么不要那么做”。

你需要一个宽松的模型来表示它吗？然后去做。如果没有，如果你觉得它只是一个负担，选择一个更简单的解决方案。

显然，目前没有这方面的需求。未来会出现这种需求的可能性有多大？这样的重构将如何影响您的代码库？你甚至可以对此做出假设吗？

在这种情况下，在这种情况下应用YAGNI原则可能是有意义的。

来源

2012-05-29 07:49:02

这是一种反模式吗？如果是这样，为什如果不是为什么不呢？

回答

相关问题