Setting up for TTD in Visual Studio 2012

1. Setting up for TTD in Visual Studio 2012 • Project | Manage NuGet Packages • Select the online tab • Search for Nunit • Select the Nunit package • Follow these instructions to download and install the Nunittest adapter: http://nunit.org/index.php?p=vsTestAdapter&r=2.6

2. Setting up for TDD in Eclipse • See steps 4 and 5 in this tutorial: • http://mobile.tutsplus.com/tutorials/android/android-sdk-junit-testing/

3. Reducing Dependency

4. Class Interdependency • When one class depends on another there are undesirable consequences • It is more difficult to reuse the dependent class • It is more difficult to maintain the dependent class • It is more difficult to test the dependent class

5. Class Dependency • Class A is said to be dependent on class B when class B is required for class A’s specification or implementation. • Example: • class Car { : private: Engine theEngine; }; • The Car class depends on the Engine class.

6. UML Indication of dependency • The Car class depends on the Engine class

7. We will try to remove dependencies when practical • We can remove a dependency on a class by changing it to a dependency on an interface. Car can now use any propulsion system that implements the interface “Propulsion System”

8. Car class is much more extensible now.

9. It is also easier to test! We can write fakes classes that implement Propulsion System for unit tests.

10. We broke an interclass dependency using an interface • Benefits • Car can now have any engine that implements the Propulsion System interface • As new engines are developed, we can use them in Car – provided that the new engines implement the Propulsion System Interface. • This makes Car easier to test, because we can make fake classes that implement Propulsion System.

11. Dependency Inversion Principle • High-level modules should not depend on low-level modules. Both should depend on abstractions. • Abstractions should not depend upon details. Details should depend upon abstractions. “It doesn’t matter what language a program is written in. If its dependencies are inverted, it has an OO design. If its dependencies are not inverted, it has a procedural design.” -Robert C. Martin

12. Dependency Inversion Principle • Depend upon abstractions: Do not depend upon concrete classes. • Code to interfaces – not class definitions. • High-level components should not depend on low-level components • Both high-level and low-level classes should depend on abstractions.

13. Guidelines for reducing Dependencies(Head-first Design Patterns) • Beware of variables that hold references to concrete classes • Beware of classes that derive from concrete classes • Beware of classes that override an implemented member function in a base classes • Because the subclass is relying on a concrete class, not an abstraction.

14. Interfaces in C++ // In C++ we can implement interfaces as abstract base classes // in which all member functions are public pure virtual. class PropulsionSystem { public: // Request that the engine produce a certain amount of energy. virtual void requestBTU(float BTUs) = 0; // See how much energy the engine is currently producing virtual float getBTU() = 0; };

15. Instantiating the Propulsion InterfaceMethod 1: Constructor Instantiation class Car { private: PropulsionSystem* propulsionSystem_; }; Car::Car(PropulsionSystempropulsionSystem) : propulsionSystem_(propulsionSystem) {} Car::~Car() { delete propulsionSystem_; }

16. Using Constructor Instantiation Car myCar(new InternalCombustionEngine()); Car myElectricCar(new ElectricEngine()); Car myTestCar(new FakeEngine()); /* The use of the interface provides flexibility; however, as soon as we say new we must refer to a concrete class and thus generate a dependency */

17. Instantiating the Propulsion InterfaceMethod 2: getter/setter Instantiation class Car { public: setPropulsionSystem(PropulsionSystem* newSystem); private: PropulsionSystem* propulsionSystem_; }; // Usage Car myCar; myCar.setProulsionSystem(new ElectronicEngine());

18. A Simple Factory Classes • Simple Factory class act like virtual constructors. You send the simple factory some information about your situation, and it returns the appropriate class. class SimplePropulsionFactory { public: static PropulsionSystem* createPropulsion(const string& reqs); };

19. Simple Factory createPropulsion PropulsionSystem* SimplePropulsionFactory::createPropulsion(const string& req) { PropulsionSystem* prop = 0; if(string == “green”) prop = new ElectricEngine(); if (string == “fast”) prop = new InternalCombustionEngine(); if (string == “test”) prop = new FakeEngine(); return prop; }

20. Instantiating the Propulsion class Method 3: Using a Simple Factory // Create a propulsion system using the factory – pass the // factory to the Car constructor. PropulsionSystem prop = SimpleFactory::createPropulsion(“green”); Car myCar(prop);

21. Method 4: Allow the subclasses to decide: Factory Method Pattern class Car { virtual void createPropulsion() = 0; }; class GreenCar : public Car { void createPropulsion() { propulsionSystem_ = new ElectricEngine(); } }

22. Method 5: The Abstract Factory Pattern • The Abstract Factory Pattern provides an interface for creating families of related or dependent object without specifying their concrete classes. [Head First Design Patterns] • There may be a number of things that vary from Car to Car • Propulsion Systems • Exhaust Systems • Saftey Systems • Create an interface for an abstract factory that produces each of the items that vary across Cars

23. CarCompnentFactory is an Example of the Abstract Factory Pattern class CarComponentFactory { public: PropulsionSystem* createPropulsion() = 0; ExhaustSystem* createExaustSystem() = 0; SafteySystem* createSaftySystem() = 0; }; class CaliforniaComponentFactory { // overrides abstract methods with concrete implementations } class EuropeanUnionComponentFactory { // overrides abstract methods with concrete implementations}