0

我正在编写一些代码，我们正在创建对象模型，但模型具有通用键。例如

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 的联系信息并获取数据。

不好的做法

  • 如果要更新特定的联系人类型，则必须循环查找正确的键。
  • 我从来没有写过这样的代码，这就是为什么即使它是完全可以接受的，这也是一种不好的做法。
  • 贫血模型，没有真正需要上课。
  • 没有定义的键，因此我们无法在不重新搜索所有联系人的情况下轻松删除或添加联系人。
  • 没有关于联系人是什么或应该是什么的定义。

任何想法将不胜感激。

编辑：当我一个人去的时候添加更多的想法

4

2 回答 2

0

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

于 2012-05-28T23:44:54.137 回答
0

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

“医生，我这样做会很痛”——“那就不要那样做”。

你需要一个松散的模型来表示它吗？然后去吧。如果不是，如果您觉得这只是一种负担，请选择更简单的解决方案。

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

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

于 2012-05-29T07:49:02.950 回答