OOP的缺点？ [英] Disadvantage of OOP?
问题描述
通常我不想知道OOP的缺点的具体情况，但是当我最近参加的一次面试时，我觉得有点奇怪。发给我的问题是告诉我面向对象编程的一个缺点（ OOP）。那时，我认为OOP是程序和功能模型之后最成熟的编程水平。所以我回答他说我根本没有看到任何负片。
但是面试官说很少，如果他不这样做，我就让他列出一个心神。他举了一个例子，我不能很好地消化。他说，OOP模式并没有严格执行继承规则，并引用了卫星/火箭示例，其中身体部位会在火箭发射期间定期瓦解以消除重量，并表示继承不支持这一点。
他的例子对我来说非常奇怪，原因是继承应用于这个例子。
我明白他给出的例子几乎没有任何意义，但我怀疑 -
在一个理想的
面向对象设计中，我们可以动态地拔掉类层次结构
（我对Java中的b
有点自信）吗？
我不完全理解他的例子。
<然而，重要的是要理解OOP对于可以用它自然建模的事物非常有效，并且对于其他事物（例如，横切关注点或方面）非常无效。这是OOP的一个缺点。另一个原因是，由于动态调度，它经常会产生一些运行时成本。
此外，滥用OOP非常容易进行无法识别的抽象。火箭继承自身体就是一个例子。我的经验是，当其他行为（如聚合）更合适时，新手开发人员或者不信任并且不使用继承，或者他们过于渴望并且错误地使用它。随着时间的推移，对机制的经验和理解会有所改善。
我不确定他的意思是OOP模式没有严格实现继承规则，因为OOP不是一种模式。一个潜在的问题是，人们可以编写一个可能违反Liskov替换原则的子类型，因此覆盖方法不会像被覆盖的方法那样至少表现。没有办法自动检查这一点，因此可以编写违反OOP原则的代码。
至于你的最后一个问题我们可以在理想情况下拔掉类层次结构面向对象的设计？，我不确定你的意思。如果您要求在运行时更改层次结构，并使其从执行中的某个点不再存在子类型关系，那么是。对于某些语言，例如Smalltalk，它是可能的。有人会说这是更多的OOP。在smalltalk中，类型支持的方法是在方法调用时根据当前层次结构和每个类的当前内容确定的。虽然我喜欢smalltalk，但这是一个我并不疯狂的功能，因为我更喜欢编译时检查，减少运行时间的惊喜。
Typically I don't want to know the specifics of the cons of OOPs, but it felt kind of weird when I had an argument at an interview I attended recently. The question that was posted to me was to tell me one disadvantage of object-oriented programming (OOP). At that time, I felt OOP to be the most matured level of programming after the procedural and functional models. So I replied to him that I don't see any negatives at all.
But the interviewer said there are few, and I asked him to list one if he does not mind. He gave an example that I don't digest well. He said that an OOP pattern does not strictly implement inheritance rules and cited the satellite/rocket example where the body parts will disintegrate periodically to remove weight during rocket launch and said that inheritance does not support this.
His example kind of felt very weird to me, the reason being the application of inheritance to this example.
I understand that the example he gave hardly had any sense at all, but I had this doubt -
Can we unplug class hierarchies dynamically (I am kind of confident in Java it's not possible) in an ideal object-oriented design?
I'm not fully understanding his example.
However, it's important to understand that OOP is very effective for things that can be modeled naturally with it, and is very ineffective for other things (e.g., crosscutting concerns or aspects). That is one disadvantage of OOP. Another is that it often incurs some runtime cost due to dynamic dispatching.
In addition, it is very easy to abuse OOP to do nonsensible abstractions. Having a rocket inherit from a body is one example. My experience is that novice developers either don't trust and don't use inheritance, or that they are over-eager and use it incorrectly, when other behaviors (like aggregation) are more appropriate. Over time, experience and understanding of the mechanism improve.
I'm not sure what he meant by "OOP pattern does not strictly implement inheritance rules", since OOP is not a pattern. One potential issue is that one can write a subtype that can violate Liskov's principle of substitution, so that an overridding method does not behave "at least" like the overridden method. There is no way to automatically check for this so it is possible to write code that violates OOP principles.
As for your final question "Can we unplug class hierarchies in an ideal Object Oriented Design?", I'm not sure what you mean here. If you're asking about changing the hierarchy at runtime, and making it so that a subtyping relation no longer exists from some point in the execution, then yes. It is possible with certain languages such as Smalltalk. Some would argue that this is "More OOP". In smalltalk, the 'methods' supported by a type are determined at the point of method call based on the current hierarchy and the current contents of each class. While I love smalltalk, this is one feature that I'm not crazy about, since I prefer compile-time checking with less runtime surprises.
这篇关于OOP的缺点？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
