也许是因为我现在已经编了两个学期左右的编码，但是我现在要做的主要绊脚石是将教授的项目描述和要求转换为实际的代码。由于我目前在算法101，我基本上做了一个自下而上的过程，首先是一个空白的白板，并绘制出对象和方法的交互，然后将其转化为类和代码。你如何从抽象的项目描述转到实际的代码？
但是现在教授已经把接口和抽象类放入混合中。在理智上，我可以认识到它们是如何工作的，但是我的脚趾正在琢磨如何在当前项目中使用这些新工具（模拟Web服务器）。
在我的教授自己的话中，将抽象描述映射到Java代码是真正的技巧。那么，哪些步骤最适合用于从英语（或任何您的语言）到计算机代码？你如何决定何时何地创建接口，或者使用抽象类？
那么哪些步骤最适合用于从英语（或任何您的语言）到计算机代码？
经验教你如何做到这一点。如果它不自然地来了，但（！如果它没有不心疼，因为它需要很长的时间），也有一些问题，你可以问自己：
有哪些主要概念系统？他们如何相互关联？如果我向别人描述这个，我会用什么词和短语？这些想法将帮助您决定哪些课程有益于思考。
这些东西有什么样的行为？它们之间是否有自然依赖关系？ （例如，如果没有Order的上下文，则LineItem不相关或无意义，如果没有Car，则Engine也不是很有用。）行为如何影响其他对象的状态？他们是否相互沟通，如果是，以什么方式？这些想法将帮助你开发你的类的公共接口。
这当然只是冰山一角。有关此思考过程的更多信息，请参阅Eric Evans的优秀书籍Domain-Driven Design。
如何决定何时何地创建接口或使用抽象类？
没有硬性和快速的处方;再次，经验是这里最好的指导。这就是说，肯定有一些经验法则可以遵循：
如果几个不相关的或显著不同的对象类型都提供同样的功能，使用的接口。例如，如果接口具有方法，则可能有许多不同的事物可以被操纵：Boat s，Airplane s，CargoShip s，Car s等。这些是完全不相关的事情。但他们都拥有能够被驾驭的共同界面。
一般来说，尝试使用接口而不是抽象基类。这样你可以定义一个实现N接口的实现。在Java的情况下，你只能有一个抽象基类，所以一旦你说一个类继承另一个类，就会被锁定到一个特定的继承层次中。
无论何时您不需要基类的实现，绝对支持通过抽象基类的接口。如果您使用继承不适用的语言进行操作，这也很方便。例如，在C＃中，不能从基类继承struct。
一般...
有没有灵丹妙药，或算法的良好设计。
现在我加入了一个设计，我认为这是一个体面的工作。
当时间正确时，我会实现理解结果将不得不重构（重写），而不是晚些时候。
给这个项目最好的照片，留意你的错误，以及在你收到结果后应该怎么做。
继续这样做，你会没事的。
你应该真正做的是code from the top-down, not from the bottom-up。尽可能使用您尚未创建的API来清楚简洁地编写主函数，就好像它们已经存在一样。然后，你可以用类似的方式实现这些API，直到你的函数只有几行。如果你从底层开始编写代码，你可能会创建一大堆你并不需要的东西。
关于何时创建接口......几乎所有的东西都应该是一个接口。当您使用尚不存在的API时，假定每个具体类都是某个接口的实现，并使用指示该接口的声明类型。你的继承应该完全通过接口完成。当您提供实施时，只能在最下方创建具体类。我建议避免抽象类和仅使用委派，但是当两个不同的实现稍微不同时，抽象类也是合理的，并且有几个具有共同实现的函数。例如，如果你的接口允许迭代元素并提供一个sum函数，那么sum函数在迭代函数中是一个很小的实现，所以这将是一个抽象类的合理使用。另一种方法是在这种情况下使用装饰器模式。
您可能还会发现Google Techtalk“How to Design a Good API and Why it Matters”在这方面很有帮助。您可能也有兴趣阅读我自己的一些software design observations。
另外，对于未来的未来，您可以继续阅读关于domain driven design的基础知识，以使自己符合现实世界的情景 - 它为需求映射到实际类提供了坚实的基础。
我知道这个问题没有任何完美的答案，但感谢给我最深的思考。 – Jason 2010-03-26 10:16:56