逻辑矛盾在课堂设计中背叛了OOP吗？

我有3个班。他们有所有类似的整数，方法等...逻辑矛盾在课堂设计中背叛了OOP吗？

class Country{ 

     int a,b; 
public: 
     Country(); 
     void doSomething(); 
     : 
     : 
} 

class Military : public Country { 
public: 
     Power(); 
     void doAnother(); 
     void doAnother2(); 
     : 
     : 
} 

class Technology : public Military{ 
public: 
     Technology(); 
     void doAnother3(); 
     : 
     : 
}

假设这种继承适合我的解决方案。但正如你所看到的，当我从国家创建军事时，逻辑上它们之间没有关系。我的意思是，军队不是一个国家。同样来自国家的技术，问题也是一样的。技术不是军事也不是国家。

无论如何，这个解决方案对我来说是好的，它缩短了我的代码，但是如果我这样做，我会背叛面向对象的编程理念吗？这是否是一个矛盾？

来源

2012-04-17 vkx

欢迎来到Stack Overflow！对于你的具体'doSomething'（'tax（）'？'signTreaty（）'？），说'Technology tech; tech.doSomething（）'？如果不是，那么这个继承不适合你的解决方案。 – 2012-04-17 15:02:52

FWIW，看起来你正在尝试用'Power'构建一个'Military'。虽然这在哲学上可能是真实的，但它不是C++的价值。 – 2012-04-17 15:04:23

是的......甚至没有'typedef军事实力;'将在C++视图中修复这个问题。 – Potatoswatter 2012-04-17 15:06:04

是的，这是反对OOP。您的关系是has-a，而不是is-a。

您应该为此使用组合而不是继承。

class Country{ 
     Military m; //Country has-a military 
     int a,b; 
public: 
     Country(); 
     void doSomething(); 
} 

class Military{ 
     Technology t; //Military has-a technology 
public: 
     Military(); 
     void doAnother(); 
     void doAnother2(); 
} 

class Technology{ 
public: 
     Technology(); 
     void doAnother3(); 
}

来源

2012-04-17 15:00:55

所有这些继承关系都是错误的。一个国家“拥有”军事和军事“拥有”技术。因此他们应该是成员。继承是“是一种”关系。

如果您颠覆了语言结构的预期含义，您可能会在稍后付钱。

来源

2012-04-17 15:01:04 Potatoswatter

这是错误的设计
当你继承某个类时，它的is-a关系。并且继承不是code reuse

您可以为它们常见的行为建立has-a关系。

如键盘有按钮，我的衬衫也有。但我的衬衫is not a键盘。
所以它应该设计为shirt has buttons和keyboards has buttons。

来源

2012-04-17 15:02:34

逻辑矛盾在课堂设计中背叛了OOP吗？

回答

相关问题