如何从抽象的项目描述变成实际的代码?

• 这些东西有什么样的行为?它们之间有天然的依赖关系吗(例如,一个 LineItem 没有上下文就没有意义 Order ,也不是 Engine 不需要一个 Car )这些行为如何影响其他对象的状态?他们之间有交流吗?如果有,用什么方式?这些想法将帮助您开发类的公共接口。

当然,这只是冰山一角。关于这个思维过程的更多信息,请参阅埃里克·埃文斯的优秀著作, Domain-Driven Design

如何决定何时何地创建接口或使用抽象类?

• 如果几个不相关或显著不同的对象类型都提供相同的功能,请使用接口。例如,如果 Steerable 接口具有 Steer(Vector bearing) 方法,可能有很多不同的东西可以控制: Boat S Airplane CargoShip 小型车 s、 等等。这些都是完全不相关的事情。但它们都有一个共同的界面,即能够被操纵。

• struct

一般来说。。。

1. 读很多别人的代码。开源项目是很好的选择。不过要尊重他们的执照。
2. 你永远不会得到完美的。这是一个反复的过程。如果你做得不对,不要气馁。
3. 练习。练习。练习。

没有灵丹妙药,也没有好的设计算法。

当时机成熟时,我将实现理解,结果将不得不重构(重写)早而不是晚。

给这个项目你最好的机会,留意你的错误,以及在你得到结果后应该怎么做。

继续这样做,你会没事的。

code from the top-down, not from the bottom-up . 使用尚未创建的api,尽可能清晰简洁地编写主函数,就像它们已经存在一样。然后,您可以以类似的方式实现这些api,直到您拥有只有几行长的函数。如果你自下而上编写代码,你很可能会创建很多你实际上并不需要的东西。

关于何时创建接口。。。几乎所有的东西都应该是一个接口。当您使用尚不存在的api时,假设每个具体类都是某个接口的实现,并使用表示该接口的声明类型。您的继承应该只通过接口来完成。只有在提供实现时才在最底层创建具体的类。我建议避免使用抽象类,而只使用委托,尽管当两个不同的实现略有不同,并且有几个函数有一个共同的实现时,抽象类也是合理的。例如,如果您的接口允许对元素进行迭代,并且还提供了一个sum函数,那么sum函数对于迭代函数来说是一个很小的实现,因此这将是对抽象类的合理使用。另一种方法是在这种情况下使用decorator模式。

How to Design a Good API and Why it Matters software design observations .

另外,对于未来,您可以继续阅读有关的基础知识 domain driven design 为了使自己适应真实世界场景,它为需求映射到真实类提供了坚实的基础。