In a direct application of dependency inversion, the abstracts are owned by the upper/policy layers. This architecture groups the higher/policy components and the abstractions that define lower services together in the same package. The lower-level layers are created by inheritance/implementation of these abstract classes or interfaces.
Ideally as wiki article also said(In approach 2 under Implementation section) abstraction module should be separate module for loose coupling,
But I have question on approach 1 with quoted statement. In mine experience wherever 2 is not implemented/possible, I have always see abstraction classes are packaged with low level modules instead of high level module.
Drawback of packaging abstraction/interfaces with high level packages is that if there are 10 high level modules calling a given low level module, then we need to package the interfaces in all 10 modules. Consider I have to add one method in interface, I have to modify all 10 modules to add that method. Is n't it ? So as per mine understanding abstraction classes should be packaged with low level modules instead of high level .
Correct me If I am wrong here ?
I will disagree with your point, "I have always see abstraction classes are packaged with low level modules instead of high level module". If you have seen the same then that class design would defenitely be wrong.
Let's compare abstraction with a real world example. Say you have a electric switch / socket think that as an abstration / interface or a high level module. Socket doesn't know which device it is connecting to. In this case devices are low level modules. In fact socket (high level module) doesn't want to know which low level modules (devices) it is connecting to. Any device which is compatable to that socket can connect to it. compatability is a kind of implementing the abstraction (socket). Only those devices designed to connect that socket only can connect to socket. Say devices designed for India cannot connect to UK sockets. Now if high level module knows about low level modules it is equivalent to design sockets for each device because in that case device is not based on abstraction.
Now to answer your question of implementing interface to all classes if there a change, sometimes we cannot avoid it but while designig an abstraction don't make it fat (Interface Segregation Principle). Logically group you interfaces and not put everything together in an interface. While designing an interface think many times regarding the grouping. I do agree still we will end up in adding more behaviour to interface and will end up to impelement it in classes. But if we design interace in a logical group then that implementation would be a needed one to all classes.