组成与继承

这个话题在开发社区中引起了紧张(特别是OOP,职能人员会适当地告诉您去猎鸭)。 OOP在1990年代引入并在2000年初由Java推广时,带来了一组漂亮的小功能(Poly,封装,…)和继承。OOP是解决现实问题的一种有效方法,对于某些人(甚至我) )很有道理。 一切都是一类,它具有自身固有的功能,您可以在自然需要时覆盖这些功能,以及一些其他有趣的东西。 继承也是一种无害的功能,本来应该做的很好,但是自从引入以来,继承就被深度嵌套的继承严重滥用,这种继承为更高的类创建了冗余的代码库以及紧密的耦合问题。 任何OOP狂热者都会告诉您继承是多么伟大,如何用继承来建模大多数问题(值得称赞)在一定程度上确实可行。 随着应用程序的增长和需求的变化,与您之前给出的动物基础类相比,将要求您编写一个类,该类将是蹦极跳和唱歌的宠物小精灵。 深度嵌套继承还导致违反DRY原则的冗余代码( 请勿 自行 重复 )。 就像要香蕉一样,您会得到一只800磅重的愤怒大猩猩,里面盛着香蕉,还有整个雨林。 好。 所以继承不是最好的主意。 组成是? 5分钟的搜索时间可以确保消除您认为宝贵的任何理智。 人们(兴高采烈的开发人员)将继续讨论如何在继承上使用合成,以及如何使用继承是愚蠢的(不是),而且他们也都没有错。…