努力与面向对象的类设计

Question

我是从科学背景出发而且我很难想象面向对象。我一直在想函数而不是对象。

例如，我有一个包含多个2D数组的数据集，我喜欢从这些数组中提取感兴趣的区域。所以我的第一个设计类似于RoIFinder类，我向其传递了对Dataset对象的引用。 RoIFinder对象发挥了它的魔力并返回了RoI。

但是这让我感觉很糟糕，因为它看起来更像是一个功能而不是一个对象。它更像是一个黑盒子。但我不知道它是如何正确完成的。

你会怎么做？

Answer 1

OO不是银弹。从不同的角度看你的工作是否正确：问题分解，效率，代码简单性，测试等等。

如果您不需要，请不要以OO方式查看代码。 OO是关于简化问题过于复杂的生活，而不是简单地以复杂的方式解决问题。

特别针对您的问题，我认为您的方法没有任何不妥。它可能没有使用一些先进的技术，那么呢？

Answer 2

对我而言，听起来就像你描述的具体情况，这可能是一个很好的OO设计。

简称OO是关于捆绑在一起的

• 状态
• 行为
• （同一性）。

每当您拥有表示系统（的一部分）状态的数据，并且您具有与该数据相关联的行为（通常操纵）时，您就拥有了对象的候选者。可选地，这些对象也可以具有标识，但这可能并不总是必要的。

如果您可能有多个不同的标准来从数据集中选择感兴趣的区域，那么您可以将它们实现为不同的*Finder类，从而实现公共基本接口。你有一个OO类层次结构！从那时起，Finders甚至可以在您的代码中用作可互换的Strategies。

另一种方法是将finder功能放在数据集中。如果您完全确定没有更多不同的标准来提取区域，那么可能可以。即便如此，您的数据集还有两个不同的职责，通常不是一个好主意。最好让每个班级对一件事负责，并且做得好。

我们不知道你应该对数组中的数据做什么 - 可能有一些可能在那里找到更多的抽象，并在这些上构建一些OO类型和对象。

但请注意，这些都只是可能性。只有在实际有用时才能实现它们（解决问题，简化代码，或者 - 最后但并非最不重要 - 帮助您获得新概念的实践经验）。

Answer 3

您所做的事情可能比向数据集类本身添加find_roi()的明显OO方法更好。为什么？因为听起来你只是基于Dataset的公共API创建了RoIFinder功能。保持数据集更简单也很好。 STL（这些日子它只是标准库的一部分）有这样的例子，排序等算法适用于多个容器，而不是每个容器都有一个排序成员函数（尽管在列表优化机会的情况下）它实现自己的版本）。 STL还有std :: string，它在很大程度上嵌入了许多本来可以考虑的功能 - 在我看来它设计得很好，优先使用方便和优雅的使用，这对于如此频繁且经常运行的无处不在的类很重要上。那么，选择适合的情况。无论如何，没有理由把RoIFinder放到一个类中，如果它同样只是一个函数，但如果你发现一些方便保存的状态（即数据成员），或者它以其他方式帮助实现，那么这是一个足够的理由坚持你的对象。

Answer 4

您的2D数组可以实现为矩阵类。一个对象 感兴趣的区域是另一类。

从矩阵中获取感兴趣的区域是一种方法。

“Iterators”进入你的矩阵就是课程。