2

Lets imagine that we have a large data structure (lets call it Configuration) and various client classes (lets call them Services). Each service needs just one or two fields from Configuration.

If we inject the whole Configuration object to the various Services, does this violate the ISP? Does the fact that Configuration is technically a data structure and not a literal Java interface change the fundamental point behind ISP?

The practical dilemma I am facing is how configuration should become available to the various parts of my system. I have the option to use Spring's @Value annotation, through which each component gets precisely what it needs and nothing more. My second option is to make a Configuration instance available as a whole. In the second case, every component of the system would get the configuration of the whole system instead of getting only the few parts that it actually needs.

I am trying to understand whether the second option violates ISP.

OldProgrammer
  • 12,050
  • 4
  • 24
  • 45
Alkis Mavridis
  • 1,090
  • 12
  • 28
  • Such things are guidelines, not iron-clad Rules That Must Be Obeyed. Which choice makes your application easier to understand, more maintainable, etc? – user16632363 Sep 18 '21 at 12:54
  • 1
    As a first guess, I think that the first one is easier. Testing for example. I think it requires more effort and more complexity to construct / mock the whole Configuration object than to simply pass a string or a boolean to the service. Still, my question now is whether ISP applies to large data structures, or whether it is strictly limited to interfaces. – Alkis Mavridis Sep 18 '21 at 14:15

1 Answers1

2

Strictly according to Bob Martin, yes. His example of applying ISP to a stack certainly seems to imply that data structures are included.

On the other hand, this question is often asked of the Dependency Inversion Principle, e.g. here, here, and here. As I have answered in regard to the DIP, I don't think it makes sense to apply it to a data structure. Your mileage may vary when applying object-oriented principles to procedural-programming constructs.

jaco0646
  • 15,303
  • 7
  • 59
  • 83