Interface inheritance for destroyers?

Question

I am working on a fairly large product. It was in development since .Net 1.0 was still incomplete, so it has a lot of poor quality code and was not written taking into account unit tests. Now we are trying to improve the quality and conduct tests for each function and error correction. One of the biggest problems that we have now is hellish objects and objects of God. In particular, there is one god object: Session . In principle, everything related to the current session of the program is located in this object. There are several more objects of God.

In any case, we made the object of this god “mock”, using Resharper to extract an interface from them. However, this still makes testing difficult, because most of the time you have to look at the code you write to find out that you really need to mock 100 different methods and properties.

A simple separation of this class is out of the question, because there are literally hundreds, if not thousands, of references to this class.

Because I have an interface (and almost all the code has been reorganized to use the interface), although I had an interesting idea. What if I made the ISession interface inherit from other interfaces.

For example, if we had something like this:

 interface IBar { string Baz{get;set;} } interface IFoo { string Biz{get;set;} } interface ISession: IFoo, IBar { } 

Thus, existing code using ISession does not need to be updated, and the actual implementation should not be updated. But in the new code we write and refactoring, we can use the more granular IFoo or IBar interfaces, but pass ISession.

And in the end, I see that it probably makes it easier, ultimately, to break up the actual interface / session object of ISession and Session

Now to you. Is this a good way to test against these god objects and ultimately break them? Is this a documented approach and / or design pattern? Have you ever done something like this?

Answer 1

From my point of view, this is a good and correct approach. Later, you can introduce more specific service instances like IFoo / IBar rather than ISession , I would say that this is a good intermediate step before further refactoring to extract classes from the god class to many specific services.

Some professionals that I see:

Phase one: Interfaces to Retrieve

• The class type super (god) is abstracted by interfaces
• The code becomes less connected because it uses single-function responsible interfaces (services)
• You have reason to move on and divide the god class into many services without massive refactoring. Sicne anythign already relies on APIs

Second stage : divide the class of gods into many small services while maintaining the principle of single responsibility

>

The third stage . Structure your existing unit tests so that the tests are grouped by service type, and not all together around the god class.