Tuesday, December 22, 2009

Object Oriented Concepts Every Dummy Must Know

Abstraction

Abstraction is Only showing what is necessary and encapsulating (hiding) unnecessary parts.

If you take a car you interact with it using abstractions

you use gas pedal, steering wheel which hides internal details

It is keeping a clear separation between abstract properties of a data type and the concrete details of its implementation.
It is not presenting the details but only show the parts which are necessary.
Hiding implementation

To abstract properties we can use private modifier. Abstraction is hiding implementation details using abstract classes and interfaces.

http://stackoverflow.com/questions/2918308/explaining-abstraction-to-a-non-programmer

http://stackoverflow.com/questions/16938667/how-abstraction-and-encapsulation-differ

http://www.introprogramming.info/english-intro-csharp-book/read-online/chapter-20-object-oriented-programming-principles/#_Toc362296567

Encapsulation :

Hiding state/data. Information hiding mechanism
It is the opposite of Abstraction.

http://stackoverflow.com/questions/24626/abstraction-vs-information-hiding-vs-encapsulation
https://www.google.com/search?q=encapsulation+vs+abstraction&ie=utf-8&oe=utf-8
http://stackoverflow.com/questions/742341/difference-between-abstraction-and-encapsulation

Composition : Combining simple types to make a complex type (Car composed of Wheels, Body etc.). An object of a composite type "has an" object of a simple type.

http://en.wikipedia.org/wiki/Object_composition

Aggregation : (See composition vs aggregation - adobe)

Is a form of object composition.

https://atomicobject.com/resources/oo-programming/object-oriented-aggregation

Inheritance : When an object or class based on another object or class.

Inheritance is "is a" relationship while, composition is "has a" relationship

Articles

https://mydevelopedworld.wordpress.com/2012/07/25/object-oriented-programming-inheritance-vs-composition/

inheritance defined statically at compile time.
object composition defined dynamically at run time, through objects acquiring references to other objects
inheritance : reuse by subclassing : white box reuse (internals of parent are visible)
composition : well defined interfaces: black box reuse (no internal objects are visible)

updated: 2014

SOLID Principles

SOLID is acronym used for 5 design principles for object oriented programming. Below we'll look at what they are

Single Responsibility principle

Every class should have only one responsibility. This responsibility should be totally encapsulated by the class.

see wikipedia, this, OODesign, not so SOLID OO Principles.

Open/Closed principle

Software entities should be open for extension, but closed for modification. This is valuable when it comes to production environments where changes to existing code may require code reviews, unit tests etc. which ensures the quality of the product. In design, inheritance is used to achieve open/closed principle.

see wikipedia, OODesign, Objectmentor,

Liskov Substitution principle

Derived types must be completely substitutable for their base types.

see OODesign,

Interface segregation principle

Client should not be forced to depend upon interfaces that they don't use

Dependency Inversion principle

High-level modules should not depend on low-level modules.

Exception handling basics

Exceptions happens when a member cannot successfully do what it's designed to do. Exceptions can be generated by CLR, 3rd party library or by user code using throw keyword.

A catch block can specify type of exception to catch. This is called exception filter. The exception type should derive from Exception. In general do not specify Exception as the exception filter.

Inside the catch block you can either return a value or throw an exception depending on the situation you're in. (When to throw an exception). Difference between throw and throw ex.

A finally block enables you to clean up actions that are performed in try block. A finally block always runs, regardless of exception is happen. Note that sometimes finally block will throw exceptions as well.

Exceptions contains a property called StackTrace. It contains names of the methods in current call stack, together with file name and line number where exception was thrown for each method. You can use Environment.StackTrace to get stack trace information when no exception is being thrown.

Sometimes you shouldn't throw exceptions. See cost of exceptions and this (SO)

Some common exceptions in .NET

NotImplementedException (msdn)
See Why does NotImplementedException exists - SO

Handling business logic in exceptions
http://stackoverflow.com/questions/5378005/when-is-it-ok-to-use-exception-handling-for-business-logic
http://programmers.stackexchange.com/questions/15570/representing-business-rules-with-exceptions

Exceptions you should not throw (SO)
Since they doesn't give any meaningful information when writing your own code you should not throw,