我正在处理一个大型项目(对我来说)，它将有许多类，需要可扩展，但我不确定如何规划我的程序以及类需要如何交互。
几个学期前我上了一门OOD课程，从中学到了很多东西;比如编写UML，并将需求文档转换为对象和类。我们也学过序列图但不知怎么的我错过了这节课，我没能记住它们。
在之前的项目中，我尝试使用从课程中学到的方法，但通常在我说“是的，这看起来像我想要的东西”时，我就会以代码结束，我不想再挖掘出新的功能。
我有一本Steve McConnell的《Code Complete》，我经常在这里和其他地方听到它的神奇之处。我读了关于设计的章节，似乎没有得到我想要的信息。我知道他说这不是一个固定的过程，它主要是基于启发式，但我似乎不能把他所有的信息都应用到我的项目中。
那么，在高级设计阶段(在开始编程之前)，你要做些什么来确定你需要什么类(特别是那些不基于任何“现实世界对象”的类)以及它们如何相互交互?
我特别感兴趣的是你使用的方法是什么?你遵循什么样的过程，通常会产生一个良好的，干净的设计，将接近最终产品?
当前回答
我在实际项目中使用的成功的技术是责任驱动设计，灵感来自Wirfs-Brock的书。
从最顶层的用户故事开始，与同事一起，在白板上勾勒出它们所暗示的高级交互。这让你对大模块有了初步的了解;重复一两次高级CRC-card(游戏邦注:如play)，你应该已经稳定了一个主要组件列表，它们的作用以及它们如何相互作用。
然后，如果任何职责很大或很复杂，那么细化这些模块，直到有足够小且简单的东西成为对象，方法是在模块内执行由更高级别交互确定的每个主要操作的交互。
知道什么时候该停下来是一个判断问题(只有经验才能决定)。
其他回答
当我有机会时，我通常会使用我所谓的“三次迭代规则”。
In the first iteration (or startup), I devise the general layout of the application according to the model objects, the algorithms, and the expected (really expected, not maybe expected) future directions. I don't write design documents, but if I have to coordinate multiple people, a rough sketch of the procedure is of course needed, together with an analysis of dependencies and guesstimate of the time needed. Try to keep this phase to a minimum if, like me, you prefer a more agile method. There are cases where a strong design phase is needed, in particular when everything is known and true about the logic of your program, and if you plan to have a lot of interactions between features in your code. In this case, use cases or user stories provide are a good high level idea, in particular for GUI apps. For command line apps, and in particular libraries, try to write "program stories" in which you code against the library you have to develop and check how it looks. These programs will become functional tests of your library when completed.
After this first iteration, you will have a better understanding on how things interact, got out the details and the rough spots, solved issues with a slapped duct tape patch. You are ready to make use of this experience to improve, clean, polish, divide what was too large, coalesce what was too fragmented, define and use design patterns, analyze performance bottlenecks and nontrivial security issues. In general, all these changes will have a huge impact on the unit tests you wrote, but not on the functional tests.
当您完成第二次迭代时，您将拥有一个经过良好测试、良好记录和良好设计的小珍宝。现在您已经有了进行第三次迭代(扩展)的经验和代码。您将添加新的特性和用例来改进应用程序。你会发现一些粗糙的地方，最终你会进入与第二次类似的第四次迭代。清洗并重复。
这是我软件设计的一般方法。它类似于螺旋设计，具有简短的，三个月的迭代，以及敏捷开发的元素，允许您了解问题并了解您的软件及其应用领域。当然，这是一个可伸缩性的问题，所以如果应用程序非常大，涉及到数百名开发人员，事情就会比这复杂一些，但最终我想想法总是一样的，分门别类。
总结一下:
在第一次迭代中，您将体验并学习它 在迭代2中，您将清理产品并为未来做好准备 在迭代3中，您添加了新特性并了解了更多 转到2
在你要写的软件设计中，你遵循的工作流程是什么?
我用于初始设计(得到类图)的步骤是:
Requirements gathering. Talk to the client and factor out the use cases to define what functionality the software should have. Compose a narrative of the individual use cases. Go through the narrative and highlight nouns (person, place, thing), as candidate classes and verbs (actions), as methods / behaviors. Discard duplicate nouns and factor out common functionality. Create a class diagram. If you're a Java developer, NetBeans 6.7 from Sun has a UML module that allows for diagramming as well as round-trip engineering and it's FREE. Eclipse (an open source Java IDE), also has a modeling framework, but I have no experience with it. You may also want to try out ArgoUML, an open source tool. Apply OOD principles to organize your classes (factor out common functionality, build hierarchies, etc.)
恐怕人们不愿意听到这样的回答。无论如何，让我陈述我的观点。
OOP should be viewed as one of the paradigms, not as the superior paradigm. OOP is good for solving certain kind of problems, like developing a GUI library. It also fits into the style of software development usually followed by large software companies - an elite team of designers or architects lays down the software design in UML diagrams or some other similar medium and a less enlightened team of developers translate that design into source code. OOP offer little benefit if you are working alone or with a small team of highly talented programmers. Then, it is better to use a language that supports multiple paradigms and will help you to come up with a prototype fast. Python, Ruby, Lisp/Scheme etc are good choices. The prototype is your design. Then you improve on that. Use the paradigm that is best to solve the problem at hand. If needed, optimize hot spots with extensions written in C or some other systems language. By using one of these languages, you also get extensibility for free, not just at the programmer level but also at the user level. Languages like Lisp can dynamically generate and execute code, which means your users can extend the application by writing small code snippets, in the language that the software itself is coded! Or if you choose to write the program in C or C++, consider embedding an interpreter for a small language like Lua. Expose functionalities as plugins written in that language.
我认为，大多数时候OOP和OOD所创造的软件都是过度设计的受害者。
总之，我喜欢的写软件的方式是:
使用动态语言。 用这种语言编写设计(原型)。 如果有必要，使用C/ c++优化某些领域。 通过实现语言本身的解释器提供可扩展性。
最后一个特性使软件能够轻松地适应特定用户(包括我自己!)的需求。
设计模式
创造性设计模式
单例——确保只创建类的一个实例，并提供对象的全局访问点。
Factory(Factory Method的简化版)—创建对象时不向客户端公开实例化逻辑，并通过公共接口引用新创建的对象。
Factory方法——定义一个用于创建对象的接口，但是让子类来决定实例化哪个类，并通过公共接口引用新创建的对象。
抽象工厂——提供了创建一系列相关对象的接口，而无需显式地指定它们的类。
Builder -定义一个创建对象的实例，但让子类决定实例化哪个类，并允许对构造过程进行更精细的控制。
Prototype—指定使用原型实例创建的对象类型，并通过复制该原型创建新对象。
行为设计模式
责任链——它避免了将请求的发送方附加到它的接收方，从而使其他对象也可以处理请求。 -对象成为链的一部分，请求通过链从一个对象发送到另一个对象，直到其中一个对象处理它。
命令-将请求封装在对象中，允许对不同请求的客户端进行参数化，并允许将请求保存在队列中。
解释器——给定一种语言，为其语法定义一个表示法，并定义一个解释器，使用该表示法解释该语言中的句子/将域映射到语言，将语言映射到语法，将语法映射到分层面向对象的设计
迭代器——提供一种方法，可以按顺序访问聚合对象的元素，而不暴露其底层表示。
中介——定义一个对象，它封装一组对象如何交互。Mediator通过防止对象显式地相互引用来促进松耦合，并且允许您独立地改变它们的交互。
观察者——在对象之间定义一对多的依赖关系，这样当一个对象改变状态时，它的所有依赖关系都会被自动通知和更新。
策略——定义一组算法，封装每个算法，并使它们可互换。策略允许算法独立于使用它的客户机而变化。
模板方法——在一个操作中定义一个算法的框架，将一些步骤推迟到子类/模板方法让子类重新定义算法的某些步骤，而不让它们改变算法的结构。
Visitor -表示要在对象结构的元素上执行的操作/ Visitor允许您定义一个新操作，而无需更改其操作的元素的类。
空对象——提供一个对象作为缺少给定类型对象的代理。/空对象模式提供了智能的无为行为，对合作者隐藏了细节。
结构设计模式
适配器——将一个类的接口转换成客户端期望的另一个接口。/ Adapter允许类一起工作，否则由于不兼容的接口而无法一起工作。
桥接——将对象组合成树形结构来表示部分-整体层次结构。/ Composite允许客户端统一地处理单个对象和对象的组合。
复合——将对象组合成树状结构来表示部分-整体层次结构。/ Composite允许客户端统一地处理单个对象和对象的组合。
装饰器——动态地向对象添加额外的职责。
Flyweight——使用共享来支持大量的对象，这些对象的部分内部状态是相同的，而另一部分状态可能是不同的。
记忆碎片——在不违反封装的情况下捕获对象的内部状态，从而提供了在需要时将对象恢复到初始状态的方法。
代理——为对象提供一个“占位符”来控制对它的引用。
