我正在处理一个大型项目(对我来说),它将有许多类,需要可扩展,但我不确定如何规划我的程序以及类需要如何交互。

几个学期前我上了一门OOD课程,从中学到了很多东西;比如编写UML,并将需求文档转换为对象和类。我们也学过序列图但不知怎么的我错过了这节课,我没能记住它们。

在之前的项目中,我尝试使用从课程中学到的方法,但通常在我说“是的,这看起来像我想要的东西”时,我就会以代码结束,我不想再挖掘出新的功能。

我有一本Steve McConnell的《Code Complete》,我经常在这里和其他地方听到它的神奇之处。我读了关于设计的章节,似乎没有得到我想要的信息。我知道他说这不是一个固定的过程,它主要是基于启发式,但我似乎不能把他所有的信息都应用到我的项目中。

那么,在高级设计阶段(在开始编程之前),你要做些什么来确定你需要什么类(特别是那些不基于任何“现实世界对象”的类)以及它们如何相互交互?

我特别感兴趣的是你使用的方法是什么?你遵循什么样的过程,通常会产生一个良好的,干净的设计,将接近最终产品?


当前回答

设计模式

创造性设计模式

单例——确保只创建类的一个实例,并提供对象的全局访问点。

Factory(Factory Method的简化版)—创建对象时不向客户端公开实例化逻辑,并通过公共接口引用新创建的对象。

Factory方法——定义一个用于创建对象的接口,但是让子类来决定实例化哪个类,并通过公共接口引用新创建的对象。

抽象工厂——提供了创建一系列相关对象的接口,而无需显式地指定它们的类。

Builder -定义一个创建对象的实例,但让子类决定实例化哪个类,并允许对构造过程进行更精细的控制。

Prototype—指定使用原型实例创建的对象类型,并通过复制该原型创建新对象。

行为设计模式

责任链——它避免了将请求的发送方附加到它的接收方,从而使其他对象也可以处理请求。 -对象成为链的一部分,请求通过链从一个对象发送到另一个对象,直到其中一个对象处理它。

命令-将请求封装在对象中,允许对不同请求的客户端进行参数化,并允许将请求保存在队列中。

解释器——给定一种语言,为其语法定义一个表示法,并定义一个解释器,使用该表示法解释该语言中的句子/将域映射到语言,将语言映射到语法,将语法映射到分层面向对象的设计

迭代器——提供一种方法,可以按顺序访问聚合对象的元素,而不暴露其底层表示。

中介——定义一个对象,它封装一组对象如何交互。Mediator通过防止对象显式地相互引用来促进松耦合,并且允许您独立地改变它们的交互。

观察者——在对象之间定义一对多的依赖关系,这样当一个对象改变状态时,它的所有依赖关系都会被自动通知和更新。

策略——定义一组算法,封装每个算法,并使它们可互换。策略允许算法独立于使用它的客户机而变化。

模板方法——在一个操作中定义一个算法的框架,将一些步骤推迟到子类/模板方法让子类重新定义算法的某些步骤,而不让它们改变算法的结构。

Visitor -表示要在对象结构的元素上执行的操作/ Visitor允许您定义一个新操作,而无需更改其操作的元素的类。

空对象——提供一个对象作为缺少给定类型对象的代理。/空对象模式提供了智能的无为行为,对合作者隐藏了细节。

结构设计模式

适配器——将一个类的接口转换成客户端期望的另一个接口。/ Adapter允许类一起工作,否则由于不兼容的接口而无法一起工作。

桥接——将对象组合成树形结构来表示部分-整体层次结构。/ Composite允许客户端统一地处理单个对象和对象的组合。

复合——将对象组合成树状结构来表示部分-整体层次结构。/ Composite允许客户端统一地处理单个对象和对象的组合。

装饰器——动态地向对象添加额外的职责。

Flyweight——使用共享来支持大量的对象,这些对象的部分内部状态是相同的,而另一部分状态可能是不同的。

