OOP:何处停止抽象

你在哪里绘制线来停止抽象并开始编写合理的代码？有很多"企业代码"的例子,比如十几个文件"FizzBu​​zz"程序......即使像RTS游戏那样简单的东西也可以有:

class Player {} ;/// contains Weapons
class Weapons{} ;/// contains BulletTypes
class BulletType{} ;///contains descriptions of Bullets 
class Bullet{} ;///extends PlaceableObject and RenderableObject which can be placed/drawn respectively
class PlaceableObject{} ;///has x,y,z, coords
class RenderableObject{} ;///an object with a draw() command
class MovingObject{}; ///an object with a move() function

等...它可以变成一场噩梦.这可以被绘制到它的逻辑极端,就像函数式编程可以被绘制到极端,你可以创建一个只有变量,函数应用程序和匿名函数定义的语言(虽然我必须承认它稍微更优雅)...

关于这个话题的任何理智的建议？

YAGNI(你不需要它).不要创建您看不到立即使用的抽象或明智的理由.通过这种方式,你可以使一件简单的事情变得更加复杂,而不是那些你会努力使事情更简单但却失败的复杂事物.

确保抽象有意义.如果他们离现实太远,太难以证明......忘掉它.

让解决方案感觉自然.努力工作直到它.然后对于一个不熟悉的人来说,解决方案看起来应该是那么明显,他尖叫着"你怎么能以不同的方式做到这一点？".

不要试图预测未来.你不能.如果你试图涵盖所有10个可能的案例,你很快就会发现第11个或更多,并且由于之前的10个实践它将更难实现,在实践中没有遇到.使其简单易用. 软件需要改变,但是易于适应(敏捷性)通常比预先覆盖所有可能的案例更好.