The*_*bra 8 architecture oop design-patterns
在编码之前,我总是想知道我是在考虑太多还是太少.如果我不确定未来可能需要更改哪些我需要考虑的情况,对我来说尤其如此.我不知道我应该如何灵活或抽象地制作课程.我举一个简单的例子.
你想编写一个针对计算机玩二十一点的程序,你就是那种喜欢尝试的人.你开始编写套牌的代码,但是你知道二十一点可以有1,2,4或任意数量的套牌.你说明了这一点,但是你意识到也许甲板会被改变而没有价值十的牌.然后,您决定该套牌应该是完全多功能的,以允许任何数量的套装或等级.然后你决定甲板的规则应该能够从标准的套装数量乘以独特的等级改变到等于套牌中的牌总数......你可以看到我要去的地方.
我的问题是,有没有关于课程应该如何灵活的指导方针？
支持极简主义和封装,避免您不需要的功能.
根据需要设计当然是好的,但是应该尽量减少使用不使用或未来可能使用的东西的设计混乱.可以考虑并实施您确定需要的东西.
当您理解并指定"未来问题"(特别是在未来的那个时候)时,您将经常解决它与今天的解决方案不同的问题.
查看1972年 David Parnas撰写的伟大论文" 关于将系统分解为模块的标准 " .
一般来说,您应该尝试确定可以在隐藏有用功能和复杂性的非常简单的界面背后推动的责任区域.您应该努力将您认为最有可能改变的区域(即预测变化)区分开来.