c# Dependency Injection

Dependency Injection is a way to implement the Inversion of Control (IOC) principle. 

Start of app, need to configure container. One option is to create a class to configure (register interfaces to implementations). 

Benefits of Dependency Injection.

A) Unit testing. Can now mock implementations for interfaces. So instead of actually Saving data, it mocks a successful save. Instead of reading data, it mocks returned data. In the unit test, you can Verify that each call is done. Can check logged messages. 

B) Able to change code implementations later. Without changing the "internal" code. Just change the container to register the interface to the new implementation (new class) ... existing code should work as is. This decoupling of code makes large applications very modular and flexible. It is now plug and play. 

Types of DI:

1) Constructor Injection (most popular)

public class InjectedClass
{
    private IDepInterface _iDependInterface;

    public InjectedClass(IDepInterface myInterface)
    {
        _iDependInterface = myInterface;
    }
}


2) Property Injection (applied at the property level)
 
private IDepInterface _myProp;

public IDepInterface MyDependencyProperty
{
     get { return ths._myProp;  }
    set { this.myProp = value;  }
}


3) Method Injection (when entire class doesn't need dependency, but just that one method)

public class InjectedClass
{
     readonly IDepInterface _iDependencyInterface;
  
    public MyMethod(IDepInterface myInterface)
    {
        // use myInterface
    }
}

SOLID

https://www.youtube.com/watch?v=gwIS9cZlrhk


Single Responsibility Principle - a function should only have one reason to change

OC Principle - a class should be open for extension but closed for modification. Once a class is done, it is done (unless there is a bug).

Meyer: Derives from requirements for the code. If requirements change, instead of changing the class, make a new class that inherits from the old class. Make the changes in the new class instead and leave the old class untouched. If you make the method in the old class "virtual", then you can "override" the method in the new class.

Massive question: how much of the class do you make "virtual". Very difficult to answer because once its coded, you are not supposed to go back and change from "virtual" to not "virtual" and vice versa.

Also, sometimes its hard to determine if its a bug or feature change.

Upside: if you code something and build a bunch of unit tests, if the code requirements change and you recode the logic, then the unit tests need to be redone. However, using OCP, because you don't change the original class, there is no need to redo existing tests. Instead, create a new class (which inherits from the old class) and therefore, you only need to create a new unit test of the new class.

Polymorphic: instead of Meyer method, create an abstract base class or an Interface and build new implementations as needed and plug in.

How to get it to work with abstract classes (AC) or interface? Since you are not inheriting, you have to really know what your AC or interface is supposed to be doing.

Both Meyer and Polymorphic hold that the original class should not need to be modified (unless there is a bug) to implement changes or to extend the original requirements.

BENEFIT: you don't change code once it works. Then you don't break code that is working.

Liskov Principle (about 29 min)

c# try and catch

DO NOT DO THIS. If an exception is thrown in CallMethod() and it gets bubbled up to this try/catch, you must use “throw;” to rethrow the exception. “throw;” will preserve the stack trace while “throw ex;” will make it look like the exception originated here. This can cause much confusion when trying to debug exception statements.

try

{

    CallMethod();                         

}

catch (Exception ex)

{

    SMXLog.LogException(ex);

    throw ex;

}

 If all that is happening in the catch block is a re-throw, then you do not need this Try/Catch at all. The try/catch is redundant and does nothing extra. In the above example, it is ok to use a try/catch with “throw;” because the catch block is Logging (doing something).

try

{

   CallMethod();                      

}

catch (Exception ex)

{

    // If the only thing being done in the Catch block is a re-throw,

    // then the entire try/catch block is redundant/not needed.

    throw;  

}

     https://stackoverflow.com/questions/881473/why-catch-and-rethrow-an-exception-in-c (good overview)

http://stackoverflow.com/questions/22623/throwing-exceptions-best-practices

using just "throw" will only bubble up a message that an exception occurred at the "throw" line rather than the actual line where exception occurred.

using "throw new exception" will preserve the stack trace with exact line of fault. but need to use parameters that allow the details to bubble up.

both examples work. first is if you want to include some extra detail but not necessary as each displays a very detailed message.