在开始开发大型应用程序（WinForm和WebApp）之前，我如何从类设计入手。在设计类结构之前，我应该检查哪些最初的'小心'的东西？
如何在我的应用程序设计中识别接口，抽象类，委托，事件等的用法？
答案 0 :(得分：9)
对这个问题的彻底回答需要一本书，而不是StackOverflow帖子！事实上，已经有很多关于这方面的书籍，比如Martin Fowler的 Patterns of Enterprise Application Architecture 。以下是一些一般性指示：
确保您了解您正在处理的问题域的部分。您是否先与客户交谈过他们的事情？您的域模型是否与他们对世界的看法相符？
从统计上讲，您的申请不太可能是特殊的。这意味着如果有人坚持认为他们需要特定的体系结构或实现模式来实现工作（例如企业服务总线，消息队列等），那么您应该持怀疑态度来看待它。考虑另一种方法是否可能更好。
在结构上和逻辑上彼此隔离应用程序的不相关部分。不要只是松散地耦合或分离你的课程;使它们完全独立，必须单独构建。
代码接口，而非实现。如果许多类都做类似的事情，请创建一个接口。不要将抽象基类用作伪接口。依赖于接口并传递它而不是单独的实现类。
了解更大范围的应用程序。它有什么商业目的？它将如何帮助人们，实现目标或提高生产力？你正在建造的东西是否符合这个目的？确保你不是为了建造而建造的。
当有人告诉您这是一个“企业应用程序”时要小心。对于太多不同的人来说，这是一个带有太多内涵的加载术语。确保明确安全，授权，身份验证，服务保证等交叉问题。
企业应用程序容易膨胀。不要害怕对新功能说“不”，并通过良好的单元测试无情地重构，以确保你获得最大的收益。
最后，一切都在适度。将上述任何一种（或任何一般情况下，真的）推向极端都是一个坏主意。你唯一真正应该做的就是节制本身！ ：）
答案 1 :(得分：2)
简要回答一个大问题 - 不要先从课堂设计开始。从组件，层的设计开始，并做出一些技术决策，例如“我是否需要数据库，如果需要，哪一个”。这假设您已经对问题域进行了一些分析，发现了一些必要的用例等。
当您准备好了它时，编写一个“直通”应用程序来验证您的架构决策可能是个好主意。这意味着，一个小型应用程序触及大多数图层，同时只处理一个非常小的用例。当您认为部分架构存在缺陷时，它应该足够小，以便轻松地重写/纠正/抛弃。这也是一个很好的技术，可以抓住你的班级设计。
答案 2 :(得分：1)
我看到了两种基本的设计活动。
主要系统部分存在分解。因此，您已经了解了将演示文稿与系统的其他部分分开。你可能也会有一些业务逻辑和持久性。第一个重要的问题，你真正拥有多少业务逻辑。有些系统只是简单数据库前面的薄皮，几乎没有任何真正的业务逻辑。其他人拥有非常重要的业务逻辑部分，在某种程度上是独立的。
如果您拥有主要的半独立作品，他们最好通过事件和消息队列进行通信。因此，要确定您是否有需要这种解耦关系的碎片，这会导致识别事件和这些事件的有效负载。这是福勒在另一个答案中引用的地方变得相关的。
接下来深入探讨业务逻辑部分。接口和抽象类等是用于构造复杂性实现的技术。分离您的代码，以便隐藏详细信息并启用灵活性。我认为这是一个OO设计练习，有很多书籍，例如head first。