SOLID principles

Back when I was having my Software Quality and Testing course with professor Ken Bauer (for whom I wrote a couple of blog entries as well) he asked us if anyone knew the reason for which importing library.module was a bad practice. Nobody on the class was really aware of it. Having a bunch of dependencies that you are not going to use was really unsafe since any change in an upper level of the dependencies trees could potentially break your code for no reason and have you smashing your head against the keyboard for no reason. Though following most good coding practices can be easy, writing classes that look after serving a single purpose sounds pretty darn challenging to me. It also seems to be contradictory since many of the patterns we have learnt throughout the course are ways to make classes flexible so they can manage tasks depending on the scenario. Next on the reading the LSP principles are presented and seem to have a bit confusing since this states that instead of using inheritance to get the functionality of a parent class you should just implement composition. I believe that the reading is missing some important trade offs. For instance, having a bunch of different interfaces in an ISP model would mean that you would have to write every single required method every time you need an instance of such class. At this point of the course I believe that there are no silver bullets when it comes to software design, "the experience whenever this is based on" needs to specify the requirements where this comes from rather than making a generalization about if whether something should be implemented this way or that way.