This analysis makes sense, and states anything that avoids code duplication and simplifies maintenance speaks for a service layer.

What is the technical behavior?

  1. When a service client references a service, does it do so at runtime, or does it happen at compile time?
  2. When I change something in the service layer code, will this change be automatically taken into account in all it's clients, or do they need to be individually recompiled?
  3. How does this make sense from a testing point of view - I have working code, based on some code from a service, but if that service changes, my code might break?!

1 Answer 1

  1. Typically service references are acquired through some sort of dependency injection, not hardcoded. They may even be remote calls.
  2. It should most definitely not be necessary to recompile clients when a service changes
  3. Yes, definitely. That's why the service API should be narrow and explicitly specified. And see the upside too: you have broken code based on a buggy service, but if someone fixes the service now your code works!
  • In point 1, does "hardcoded" have any meaning for languages that don't require pre-run compilation? Commented Nov 13, 2012 at 15:38
  • @kevin cline: yes - hardcoded to me also implies that the dependency is fixed in the dependent code, whereas with depdendency injection you typically have a central point where all the dependencies are configured. Commented Nov 13, 2012 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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