记忆碎片——在不违反封装的情况下捕获对象的内部状态,从而提供了在需要时将对象恢复到初始状态的方法。

代理——为对象提供一个“占位符”来控制对它的引用。

其他回答

学习和掌握设计模式。 接下来,学习领域驱动设计 之后,学习需求收集

我上了几个学期的OOD课程 回来后,我学到了很多;就像 编写UML和翻译 将需求文档转换为对象 和类。我们学过序列 图表也有,但不知怎么的,我错过了 讲座之类的,他们没有 跟紧我。

You know about the step 3. You need to master it. I mean, via a lot of practice to make it become your second nature. That's because the method you learn, is simply against the way we used to have. So you need to really master it. Otherwise, you will always find yourself go back to your original way of doing thing. This is somehow like Test Driven Process, where a lot of java developer give it up after a few tries. Unless they fully master it, otherwise it's just a burden to them Write use cases, especially for alternate course. Alternate course occupy more than 50% of our development time. Normally when your PM assign you a task, for instance, create a login system, he will think it's straight forward, you can take 1 day to finish it off. But he never take into account that you need to consider, 1. what if user key in wrong password, 2. what if user key in wrong password for 3 times, 3. what if user doesn't type in user name and etc. You need to list them out, and show it to your PM, ask him to reschedule the deadline.

如果你对你要从事的项目有专业知识,比如银行业。你可以很容易地构建你的对象,而且你知道每隔一天就会有这些增强。

如果你没有这方面的专业知识,那就和有这方面专业知识的人合作,把这些想法转化为技术细节。

如果你对如何组织你的项目设计感到困惑。盲目地遵循“实用的程序员”这本书。我以前也遇到过同样的情况,试着读那本书的一章。它会改变你作为软件开发人员的思维方式。

它经常被重复,但完全正确——理解你的数据。

对于面向对象编程,你的类应该描述重要的信息片段以及它们如何交互。

如果您有一个心智模型,它很好地描述了数据的行为和生命周期,那么您将很容易布局您的类。

这句话其实是“确切地知道你要做什么”的延伸。

斯科特·戴维斯补充说:

Make absolutely sure you know what your program is all about before you start. What is your program? What will it not do? What problem is it trying to solve? Your first set of use cases shouldn't be a laundry list of everything the program will eventually do. Start with the smallest set of use cases you can come up with that still captures the essence of what your program is for. For this web site, for example, the core use cases might be log in, ask a question, answer a question, and view questions and answers. Nothing about reputation, voting, or the community wiki, just the raw essence of what you're shooting for. As you come up with potential classes, don't think of them only in terms of what noun they represent, but what responsibilities they have. I've found this to be the biggest aid in figuring out how classes relate to each other during program execution. It's easy to come up with relationships like "a dog is an animal" or "a puppy has one mother." It's usually harder to figure out relationships describing run-time interactions between objects. You're program's algorithms are at least as important as your objects, and they're much easier to design if you've spelled out what each class's job is. Once you've got that minimal set of use cases and objects, start coding. Get something that actually runs as soon as possible, even though it doesn't do much and probably looks like crap. It's a starting point, and will force you to answer questions you might gloss over on paper. Now go back and pick more use cases, write up how they'll work, modify your class model, and write more code. Just like your first cut, take on as little at a time as you can while still adding something meaningful. Rinse and repeat.

这只是我的个人意见。希望对大家有用。

一个有用的技巧是将你独特的问题描述与你在现实世界中可以找到的东西联系起来。例如,你正在为一个将席卷全球的复杂医疗保健系统建模。有什么例子你可以随时调用建模吗?

确实。观察旁边的药房是如何运作的,或者医生的房间。

把你的领域问题归结为你能理解的问题;一些你能联想到的东西。

然后,一旦领域内的“玩家”开始出现,你开始对你的代码建模,选择“提供者-消费者”建模方法,即你的代码是模型的“提供者”,而你是“消费者”。

与领域相关并在较高层次上理解它是任何设计的关键部分。