如何重构紧密耦合的类？
我正在尝试重构一个大型紧密耦合的应用程序，并尝试使其更加可维护和灵活。
我有很多单元测试，所以我希望逐步重构。
哪个设计& 我应该考虑实施/应用重构模式来完成这项任务吗？
我能想到一些：
也请随意分享您自己的此类重构工作的经验和最佳实践。
更新
我正在执行此重构因为这个问题中解释的原因。 基本上，如果不提取几个接口，我就无法实现插件系统，并且这些接口是高度耦合的，这需要将应用程序分成 40 多个 DLL，以便在没有循环引用问题的情况下进行编译。
I'm trying to refactor a big tightly coupled application and trying to make it more maintainable and flexible.
I've got many unit tests, so I'm hoping to refactor step by step.
Which Design & Refactoring Patterns should I consider implementing / applying to accomplish this task ?
I can think of some :
Also feel free to share your own experience and best practices for this kind of refactoring job.
UPDATE
I'm carrying out this refactoring because of the reasons explained in this question. Basically I can't implement a plugin system without extracting an couple of interfaces and those interfaces are highly coupled which requires separated the application in 40+ DLLs to just compile without circular referencing problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
严肃地说，重构并不是一件可以掉以轻心的事情，尤其是在紧密耦合的系统中。 在执行之前，它通常看起来是一项值得的任务，但根据我的经验，一旦开始，它很快就会成为一种负担，因为它通常更有可能引入新的错误，而不是解决任何现有问题。
在开始重大重构之前，您应该考虑收益是什么以及有哪些替代方案（例如从头开始创建新产品、仅重构立即需要的部分等）。 在开始之前，您当然应该充分了解架构、角色和职责，以及预期和现有的行为，以确保您知道何时破坏了某些内容。
此外，制定重构后的设计以及如何映射到当前实现也是有益的，这样您就可以保持重点。 您还应该尽可能频繁地进行回归测试。
当设计明显需要重构时，完美主义者可能会感到沮丧，但有时必须考虑更改的成本/收益并放弃战斗。 如果你必须做出改变，请小心行事，不要尝试一次做太多事情。
In all seriousness, refactoring is not an undertaking to be taken lightly, especially in tightly coupled systems. It can often seem like a worthwhile task before it has been performed, but from my experience, it can soon become a burden once started as it is often more likely to introduce new bugs than solve any existing issues.
Before embarking on a major refactoring, you should consider what the gains will be and what alternatives there are (such as creating a new product from scratch, refactoring only the parts that need it right away, etc.). You should certainly have a good understanding of the architecture, roles, and responsibilities before starting, as well as the expected and existing behavior to ensure that you know when you've broken something.
Also, it can be beneficial to draw up a design of how it will be after the refactoring and how that maps to the current implementation so that you can stay on point. You should also regression test as often as possible.
It can be frustrating to the perfectionist when a design is quite obviously in need of refactoring, but sometimes one has to consider the cost/benefit of the changes and concede the battle. If you must make the changes, tread carefully and don't try to do too much at once.
这是一个很大的问题，一个人可以写一整本书来回答它。 幸运的是，已经有人这么做了。 为自己获取一份 Michael Feathers 撰写的有效处理遗留代码的副本。 这几乎是一本专门用来回答你的问题的书。
这也是一本非常好的书。 我肯定会把它与代码完整、设计模式和实用程序员一起列入每个开发人员都应该拥有的书籍清单中。图书馆。
This is a big question, and one could write an entire book in answer to it. Fortunately, someone already has. Grab yourself a copy of Working Effectively with Legacy Code by Michael Feathers. It's pretty much an entire book devoted to answering your question.
It's a really good book, too. I'd definitely put it up there with Code Complete, Design Patterns, and Pragmatic Programmer on a list of books that should be in every developer's library.
接口重构和依赖注入将是减少耦合的关键。 您可能还想考虑使用工厂来创建依赖对象。
Refactoring to interfaces and dependency injection are going to be key in reducing coupling. You might also want to consider using factories for the creation of your dependent objects.
以上所有内容，还有一些。但在开始之前，我会考虑一下大局。 定义程序的各个部分（包、项目等），然后制定计划将功能移动到适当的包中。 然后，一旦一切都在逻辑上应该开始使用提取接口、依赖注入和工厂方法来开始解耦包。
All of the above and then some. But before you start any of that, I'd think about the big picture. Define the sections of your program (packages, projects, etc) and then have a plan for moving functionality around to be in the appropriate package. Then once everything is where it logically should be start using extract interface, dependency injection, and factory methods to start de-coupling the packages.
菲利普的一些很好的建议：
重构唾手可得的成果
我认为很难说哪些具体重构适合您的业务具体案例没有更多信息。
Some great advice from Phlip:
Refactor the Low-hanging Fruit
I think it's very hard to say which specific refactorings are appropriate in your specific case without a great deal more information.
感谢所有答案，在尝试了多种不同的方法之后，我发现最好的办法就是为所有东西创建接口。 这使我能够自由地更改设计，并且只破坏一天的构建（一天是因为项目很大，我需要修复如此多的引用和单元测试+一些重构）。
经过一天的提取和修复所有界面后，我可以创建单独的解决方案并自由地进行设计。
基本上，我认为第一步应该是将所有内容移至接口，然后尝试摆脱内部依赖关系。
Thanks for all answers, After struggling with so many different ways I found that the best thing to do was creating interfaces for everything. This allowed me to change the design freely and I only break the build for a day (a day because the project was big and I need to fix so many references and unit tests + some refactoring).
After day extracting and fixing all interfaces I can create separate solutions and play with the design freely.
Basically first move I think should be moving everything to interfaces and then try to get rid of internal dependencies.