14

I'm learning about the Dependency Inversion Principle. It states that:

High level modules should not depend upon low-level modules. Both should depend upon abstractions.

For a while I tried to understand what it means that both the high level components and the low level components, rely on the abstractions and are dependent on them.

I'm assuming both should depend on the same abstraction in some way. Please correct me if this is wrong.

I have come to some conclusion about what this means. Please confirm if this is accurate.

enter image description here

"The high level components are dependent on the abstraction" - Meaning:

The high level components talk to an interface to communicate with the low level components, instead of communicating with concrete low level components directly. The low level components implement this interface.

"The low level components are dependent on the abstraction" - Meaning:

The low level components are defined and designed in the terms of the interface. They are designed to fit the interface. They are dependent on the interface, in the way that the interface defines how they are designed. (Often low level classes implement that interface).

This way, both the high level components and the low level ones are 'dependent on the abstraction', but in different ways.

Is this a good understanding?

Improve this question
5
  • 11
    You're pretty much spot on. The last piece of the puzzle is that the interface is defined by the high-level component, not the low-level one. In other words, the high-level concern (eg the domain model) gets to choose the most convenient way to talk to the low-level code (like data-access code), and it's the job of the low-level code to conform to that interface. When you understand that the interface is part of the high-level behaviour, the term 'dependency inversion' makes much more sense.
    – Benjamin Hodgson
    Apr 6, 2014 at 15:12
  • 1
    @BenjaminHodgson I see. Let me see if I understand. Obviously an object can't define an interface, that's the programmer's job. So by 'the interface is defined by the high-level component', I assume you mean 'the programmer defines the interface in terms of what will be a convenient way for the high-level components to talk to the low-level ones'. Do you confirm?
    – Aviv Cohn
    Apr 6, 2014 at 15:15
  • (since the low-level ones will later implement this interface and be constructed according to it).
    – Aviv Cohn
    Apr 6, 2014 at 15:21
  • Yes, obviously all of the code is written by the programmer. I was trying to convey the idea that the interface is conceptually part of the high-level concern; you should put it in the same package as your high-level code and it should change according to the business requirements, not in response to changes in implementation details.
    – Benjamin Hodgson
    Apr 6, 2014 at 16:16
  • 1
    I would just add a caveat that although it's ideal, you're not always given the luxury of defining the low level interface in terms of whatever the high level component's requirements are. For example, if you're integrating an existing library that provides some useful functionality into your app, chances are you have high level components that represent the business function you're trying to accomplish. They use that low level library (like maybe iText for example) to actually do the work. You probably won't have the luxury of defining the abstraction without regard to what iText needs.
    – Calphool
    Apr 22, 2014 at 15:06

2 Answers 2

Reset to default
8

Your understanding of the concept is very accurate.

Pointing out exceptions, special cases or philosophical minutiae right now would be diverting you from your present clarity of concept.

I would suggest, though, you use UML symbols:

enter image description here

  • Open arrow : uses
  • Closed arrow: inherits or implements
  • << name in brackets >> : interface or abstract class
Improve this answer
0

Yes, many people think of software construction as in building construction. The DB is the "foundation" the DAL sits on top of it, the Business Layer Sits on the DAL, the UI sits on the Business Layer...

Instead think of it as a hanging mobile. Where the "layers" hang from a common anchor. UI and Business Layer both hang from the Business Interface, Business Layer and DAL both hang from the DAL interface, DAL and Database connect through the DB Interface.

Improve this answer

Your Answer

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

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