展开面向对象的代码
是否有任何工具可以扩展面向对象的代码，从而避免任何类型的共享？例如，如果我有两个继承 C 的类 A 和 B，那么该工具将调整类 A 和 B 以不再使用 C。如果该工具执行此操作并且仍然编译并产生相同的结果，那就太好了。我认为如果动态检查类类型，主要的困难将是调整任何条件逻辑。
我知道从机器的角度来看这完全没有意义，但这将是一个有趣的学术练习。
Are there any tools that will expand object oriented code so there is no sharing of any kind? For example if I have two classes A and B which inherit C then the tool would adjust classes A and B to no longer use C. It would also be nice if the tool did this and it still compiled and produced the same results. I think the main difficulty would be adjusting any conditional logic if class type is checked dynamically.
I know this is totally pointless from a machine perspective, but it would be a fun academic exercise.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
虽然有各种重构工具，但我怀疑你的问题是否具有实际应用，因为它需要大量的上下文知识和人工干预来执行这种自动操作。
在您的示例中，A 和 B 获取 C 的方法和属性并不够，而且事实上，在许多情况下，您希望将 A（或 B）交给方法并像 C 一样对待它。或者，您可能希望将其交给需要 C 的对象，但调用 A（或 B）的特定行为——想象一个对其中的任何对象调用 .DoThing() 的集合。
您不仅必须分解类，而且还必须拥有各种其他重载函数以及大量看起来冗余的代码（特别是对于类型，而不仅仅是行为）。
我想说，虽然这是一个有趣的思想实验，但也许我们应该把它放在坏主意堆里。我怀疑它会对可读性、可扩展性或性能有所帮助。
While there are various refactoring tools out there, I doubt your question has practical application as it would require substantial contextual knowledge and human intervention to perform that kind of automatic manipulation.
In your example, it's not just enough that A and B obtain C's methods and properties, but the fact that in many cases, there are places where you want to hand A (or B) to a method and have it treated like a C. Or, you might want to hand it to something that takes a C, but have A's (or B's) specific behavior invoked --- imagine a collection that invokes .DoThing() on whatever object is inside of it.
You'd have to not only bust apart the classes, but have all kind of other overloaded functions with lots of redundant looking code (especially for the types, not just the behaviors).
I'd say while an interesting thought experiment, perhaps we should place it in the bad idea pile. I doubt it would help for readability, extensibility, or performance.
问题是使用 C 而不是 A 或 B 的代码很难处理：
在我们的 OO 代码中，我们可以将 A 或 B 传递给该函数。如果 A 和 B 不再有任何共同点，就不能这样做。
我认为通过复制这样的代码可以使某些东西起作用，但天哪，这是一个多么可怕的想法;-)
The problem with this is that code which uses C rather than A or B is hard to deal with:
in our OO code we can pass either an A or a B to that function. Can't do that if A and B no longer have anything in common.
I would think by duplicating such code something could be made to work, but good grief what a horrible idea ;-)