OOPS-DEFINITION

1 Class This is a programmer-defined datatype, which includes local functions as well as local data. You can think of a class as a template for making many instances of the same kind (or class) of object.
2 Object An individual instance of the data structure defined by a class. You define a class once and then make many objects that belong to it. Objects are also known as instance.
3 Member Variable These are the variables defined inside a class. This data will be invisible to the outside of the class and can be accessed via member functions. These variables are called attribute of the object once an object is created.
4 Member function These are the function defined inside a class and are used to access object data.
5 Inheritance When a class is defined by inheriting existing function of a parent class then it is called inheritance. Here child class will inherit all or few member functions and variables of a parent class.
6 Parent class A class that is inherited from by another class. This is also called a base class or super class.
7 Child Class A class that inherits from another class. This is also called a subclass or derived class.
8 Polymorphism This is an object oriented concept where same function can be used for different purposes. For example function name will remain same but it make take different number of arguments and can do different task.
9 Overloading A type of polymorphism in which some or all of operators have different implementations depending on the types of their arguments. Similarly functions can also be overloaded with different implementation.
10 Data Abstraction Any representation of data in which the implementation details are hidden (abstracted).
11 Encapsulation Refers to a concept where we encapsulate all the data and member functions together to form an object.
12 Constructor Refers to a concept where we encapsulate all the data and member functions together to form an object.
13 Destructors refers to a special type of function which will be called automatically whenever an object is deleted or goes out of scope.
14 Function Overriding Function definitions in child classes override definitions with the same name in parent classes. In a child class, we can modify the definition of a function inherited from parent class.
15 Public Members Unless you specify otherwise, properties and methods of a class are public. That is to say, they may be accessed in three possible situations:
1. From outside the class in which it is declared,
2. From within the class in which it is declared,
3. From within another class that implements the class in which it is declared.

Till now we have seen all members as public members. If you wish to limit the accessibility of the members of a class then you define class members as private or protected.

16 Private members By designating a member private, you limit its accessibility to the class in which it is declared. The private member cannot be referred to from classes that inherit the class in which it is declared and cannot be accessed from outside the class.
17 Protected members A protected property or method is accessible in the class in which it is declared, as well as in classes that extend that class. Protected members are not available outside of those two kinds of classes. A class member can be made protected by using protected keyword infront of the member.
18 Abstract Classes An abstract class is one that cannot be instantiated, only inherited. You declare an abstract class with the keyword abstract, like this: When inheriting from an abstract class, all methods marked abstract in the parent's class declaration must be defined by the child; additionally, these methods must be defined with the same visibillity.
19 Interfaces Interfaces are defined to provide a common function names to the implementors. Different implementors can implement those interfaces according to theri requirements. You can say, interfaces are skeltons which are implemented by developers.
20 Constants A constant is somewhat like a variable, in that it holds a value, but is really more like a function because a constant is immutable. Once you declare a constant, it does not change.
21   Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.
22   Designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
23   If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.
24   If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.
25   The main reasoning behind the preference for abstract base classes is versioning, because you can always add a new virtual member to an abstract base class without breaking existing clients. That's not possible with interfaces.
     
  As a first rule of thumb, I prefer abstract classes over interfaces, based on the .NET Design Guidelines. The reasoning applies much wider than .NET, but is better explained in the book Framework Design Guidelines.
  The main reasoning behind the preference for abstract base classes is versioning, because you can always add a new virtual member to an abstract base class without breaking existing clients. That's not possible with interfaces.
  There are scenarios where an interface is still the correct choice (particularly when you don't care about versioning), but being aware of the advantages and disadvantages enables you to make the correct decision.
  So as a partial answer before I continue: Having both an interface and a base class only makes sense if you decide to code against an interface in the first place. If you allow an interface, you must code against that interface only, since otherwise you would be violating the Liskov Substitution Principle. In other words, even if you provide a base class that implements the interface, you cannot let your code consume that base class.
  If you decide to code against a base class, having an interface makes no sense.
  If you decide to code against an interface, having a base class that provides default functionality is optional. It is not necessary, but may speed up things for implementers, so you can provide one as a courtesy.
  An example that springs to mind is in ASP.NET MVC. The request pipeline works on IController, but there's a Controller base class that you typically use to implement behavior.
  Final answer: If using an abstract base class, use only that. If using an interface, a base class is an optional courtesy to implementers.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>