How To Improve Object Oriented Programming Skill Beyond Basics

Most software developers join industry after undergrad in CS. The Object Oriented Programming course we study in early BS semester covers only basics of Object Oriented Design. I had good luck to study Design Patterns in MS and other relates stuff by self study.

The good thing is, there is nothing difficult of rocket science. If we just have some basic guidelines, we can explore things by our own.


Here I would share very brief outline how we can switch our object oriented design skill to next level.

Level - I: Object Oriented Programming Concepts

Here comes the basics. We should study basic object oriented concepts. These are mostly covered in OOP course of undergrad level. Basic concepts, one must be familiar with at this level includes:

1. Association
2. Composition
3. Aggregation
4. Inheritance
5. Polymorphism
6. Encapsulation
7. Abstraction
8. Generalization
9. Overloading
10. Overriding

Level - 2: Object Oriented Design (Patterns)

There are some scenarios we frequently encounter during object oriented software design. Luckily, we are not alone in facing such cases. So for particular set of cases, there are some skeleton object oriented design guidelines already developed by experienced developers and researchers. Once we understand these skeleton designs, we can identify the cases where we need them.

These set of solutions are called Design Patterns. Design Patterns are just guideline how we should use our Level 1 knowledge to solve some real problems (I will cover different design patterns in coming posts). Here I only list a few (you can study further on Google) e.g. Singleton, Composite, Proxy, Strategy, ... you can see full list here. Here my objective is not to discuss each in detail, but only identify what we must learn at this level.

Level-3: Object Oriented Design (Principles)

If you are conformable with Level 1 and Level 2, you would surely be able to read any literature about software design or architecture. Principles can be think of as guidelines to create better object oriented design. Level 2 were cook book solutions for particular set of problems or use cases. But principles are not solution to some problems, they just remind you some issues that you may encounter in your object oriented design.

For example, of you mistakenly added some non related attributed in a class, you can still write a class and use it using Level 1 knowledge. But principles will help you identify some issues that you may encounter in future if you added not related attribute in a class. or given multiple type of responsibility to single class. There are principles that operate at class design level, some helps to define better package cohesion, some principles help to develop loosely coupled packages. Here is the listing:

Principles for class design: 

1. Open Closed Principle
2. Liskov Substitution Principle
3. Single Responsibility Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle

Principles to make cohesive packages include:

1. Reuse Release Equivalence Principle
2. Common Closure Principle
3. Common Reuse Principle

Principles for loose package coupling:

1. Acyclic Dependencies Principle
2. Stable Dependencies Principle
3. Stable Abstraction Principle

Level - 4: Domain Specific Patterns

If you are up with Level 3, you are almost black belt. There are further solution for particular set of domains or programming areas. Learning things of Level 4 depends in which area of software design or development you are working. For example of you write common database backed websites using non multi threaded code, there is no much benefit of learning Concurrency Patterns and Enterprise Integration Patterns. See some lists of EIP here. The patterns to use for multi threaded programming are called concurrency patterns. You only need to be familiar with them if you are writing multi threaded applications.

This is level where things starts getting cross layer, some are really about object oriented design and others may fall under general software design. I am not discussing a particular set, but only pointing you that this level exist. And you will rarely encounter it in day-to-day software development.


So its was the overview, of different levels of Object Oriented Design knowledge. The myself created these "Levels", to elaborate object oriented design knowledge with increasing level of difficulty. I will keep sharing different related examples in coming posts. Your feedback is always highly appreciated !