我正在进行一个项目，其中自然的方法是使用基于不同类的子组件来实现主对象，例如由CPU、GPU。。。
我从一个组合结构开始，其中组件具有其子系统固有的属性和功能，每当需要更高级别的属性时，它们都会作为参数给出。
现在，随着我添加更多的功能，拥有不同类型的主对象是有意义的，例如笔记本，它将扩展PC类，但仍然有CPU等。目前，我正在使用一个单独的脚本，其中包含与该类型相关的所有功能。
通过对不同类型的主对象使用子类，将继承和组合结合起来会被认为是不好的做法吗
简而言之
偏爱组合而非继承并不排除继承，也不会自动使两者的结合成为一种糟糕的做法。这是关于做出明智的决定。
更多详细信息
建议更喜欢组合而不是继承是一条经验法则。它最早是由GoF创造的。如果你阅读他们的完整论证，你会发现这与作文好和继承坏无关；它的组成更灵活，因此在许多情况下更适合。
但你需要根据具体情况做出决定。事实上，如果您考虑复合模式的一些变体，叶类和复合类的专业化在某些情况下是完全合理的：
- 多态性可以避免大量的CCD_ 1和CCD_
- 在某些情况下，组合可能需要额外的调用转发开销，而当它真正涉及类型专门化时，这可能是不必要的
- 组合和继承的结合可以用来两全其美(注意：如果不小心应用，也可能两全其差(
注意：如果您想用UML图提供上下文的简短概述，那么可以在您的特定上下文中提供更多的参数。同时，这个关于SE的问题也可能引起的兴趣