1

I have 2 modules (containing multiple classes). Let's call them Module A and Module B. Module B has a dependency on Module A: Module B -> Module A. Now, I have created an utility class C, which A and B are supposed to use but the utility itself depends on functionality found in A and B, thus A and B also depend on C. So something like this: C <-> B -> A <-> C.

Unfortunately, I am not allowed to extract the dependency from A and B and put them somewhere else, so they have to remain untouched (except for code using the utility). Making the utility an Interface and implementing it in A and B also does not work because the implementations would also depend on A and B respectively causing again a cyclic dependency...

Is this a general design issue of how my project is designed which is unsolvable?

EDIT: adding a bit more of details.

The dependencies are in form of method calls to classes located inside the modules A and B. An extraction would be possible but it would break the initial design and also make it look weird as it makes sense to keep them where they are.

Improve this question
2
  • Thanks for the suggestion. i will add a bit more of details but cannot go into details because of corporation limitations. – sceiler May 19 '16 at 12:34
  • Can you show an example using method names such as "foo()", "bar()", etc. – Jay Elston Jun 2 '16 at 18:14
1

If C is an utility class to be reused from A and B, it should not contain any direct dependencies from A and B. That is as simple as it is.

However, if C needs a service from A (or B) to fulfill its purpose, you should define an interface for that service, make A (and/or B) implement that interface, and inject the service into C during construction:

   class C
   {
        IService _service;
        C(IService x)
        {
            _service=x;
        }
   }

   class A : implements IService
   {
       C c;
       A()
       {
           c=new C(this);
       }
   }

This way, there will be no need to extract anything from A or B into another place, you just allow C to access the functionality in A or B through the IService interface.

Improve this answer
0

It's hard to tell without knowing more about the code, but the way you describe it, the only solution would indeed be to extract the parts from A and B that C depends on, and move these parts into C. Then A and B can depend on C, and C depends on neither.

If that is not an option (why?), then the only option I can see is to modify C such that it no longer depends on A or B. In my experience this is usually possible, but to be more specific, we'd need more details about your code.

Improve this answer
1
  • I cannot go into code details because it is company owned code. But by current design, extracting the dependency (some methods and classes) would break the design as it would be really weird to not have them where they are now. So yes it would be possible but would break the design. The other possibility would be to copy-paste the respective code but that would cause code duplication... – sceiler May 19 '16 at 12:32
0

Can't you like change modules A and B in a way where you only write wrappers that incorporate the functionality you want to keep, but really use the functionality from module D. Then you can keep using Module A and B in exactly the same way you did, but the common functionality is really in Module D.

This way you don't take the functionality out of A and B.

a wrapper could be something like this:

function a(){
  dosomething()
}

becomes:

function d(){
  dosomething()
}

function a(){
  d()
}

You can keep using function a like you used to be the logic is somewhere else.

Improve this answer
2
  • Thanks for this suggestion. I am not really familiar with wrappers but that sounds great. I will have a look at it. – sceiler May 19 '16 at 12:33
  • @sceiler I updated my answer with an example. – Pieter B May 19 '16 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.