开始解耦对象的最佳位置
这是一个 C# 问题，但实际上可能与语言无关
我继承了一个大型对象模型（100 多种类型），具有“拥有”0..n 个其他类型对象的对象层次结构，这些对象都共享一个基础（其中有一个“相对”严格的类型层次结构）。
我想开始通过继承来解耦这些对象，以组合一个基于 IoC 的系统，开始实现一些比当前存在更深入的单元测试。
最好从哪里开始？
我可以从层次结构的顶部开始，这很简单，但最初的好处最少，而且在我进一步深入链之前会很死记硬背，但这需要我在基础对象上实现一些小东西重载函数签名以接受基本接口，直到我获得完全覆盖。
我可以从层次结构的底部开始，这会更棘手，因为那里的类之间有更多的交互，但会“迫使”我们对重构采取更全面的看法。
我还可以从基本对象（所有对象都继承自的对象）开始，这将在逻辑点开始进程，但几乎肯定会创建一个无法编译的应用程序，直到我们交换所有对象继承和函数调用。
有什么想法吗？
This is a C# question, but really could be language-agnostic
I have inherited a large object model (100+ types), with a hierarchy of objects that 'own' 0..n of other typed objects that all share a base (where there is a 'relatively' strict type hierarachy).
I want to start decoupling these objects though inheritance to put together an IoC based system to start to implement some unit tests with greater depth than currently exist.
Where would be the best place to start?
I can start at the top of the hierarchy, which is quite simple but would have the least initial benefit, and would be quite rote until I get further down the chain, but that would require me to implement a few cludges at the base object to overload function signatures to accept base interfaces until I get full coverages.
I could start at the bottom of the hierarchy, which would be much trickier, as there is alot more interaction between classes down there, but would 'force' us to take a more holistic view of the refactoring.
I could also start at the Base objects (those which all the objects are inheriting from) which would start the process off at the logical point, but would almost certainly create an uncompilable application until we get to swap out all the objects inheritances and function calls.
Any thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这可能有点太学术了，但是九十年代中期有很多关于如何自动重构大型类层次结构的研究，例如通过找出常用的接口等。虽然这可能无法解决您的问题，它可能会给你一个很好的选择，让你从哪里开始，或者至少对这类问题提供一些有趣的视角。
该链中的第一篇论文是 Godin 和 Mili 的
“使用伽罗瓦格构建和维护分析级类层次结构”
（谷歌，你会找到PDF），
并且有一系列关于不同技巧的后续论文（请参阅引用此的论文）。
This may be a little too academic, but there was a lot of research in the mid-nineties on how to automatically refactor large class hierarchies, for example by figuring out interfaces that are commonly used, etc. While this may not solve your problems, it may give you a good option of where to start or at least some interesting perspective on these sort of problems.
A first paper in that chain was Godin and Mili's
"Building and maintaining analysis-level class hierarchies using Galois Lattices"
(google and you shall find the PDFs),
and there was a whole series of following papers (see papers that cited this) on different tricks.
从顶部开始，创建较小的层次结构，向下移动时使用委派而不是继承。 使用策略模式从层次结构中的类中删除行为。
Start from the top and create smaller hierarchies, using delegation instead of inheritance as you move down. Use the strategy pattern to remove Behaviors from classes in the hierarchy.
我想说
只要开始...而不是花 BDUF 时间试图找出方法方法...它会变得清晰。 当然，拥有良好 AT 的安全网至关重要。
I'd say
Just get started... instead of spending BDUF time trying to figure out the way.. it'll clear up. Of course, having a safety net of good ATs would be vital.
如果您可以在合理的时间内完成整个过程，请从基础开始并完成整个过程； 如果您必须同时保持应用程序运行，那么应用程序将被破坏，直到您完成
，从顶部开始，一次向下几个类，
我也会看看自下而上的视角，但怀疑它将是一种实用的实施方法，因为它可能会破坏一切并且比其他两种方法花费更长的时间，但是您的里程可能会有所不同;-)
基本问题是：
if you can complete the entire process in a reasonable amount of time, start with the bases and go through the whole thing; the app will be broken until you are done
if you must keep the app working in the meantime, start at the top and work your way down a few classes at a time
i would look at the bottom-up perspective also, but doubt that it will be a practical way to implement since it likely will break everything and take longer than the other two approaches, but Your Mileage May Vary ;-)
the base questions are: