Dependency Inversion Principle

This morning I was "retroFactoring" an application for purposes of giving an assignment to my software design class requiring application of Robert (Uncle Bob) Martin's Dependency Inversion Principle. I say "retroFactoring" because I was taking the application that was already refactored back to an application that I will give to the class for refactoring. In the process of doing so, the inversion of the dependency came about forthwith when I removed the interface. This required the switch class in the 'device' ('higherlevel') layer to learn about the classes in the 'lower level' layer - the light bulb and the fan. Thus I had to place an import statement in the switch class ('higher level') so it would know about these switchable objects ('lower level'). It was when I realized that I needed to place the import statement allowing access to these 'lower level' classes that I realized I was setting up the dependency of 'higher level' classes on 'lower level' classes. This is exactly the situation Martin refers to when he states: "High-level modules should not depend on low-level modules."