c++ - SOLID: Does DIP mean that composition/aggreation to an object is forbidden? -

i trying understand , apply solid principles. regarding dependency inversion principle, means composition/aggregation object forbidden? interface must used access class method?

i mean that:

class serviceclass {   void serviceclasshelper(); }  class mainclass {   void mainclass(serviceclass service); // use serviceclasshelper } 

must changed to:

class serviceinterface {   virtual void interfacehelper() =0; }  class serviceclass : public serviceinterface {   void serviceclasshelper();   void interfacehelper() { serviceclasshelper(); }; }  class mainclass {   void mainclass(serviceinterface service); // uses interfacehelper } 

i think (or @ least hope) understand principle. wonder if can rephrased that. indeed, stuff read dip suggest use interfaces.

thanks!

basically, main idea of dip is:

• high-level modules should not depend on low-level modules. both should depend on abstractions.
• abstractions should not depend on details. details should depend on abstractions.

as can see, says should , not must. not forbid doing anything.

if classes composite of / aggregate to other specific classes (not interfaces / abstract classes), fine! code still compile , run, no warnings displayed telling you: "hey, violating dip". think answer question is: no, doesn't.

imagine system composed of thousand classes, can apply dip 2 classes , have 1 of them depends on 3rd specific class (not interfaces / abstract classes). long problem solved, nothing matters. try keep solution short & simple -> easy understand. trust me find valuable 1 month after when @ solution.

dip guideline tells when face specific set of problems in order solve them. not magical guideline, comes @ cost: complexity. more apply dip more complex system be. use wisely. further support point, recommend take @ reference (taken head first: design patterns book). access link (it pdf file) , @ top bar navigate page 635 / 681. or if lazy enough, read below quote:

your mind on patterns

the beginner uses patterns everywhere. good: beginner gets lots of experience , practice using patterns. beginner thinks, “the more patterns use, better design.” beginner learn not so, designs should simple possible. complexity , patterns should used needed practical extensibility.

as learning progresses, intermediate mind starts see patterns needed , aren’t. intermediate mind still tries fit many square patterns round holes, begins see patterns can adapted fit situations canonical pattern doesn’t fit.

the zen mind able see patterns fit naturally. zen mind not obsessed using patterns; rather looks simple solutions best solve problem. zen mind thinks in terms of object principles , trade-offs. when need pattern naturally arises, zen mind applies knowing may require adaptation. zen mind sees relationships similar patterns , understands subtleties of differences in intent of related patterns. zen mind beginner mind — doesn’t let pattern knowledge overly influence design decisions.

finally, point gang of 4 design pattern make use of dip: strategy

example problem: character can use 3 types of weapon: hand, sword, & gun. (character) can swap current weapon whenever wants.

analysis: typical problem. tricky part how handle weapon swapping @ run-time.

candidate solution strategy: (just sketchup):

weapon = new hand(); weapon.attack(); // implementation of hand class  weapon = new sword(); weapon.attack(); // implementation of sword class  weapon = new gun(); weapon.attack(); // implementation of gun class 

---

other design patterns & frameworks make use of dip:

• inversion of control (a.k.a ioc)
• dependency injection
• autofac framework (you can download & play it)