问题标签 [package-design]

我在设计数据库方面工作了很长时间，而这些天我也在 C# 中工作。OO 对我来说很有意义，但我觉得我对 OO 设计的深层理论没有很好的基础。

在数据库领域，有很多关于如何设计数据库结构的理论，主要概念是规范化。规范化直接控制数据库的结构，并在一定程度上决定了如何在数据库中排列实体。

如何设计面向对象程序的结构背后是否有类似的概念？

我所追求的是一个或多个基本理论原则，它们自然地引导开发人员为解决给定问题进行“正确”设计。

我在哪里可以找到更多信息？
有没有我应该阅读的工作？

更新：

感谢大家的回答。我正在阅读的内容似乎是说没有“面向对象设计的大理论”，但是有许多重要的原则——这些原则在很大程度上以设计模式为例。

再次感谢您的回答:)

最近听说OOP(Java)有9条规则。我只知道抽象、多态、继承和封装四个。OOP 还有更多规则吗？

我很想知道人们如何组织他们的代码库，尤其是在可重用组件方面。我在下面用 OO 术语谈论，但我对您如何为其他类型的语言组织库也很感兴趣。

例如：

• 您是所有类库项目的忠实拥护者，还是更喜欢将所有内容保存在一个项目中？
• 您是否重用了预构建的 DLL，或者您是否在当前工作中包含了以前项目中的各个类？如果是单独的课程，您是否在项目之间共享它们以确保所有课程都保持最新，或者您是否允许分支？
• 您的可重用元素有多大？他们的专注度如何？他们是如何集中注意力的？
• 您通过首选实践实现了何种程度的重用？

等等

编辑

我不是在这里寻找具体的指导，我只是对人们的思想和实践感兴趣。我对在不同项目之间重用代码特别感兴趣，而不是在单个项目中重用。（不幸的是，这里使用“项目”具有误导性——我的意思是在为客户开展的实际项目之间重用，而不是 Visual Studio 意义上的项目。）

阅读Amazon和ACCU的评论表明，John Lakos 的书，大型 C++ 软件设计可能是模块化的罗塞塔石碑。

与此同时，这本书似乎真的很稀有：没有多少人读过它，也没有盗版电子版在四处飘荡。

所以你怎么看？

我有2个项目。

Project#2 引用了 Project#1

现在我需要在 Project#1 中引用 Project#2，但是 vs.net 抱怨循环依赖。

有没有办法解决这个问题？

众所周知，几乎每个复杂的架构都包含多个层。在一个管理系统中，我们可以很容易地想出数据访问层、业务逻辑层和表示层，而不用想太多。我想知道如何创建多个图层是否有明确的原则。PS：不限于管理系统。

最近我遇到了这个 javalobby 帖子http://java.dzone.com/articles/how-chang-java-package按功能打包 java 代码。

我喜欢这个主意，但我对这种方法几乎没有疑问。我问了我的问题，但没有得到满意的答复。我希望 StackOverflow 上的人可以澄清我的问题。

我喜欢按功能打包的想法，它大大减少了在编码时跨包移动的时间，所有相关的东西都将放在一个地方（包）。但是不同包中的服务之间的交互呢？

假设我们正在构建一个博客应用程序，并且我们将所有与用户相关的操作（控制器/服务/存储库）放在com.mycompany.myblog.users包中。以及包中所有与博客文章相关的操作（控制器/服务/存储库）com.mycompany.myblog.posts。

现在我想显示用户个人资料以及他发布的所有帖子。我应该打电话myblog.posts.PostsService.getPostsByUser(userId)吗myblog.users.UserController.showUserProfile()？

包之间的耦合呢？

同样，无论我在哪里阅读按功能打包的信息，每个人都说这是一个很好的做法。那么为什么很多书籍作者甚至框架都鼓励分层分组呢？只是想知道:-)

我有以下 dll 的应用程序：

Web 项目 - MVC Web 应用程序

Wcf 服务 - Web 应用程序使用的服务。

模型 - 实体框架代码首先实体和 DbContext 对象。

现在，当我需要更改某些内容时，可以说 wcf 服务中的功能，因此我更改了功能，但 Web 也受到了影响，我需要再次添加服务引用并更改使用 wcf 服务的代码以及模型有时会更改.. .

正如 CCP 所说： 改变包装的理由不应该超过一个。如果更改发生在依赖于多个包的应用程序中，理想情况下，我们只希望更改发生在一个包中，而不是多个包中。这有助于我们确定可能更改的类，并将它们打包在一起，原因相同。如果这些类是紧密耦合的，请将它们放在同一个包中。

所以在我的设计中我违反了这个原则？如果有人能解释更好的设计，我会很高兴。

Bob 大叔的 OOD 原则 ( http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod ) 描述：

• 班级设计的五项原则
• 包设计的六大原则（Release Reuse Equivalency Principle、The Common Closure Principle等）

文章指出：

在这种情况下，包是像 .jar 文件或 dll 一样的二进制交付物，而不是像 Java 包或 C++ 名称空间这样的名称空间。

这是否意味着这 6 条“包原则”根本不适用于 Java 包（使用关键字package定义）？这是否意味着以这种方式应用它们是错误的？如果是这样，您能否指出在哪里可以找到这样的命名空间包原则？

在阅读了关于稳定抽象原则 (SAP) 的这个wiki 之后，我想知道是否有人知道依赖抽象而不是具体的任何缺点（我想，这超过了优点）。

SAP 声明包越稳定，它应该越抽象。这意味着如果一个包不太稳定（更可能改变），那么它应该更具体。我真的不明白为什么会这样。当然，在所有情况下，无论稳定性如何，我们都应该依赖抽象并隐藏具体实现？