Showing posts with label Design Pattern. Show all posts
Showing posts with label Design Pattern. Show all posts

Dependency Injection Principal (DIP)

Dependency injection Principal ensures it should be more and perfect abstraction between base level & derived level implementation. Dependency inversion principle is to decouple application glue code from application logic. Reusing low-level components (application logic) becomes easier and maintainability is increased.        

 The below example is all about Project management in normal it field. Based on requirement we will add junior developers and senior developers.Here the manager manage only one junior developer & one senior developer .In future s/he needs to add one more junior then it is easy to create a new collection of developers with IEngineer.
/// <summary>
    /// Interface for Developer people
    /// </summary>
    public interface IEngineer
    {
        void Dowork();
    }
    /// <summary>
    /// Interface for Mentoring people
    /// </summary>
    public interface IMentor
    {
        void DoMentoring();
    }
 
    /// <summary>
    /// Class implementing Developer qualities
    /// </summary>
    public class SoftwareEngineer : IEngineer
    {
        public string Name { get; set; }
 
        public void Dowork()
        {
            Console.WriteLine(Name + " Doing Coding....");
        }
    }
    /// <summary>
    /// Class implementing Developer & Mentor Qualities
    /// </summary>
    public class SeniorSoftwareEngineer : IEngineer, IMentor
    {
        public string Name { get; set; }
 
        public void DoMentoring()
        {
            Console.WriteLine(Name +  " Mentoring Juniors...");
        }
 
        public void Dowork()
        {
            Console.WriteLine(Name +  " Doing Coding....");
        }
    }
    /// <summary>
    /// Manager class for Managing .With the implementation of Developers & Mentors
    /// </summary>
    public class Manager
    {
        IEngineer Developers;
        IMentor Mentors;
 
        public void SetWorker(IEngineer developer)
        {
            Developers = developer;
        }
 
        public void SetMenter(IMentor mentor)
        {
            Mentors = mentor;
        }
 
        public void Manage()
        {
            if(Developers !=null)
            Developers.Dowork();
 
            if(Mentors !=null)
            Mentors.DoMentoring();
        }
    }
 
Call
Manager manager = new Manager();
SoftwareEngineer Sharan = new SoftwareEngineer { Name = "Sharan" };
SeniorSoftwareEngineer Jannet = new SeniorSoftwareEngineer { Name = "Jannet" };
 
            manager.SetWorker(Sharan);
            manager.Manage();
 
            manager.SetWorker(Jannet);
            manager.SetMenter(Jannet);
            manager.Manage();
 
dd                                                                                            

Interface segregation Principal (ISP)

ISP States that no client should be forced to depend on methods it does not use. ISP is one of the five SOLID principles of Object-Oriented Design.

The below example i have create Imamals interface for Mamal features. Interface is having two features like canfeed, canSpeek . But CanSpeek in only applicable for Human . It is not required for Tiger Object. 

/// <summary>
    /// Mamal Features implemneted for Human
    /// </summary>
    public class Human : IMamals
    {
        public void CanFeed()
        {
            Console.WriteLine("Human Can Feed..");
        }
 
        public void CanSpeek()
        {
            Console.WriteLine("Human Can Speek..");
        }
    }
    /// <summary>
    /// Mamal Features implemneted for Tiger
    /// </summary>
    public class Tiger : IMamals
    {
        public void CanFeed()
        {
            Console.WriteLine("Tiger Can Feed..");
        }
 
        public void CanSpeek()
        {
            throw new NotImplementedException();
        }
    }
 
Human human = new Human();
            human.CanFeed();
            human.CanSpeek();
 
            Tiger tiger = new Tiger();
            tiger.CanFeed();
     tiger.CanSpeek();
ISP Implementation
 
We have already know the CanSpeek implementation in the ABOVE example. Here we split the Interface in two, one is for Common and another for Specific.
/// <summary>
    /// Interface For common
    /// </summary>
    public interface IMamalsCommon
    {
        void CanFeed();
      
    }
    /// <summary>
    /// Interface for Specific
    /// </summary>
    public interface IMamalsSpecific
    {
        void CanSpeek();
    }
 
 
    /// <summary>
    /// Mamal Features implemneted for Human
    /// </summary>
    public class Human : IMamalsCommon,IMamalsSpecific
    {
        public void CanFeed()
        {
            Console.WriteLine("Human Can Feed..");
        }
 
        public void CanSpeek()
        {
            Console.WriteLine("Human Can Speek..");
        }
    }
    /// <summary>
    /// Mamal Features implemneted for Tiger
    /// </summary>
    public class Tiger : IMamalsCommon
    {
        public void CanFeed()
        {
            Console.WriteLine("Tiger Can Feed..");
        }
 
    }
.
Human human = new Human();
            human.CanFeed();
            human.CanSpeek();
 
            Tiger tiger = new Tiger();
            tiger.CanFeed();
 
When an interface is implemented for a wide responsibility of members then there will be chance where some clients may have to implement members, which they don’t even use.

 

Liskov substitution Principle (LSP)

This rule of design pattern assure that if a class derived from base class then base class should be a proper substitute for derived class.

“The derived classes should be perfectly substitutable for their base classes”.
In the below example “Jeep” Class object is representing “Trucker” Object. AS per LSP principle it should be wrong.

/// <summary>
    /// Jeep Class
    /// </summary>
    public class Jeep
    {
        public virtual int Speed()
        {
            return 60;
        }
    }
    /// <summary>
    /// Truck Class inherit
    /// </summary>
    public class Trucker : Jeep
    {
        public override int Speed()
        {
            return 55;
        }
    }
 
 
Jeep jep = new Trucker();
            Console.WriteLine(jep.Speed().ToString()); 

Implementation of “Liskov substitution Principle”
                We must make sure that the new derived classes just extend without replacing the functionality of old classes. Otherwise the new classes can produce undesired effects when they are used in existing program modules.

/// <summary>
    /// Abstract  class for vechile
    /// </summary>
    public abstract class Vechile
    {
        public abstract int Speed();
    }
   
    /// <summary>
    /// Jeep Class
    /// </summary>
    public class Jeep : Vechile
    {
        public override int Speed()
        {
            return 60;
        }
    }
    /// <summary>
    /// Truck Class inherit
    /// </summary>
    public class Trucker : Jeep
    {
        public override int Speed()
        {
            return 55;
        }
    } 

I have implement new abstract class for Vehicle & it is derived for all classes. Ie “Jeep” derived from “Vehicle” and “trucker” derived from “Jeep”. But we can represent Both “Jeep” & “Trucker” object using “Vechile” object.
     Vechile vehicle = new Jeep();
            Console.WriteLine(vehicle.Speed().ToString());
            vehicle = new Trucker();
            Console.WriteLine(vehicle.Speed().ToString());