c# - Interface inheritance to breakup god objects? -

c# - Interface inheritance to breakup god objects? -

i work on big product. it's been in development since .net 1.0 still work-in-progress , has lot of bad quality code , not written unit tests in mind. we're trying improve quality , implement tests each feature , bug fix. 1 of biggest problems we're having dependency hell , god objects. there 1 god object in particular that's bad: session. basically, related current session of programme in object. there few other god objects.

anyway, we've made god object "mockable" using resharper extract interface out of them. however, still makes hard test because of time have @ code write figure out needs mocked out of 100 different methods , properites.

just splitting class out of question right because there literally hundreds if not thousands of references class.

because have interface(and code has been refactored utilize interface) though, had interesting idea. if made isession interface inherit other interfaces.

for instance, if had this:

interface ibar { string baz{get;set;} } interface ifoo { string biz{get;set;} } interface isession: ifoo, ibar { }

in way, existing code using isession wouldn't have updated, nor actual implementation have updated. but, in new code write , refactor can utilize more granular ifoo or ibar interfaces, pass in isession.

and eventually, see making easier break actual isession , session god interface/object

now you. way of testing against these god objects , breaking them up? documented approach and/or design pattern? have ever done this?

from standpoint , right approach. later can inject more specific service instances ifoo/ibar rather isession, intermediate step before farther refactoring extract classes god class many specific services.

some pros see:

first stage: extract interfaces

a super (god) class type abstracted interfaces code becomes less coupled since relies on single-function responsible interfaces (services) you have ground move farther , split god class many services without massive refactoring sicne everythign relies on interfaces api

second stage: split god class many little services keeping single responsibility principle in mind

third-stage: structurize existing unit tests tests grouped per service type rather around god class

c# unit-testing interface refactoring god-object