Talk:Dependency inversion principle

This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer scienceWikipedia:WikiProject Computer scienceTemplate:WikiProject Computer scienceComputer science

???

This article has not yet received a rating on Wikipedia's content assessment scale.

???

This article has not yet received a rating on the project's importance scale.

Things you can help WikiProject Computer science with:

Here are some tasks awaiting attention:

Article requests :
- Requested articles/Applied arts and sciences/Computer science, computing, and Internet
Cleanup :
- Computer science articles needing attention
- Computer science articles needing expert attention
Copyedit :
- Computing
Expand :
- Computer science
Infobox :
- Computer science articles without infoboxes
Maintain :
- Timeline of computing 2020–present
Photo :
- Find pictures for the biographies of computer scientists (see List of computer scientists)
- Computing articles needing images
Stubs :
- Computer science stubs
Unreferenced :
- WikiProject Computer science/Unreferenced BLPs
Project-related :
- Tag all relevant articles in Category:Computer science and sub-categories with {{WikiProject Computer science}}

Introduction

I miss a reference to the original author of this principle Robert C. Martin in "Agile Software Development: Principles". --Klodr (talk) 01:08, 7 January 2013 (UTC) [reply]

Description

It's wrong that the interface which defines the services required by the higher layers is in the same package. That will result in an undesirable impact to re-usability of lower layers. For example, packages that defines persistence or logging sub-systems. The perfect DIP implementation requires that both layers depend on abstractions in separate libraries or packages. The dependency inversion is only by name, defining the policy as an abstraction of services, not for implementation or compilation.

--Klodr (talk) 01:08, 7 January 2013 (UTC)[reply]