问题标签 [class-design]

我有两张桌子。

订单 - 包含列 OrderID、OrderStatusID
OrderStatus - 包含列 OrderStatusID、说明

我有一个 Order 对象，它调用数据库并填充其属性以在我的代码中使用。现在我可以访问 Order.OrderStatusID，但在我的应用程序中，我确实需要访问“描述”字段。

您如何通过良好的 OO 设计优雅地处理这个问题？

我目前正在编写一个财务应用程序，我们有一个非常标准的客户表。它由许多必填字段和一些可选字段组成，例如 Cell/Fax 等。我使用 NHibernate 作为 ORM 并且所有映射都正确。它已经起作用了。

我只是想知道，我如何在代码中“表达”一个字段不为空而不注释？我有记录这个的 hbm.xml 文件，但是对于这样的事情来看它们有点尴尬。

想到的另一件事是我不希望存储库在我的逻辑上抛出 NHibernate 异常，所以也许我应该在控制器中进行验证。不过，我怎样才能让 POCO 代码表达某些字段可以为空？

如您所见，我希望蜂窝和传真是可选的，而电话是必需的。它们都只是复合映射，所以映射文件只是指定每个元素的单个元素必须不为空，但我讨厌一直执行 Person.Cellular != null 检查以避免出现 NullReferenceException。

和有什么区别

• 一个简单的fields-accessors-mutators类
• 丰富的模型类

什么构成业务领域类中的丰富建模？

我正在编写一个 HTML 表单生成库。有一个顶级的 Form 类，在底部有针对每种类型的 HTML 表单输入对象（Select、Textfield、Radio 等）的类。中间有一个类，它包含 1 个或多个语义相关的输入对象的分组。

例如，此类的一种类型可以称为“登录”，并且将包含文本字段输入和密码输入。再举一个例子，表单库的主要用途是生成在线调查，因此中间类将是各种调查问题。

我的问题是一般如何称呼这些中级类。我们工作组中提出的一些建议是“Set”、“Fieldset”、“Group”、“Block”、“Chunk”和“Conglomeration”。

这些建议中有几个是“好的”，但没有一个是“就是这样！” 打断。（最接近的是后者，但那（a）太长了，（b）太容易拼写错误。）有人有更好的建议吗？

他们是一种使用与成员函数相同的“点”表示法在对象上使用非成员非朋友函数的方法吗？

我可以将（任何）成员从课程中拉出来，并让用户以他们一贯的方式使用它吗？

更长的解释：

Scott Meyers、Herb Sutter 等人认为，非成员非友元函数是对象接口的一部分，并且可以改进封装。我同意他们的观点。

然而，在最近阅读了这篇文章之后：http ://www.gotw.ca/gotw/084.htm我发现自己质疑语法含义。

在那篇文章中，Herb 建议拥有一个insert、erase和replace成员，以及几个同名的非成员非朋友函数。

这是否意味着，正如我所认为的那样，Herb 认为某些函数应该与点符号一起使用，而其他函数应该作为全局函数使用？

编辑：

感谢大家提供非常有用的答案，但是，我认为我的问题的重点被忽略了。

我特别没有提到运算符的具体情况，以及它们如何保留“自然”符号。您也不应该将所有内容包装在名称空间中。这些东西写在我链接的文章中。

问题本身是：

在文章中，Herb 建议一个 insert() 方法是成员，而其余的是非成员非友元函数。

这意味着要使用一种形式的 insert()，您必须使用点符号，而对于其他形式，您不需要。

只是我，还是听起来很疯狂？

我有一种预感，也许您可​​以使用单一语法。（我在想 Boost::function 如何将 *this 参数用于 mem_fun）。

以下是对我来说似乎含糊不清的几点：
“High-Fan in”：有大量使用给定类的类；在较低级别很好地使用实用程序类。
“低扇出”：不要在给定类中使用太多其他类。
这是否意味着您甚至不能让一个给定的类使用几个小的实用程序类？

假设我有一个类“应用程序”。为了被初始化，它需要在构造函数中进行某些设置。让我们还假设设置的数量如此之多，以至于将它们放在自己的类中是令人信服的。

比较此方案的以下两种实现。

实施1：

实施2：

对我来说，第二种方法非常可取。它更具可读性，因为它强烈强调了两个类之间的关系。当我编写代码以在任何地方实例化 Application 类时，第二种方法看起来会更漂亮。

现在想象一下，Settings 类本身又具有一些类似的“相关”类，而该类也同样如此。只进行三个这样的级别，并且在“非嵌套”情况下类命名会失控。然而，如果你嵌套，事情仍然保持优雅。

尽管如此，我还是读到有人在 StackOverflow 上说嵌套类只有在它们对外界不可见时才是合理的；也就是说，如果它们仅用于包含类的内部实现。普遍引用的反对意见是膨胀包含类的源文件的大小，但部分类是该问题的完美解决方案。

我的问题是，为什么我们要警惕嵌套类的“公开”使用？还有其他反对这种使用的论据吗？

我在 Visual Studio 2005 中使用 C++ 扩展模板类。当我尝试使用以下方法扩展模板基类时，它给了我一个错误：

当我尝试实例化对象时出现第二个错误：

错误一：

**redblacktreeopengl.hpp(27) : error C2039: '{ctor}' : is not a member of 'RedBlackTree' with [ K=double, D=std::string ] **

错误2：

main.cpp(50) : 请参阅正在编译的类模板实例化“RedBlackTreeOGL”的参考

在 C++ 编程时，我们曾经在需要时创建复制构造函数（或者我们被教导过）。几年前切换到 Java 时，我注意到现在正在使用 Cloneable 接口。C# 遵循定义 ICloneable 接口的相同路线。在我看来，克隆是 OOP 定义的一部分。但我想知道，为什么要创建这些接口，而复制构造函数似乎已被删除？

当我想到它时，我想到如果需要复制类型未知的对象（如引用基类型），复制构造函数将没有用。这似乎合乎逻辑。但我想知道是否还有其他我不知道的原因，Cloneable 接口比复制构造函数更受青睐？

我有一种情况，我必须使用多个视图（如个人信息 -> 专业信息 -> 流程完成）从用户那里获取输入。

我想知道，如何构建一个像 UIImagePickerController 这样的类，它接受用户的输入并将数据返回给父类？请注意，视图也由此类处理。