1. What is OOPS ?

• It stands for Object Oriented Programming. It is a programming concept/design.
• Object-Oriented Programming (OOP) uses a different set of programming languages than the old procedural programming languages (C, Pascal, etc.).
• Everything in OOP is grouped as “objects”.

Example:
• Your “hand” is a class. Your body has two objects of type hand, named left hand and right hand.
• Their main functions are controlled/ managed by a set of electrical signals sent through your shoulders (through an interface). So the shoulder is an interface which your body uses to interact with your hands.
• The hand is being re-used to create the left hand and the right hand by slightly changing the properties of it.

2. What is a Class ?

• A class is a blueprint or a template that describe the details of an object.
• A class is the blueprint from which the individual objects are created.
• Class is composed of three things: a name, attributes, and operations.
Example:
public class Student
{
}

3. What is an Object ?

• An object can be considered as a “thing” that can perform a set of related activities.
• The set of activities that the object performs defines the object’s behavior.
• In pure OOP terms an object is an instance of a class.
Example:
• A student object will give you a name, address, date of birth etc..
• A studentResult object will give you a student’s grades, aggregrate marks, year of passing and so on…

4. What is Abstraction ?

Abstraction is a process of hiding unwanted details (or complexity) from the user.
Example 1 : Computer games also use this feature. The user only needs to know how to play the game, the complex working of the game is hidden from the user.
Example 2 : Let’s say you have a method “CalculateSalary” in your Employee class, which takes EmployeeId as parameter and returns the salary of the employee for the current month as an integer value. Now if someone wants to use that method. He does not need to care about how Employee object calculates the salary? An only thing he needs to be concern is name of the method, its input parameters and format of returned value.

4. What is Encapsulation ?

Encapsulation is the process of combining data and functions into a single unit called class.
In Encapsulation, data is not accessed directly; it is accessed through the functions present inside the class.
Encapsulation makes the concept of data hiding possible.
Encapsulation is the feature that provides security to the data and the methods of a class.

5. What are SOLID OOPS Principle ?

There are 5 principles that you must follow when designing a class, – SOLID
1. SRP – The Single Responsibility Principle
There should never be more than one reason for a class to change. A class should have one and only one responsibility.
If you have a class that has more than one reason to change, you need to split the class into multiple classes, based upon their responsibility.
This does not mean that you cannot have multiple methods in a single class, It means that methods in a class should be implemented with a single purpose.

2. OCP – The Open Closed Principle
Software entities (like classes, modules, functions etc….) should be open for extension but closed for modification.
Open for extension : The idea was that once completed, the implementation of a class could only be modified to correct errors; new or changed features would require a different class to be created. That class could reuse coding from the original class through inheritance. The derived subclass might or might not have the same interface as the original class.
Closed for Modification : The source code of such a module not be disturbed/touched/modified. The existing implementation is closed to modifications, and new implementations need not implement the existing interface.

3. LSP – The Liskov Substitution Principle
Sub types must be substitutable for their base types. If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T) without altering any of the desirable properties of that program
Example : Say, a KingFisher class extends a Bird base class and hence, it will inherits the Fly() method which is defined under the Birds class.
Ostrich is also a Bird (Definitely it is!) and hence it inherits the Bird class. Now, can it fly? No! Here the design violates the LSP. So, even if in real world this seems natural, in the class design, Ostrich should not inherit the Bird class and there should be a separate class for birds that can’t really fly and Ostrich should inherit that.

4. ISP – The Interface Segregation Principle
No client should be forced to depend on methods it does not use
The ISP says that once an interface has become too ‘fat’ it needs to be split into smaller and more specific interfaces so that any clients of the interface will only know about the methods that pertain to them.
For Example : IBird Interface have many bird behaviour defined along with the Fly() behaviour.Now, if a Bird class (Say, Ostrich) implements this interface, it has to implement the Fly() behaviour unnecessarily (Because, Ostrich doesn’t fly)

5. DIP – The Dependency Inversion Principle
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

6. What are Coupling and Cohesion ?

Cohesion refers to what a class (or module) will do.
Low cohesion means that the class does a variety of actions and is not focused on what it should do.
High cohesion means that the class is focused on what it should be doing, i.e. only methods relating to the intention of the class will be present here.
Example of Low Cohesion:
——————- | Staff | ——————
checkEmail()
sendEmail()
emailValidate()
PrintLetter()
Example of High Cohesion:
——————- | Staff | ——————-
-salary
-emailAddr
—————————-
setSalary(newSalary)
getSalary()
setEmailAddr(newEmail)
getEmailAddr()

Coupling, refers to how two classes (or modules) are related and how much dependent they are on each other.
Low coupling means that changing something major in one class should not affect the other.
High coupling would make your code difficult to change as well as to maintain it, as classes are coupled closely together, making a change in one class could affect another.
All good software design will go for high cohesion and low coupling.