OOPS Principles (SOLID Principles)

Explains about each OOPS Principles (SOLID Principles) in detail. It has sample demos for each principle in detail i.e. Single Responsibility Principle, Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle.

C# (85.5 KB)
 
 
 
 
 
(33)
13,401 times
Add to favorites
4/30/2013
E-mail Twitter del.icio.us Digg Facebook
Sign in to ask a question


  • Good Article Gopal
    1 Posts | Last post November 28, 2012
    • First i am very thankful for your article it clears more doubts on Ioc/DI Pattern but i want more idea on SOLID for using it in WebApi and Webapplications and How we use single object interaction in Unit test application?
      
      Please help on these Doubts.
      
      Thank you,
      Pavan.
  • Can you just create a sample for interface in c#
    3 Posts | Last post October 30, 2012
    • Can you just create a sample for an interface in c#. I searched in internet and doesnt find any useful application in interfaces.
    • Sure Amal, I can do that. What sample do you want?
      About explaining what is interface or using it ? let me know if any specific sample you are looking at, so that I can write that and help you out.
      
      Thank you,
      
      Regards,
      Srigopal
    • How to implement an interface in wpf application , and what are its advantages .I am confused to use the iterfaces , abstract classes and override methods.
      If you get time please create an application explaining about the interfaces, abstract classes , overriding .
      
      waiting for your sample.
      
  • Unsure about D
    2 Posts | Last post October 04, 2012
    • I’m new to SOLID and I really enjoyed your article Srigopal.
      
      My C# is a little rusty however, in part D, I'm pretty sure that your example source doesn't match the EmployeeWriter class that you talked about in your solution. :) I'm with Stefano on this and am very curious to see how an expert on a budget would code the EmployeeWriter class for XML that doesn’t fall down in terms of coupling and cohesion with the Employee Class.  
      
      Are SOLID and its SRP more important than the old school guidelines of loose coupling and high cohesion?  Why is it important to separate something like the toXML method?  In my mind, toXML will have more dependencies to the employee class then a writer class.  
      
      From my understanding of SOLID, a massive rendering engine would need to build in order to save hierarchical data like XML.   Microsoft's ASP.net server controls and its render method is real world example of what I’m thinking of.  I can’t see how many projects can afford to build something like that each time. Help!
      
      http://msdn.microsoft.com/en-us/library/system.web.ui.control.render.aspx
      
      Thanks,
      
      Jason
      
    • Hi Jason,
      First thank you for your positive feedback.
      
      Next 
      Are SOLID and its SRP more important than the old school guidelines of loose coupling and high cohesion?  Why is it important to separate something like the toXML method?  
      
      Ans: In many place by knowingly or unknowingly we will be violating this principle. As long as it wont impact more in maintenance. 
      E.g. ToString() method in CLR, or DataSet.ReadXML or DataSet.WriteXML() methods.
      
      In my mind, ToXML will have more dependencies to the employee class then a writer class. 
      Ans: As you mentioned if ToXML has more dependencies then I would recommend write subclass or in the same class implement that ToXML() method, so that Employee object will be taken care of writing to XML too as a SRP.  
      
      Otherwise If we want to strictly follow SRP then we can write separate generic class and methods by using reflection or use Unity or MEF by following Dependency Injection.
      
      I recommend you to read these articles (I am sill updating them) to get clear idea how to follow SRP in the above mentioned scenario.
       
      http://code.msdn.microsoft.com/Dependency-Injection-with-5702acaf
      http://code.msdn.microsoft.com/Dependency-Injection-with-d9222c2f
      
  • Good Job.
    2 Posts | Last post September 28, 2012
  • Nict Article & Nice Samples
    3 Posts | Last post September 23, 2012
    • Good article with nice examples gopal.
    • really this is good.
    • Thank you Pranathi & Arif.
  • Writer of complex objects
    3 Posts | Last post September 23, 2012
    • Hi Srigopal
      good article and clear explanation.
      
      I have a question for you: say you have some objects that have a complex internal structure. This can be the case of a Order object that contains a collection of OrderItem, and each OrderItem is linked to a Product, and the Order is associated to a Customer.
      
      Writing an XML representation of the Order object may be dunting in one single writer. Assume the XML would look like this one:
      <order>
         <customer id="USR1001">
            <firstname>John</firstname>
            <lastname>Smith</lastname>
         </customer>
         <shipping>   </shipping>
         <invoicing>   </invoicing>
         <price>   </price>
         <items>
            <item id="PRD001">
               <descr>Nokia Lumia 920</descr>
               <quantity>1</quantity>
               <price>300</price>
               <currency>USD</currency>
            </item>
         </items>
      </order>
      
      You get the idea: each node is a representation of a complex object with several properties.
      
      How would you approach the development of the Xml writer for such object?
      
    • I see two ways of doing this:
      
      1) Each object has its own internal Xml representation (for instance by overriding the ToString() method, or introducing a new ToXml() method).
      In this way, each object is responsible for its own representation, and the writer would only have to navigate the object structure and invoke the ToXml() method to obtain the full Xml node of the object. The writer would know in which place this single node should fit in the overall Xml document.
      Disadvantage of this approach is that the object is also responsible for its own representation.
      
      2) The writer has close knowledge of all the objects and builds the overall Xml document object by object. The representation of each object is then responsibility of the writer only. Immediate thought to this approach is that the write method would really be long, to account for each possible type of object that is included in the Xml document. Also, there is a strong dependency between the writer and the object: if the object changes its properties, the writer would not work any longer. In the first example, the writer is not aware of any property of the object, it just get their Xml representation, so any change to properties would require an update of the internal ToXml() method of the object without breaking the writer. Makes sense?
      
      What's your view on this?
      
      Thanks
      
    • Sorry for the delay reply Stefano.
      Really a good question to think and discuss. 
      Your both options are doable, 
      I would suggest to follow SRP for implementing each, Order , Customer and derive them to XML writer or String writer classes and then implement necessary logic in the respective classes. 
      Let me know your view on this?
      
      Thank you,