Learn advanced programming using OOP and Design Patterns

What this blog is about

See the diagram below for a quick overview.

Figure 1 What this blog is about

This blog is for readers who are interested in learning good programming technique. To learn basic programming, please refer to other websites. Here we assume that you already know the syntax and semantics of the language.

We will start with the java programming language. Then we will also cover Ruby, Scala and Groovy. Only 4 languages are planned now, but we may add more, later.

You will walk through a working example of a program. The program will ultimately have all features that can be listed as good OOP principles and will use the GOF design patterns, where appropriate. The initial version of the program will have quality issues. These issues will be resolved and the programming style improved, as we advance in our journey.

Good Programming

So what is good programming? Like in all other things in life, good and bad are relative; we have to learn to discern them. Of course bad programming is easy to recognizeJ. But good programming is not always so easy to recognize or learn. Hopefully this blog will help you in your journey.

Let us take an example which can show us why good programming can be fuzzy to define: Suppose you see a program that conforms to the SOLID object oriented programming principles and implements the relevant Design Patterns. All the code reviewers are happy and they gave the go ahead. There are enough test cases and they all pass. But what if the program is relatively slow and runs at 50% of the required performance?

We can never deploy such a program in production. All the goodness that has been incorporated in the code has academic value only. Now what? There is no need to throw away the code. We have to refactor the code to improve its performance. Poor performance is normally due to poor usage of data structures, inefficient memory utilization and slow algorithms.

Technical debt

In this context, I would like to introduce another term: Technical debt. Debt is when we owe something to someone. The problem with debt is that it tends to pile up over time. And then, the whole is bigger than the parts L. Technical debt refers to the weaknesses(big or small) that we intentionally or unintentionally insert into our code. These weaknesses get into our code due to project pressures or our lack of knowledge. Writing bad code helps us finish things faster. But it is a short term saving of time. In the longer term, such weakness(or debt) takes much longer to fix than the original time we save. Thus by saving some time now, using technical debt, we are borrowing a lot from those who will be maintaining this code later. Most probably when such debt “comes out”, it has been long enough in production, and it is someone else who is maintaining the code. They will take much longer to identify weakness inserted by the original developer. Thus in the long run, technical debt imposes heavy costs on the project owner.

Figure 2 Technical Debt: Borrowing from the future

In this blog, we will try to identify technical debt in our code, and improve upon it.

Presentation style: Conversing student and teacher

This blog is in the form of a conversation. Those who do not want to look at the conversation can see the code at github

directly. But I encourage you to read the conversation. Reading the conversation makes learning much easier. Laziness to read is one of the main causes of technical debt. I have seen this from my experience of reviewing code.

The conversation is between two individuals: the student and the teacher. The traditional way to teach is that the teacher dishes out knowledge and the student eagerly takes it in. But such a teacher-teaches-and-student-learns style gets boring after some time. So I have taken a different approach: the role of the teacher and the student are exchanged throughout the conversation. The teacher doesn’t know everything, as is normally the case. When such a situation arises, the teacher starts asking questions to the student. The student now has to find answers and “teach the teacher”J.

Figure 3 Exchanging the roles of student and teacher

Source code

TBD

References

  1. Object Oriented Programming
    1. Wikipedia
    2. Webopedia
    3. OOP with Java from Oracle
    4. Conceptual explanation of objects and classes by Thomas De Leon
  2. The principles for class design and package design
    1. Article by Robert C Martin
    2. Article by Al-Farooque Shubho
  3. The Gang of Four Design patterns
    1. Non-software examples. Very good for beginners and as a reference.
    2. Wikipedia: History of the Design patterns, their names and short descriptions
    3. BlackWasp: Listing of the design patterns and longer descriptions
    4. dofactory: Has the UML diagrams for each design pattern
  4. Technical Debt
    1. On wikipedia
    2. Article by Martin Fowler
    3. A real life story, by Jon Evans
  5. Programming languages
    1. Java
    2. Ruby
      1. From ruby-lang.org
      2. From tutorialspoint
      3. Example based tutorial from rubylearning.com
    3. Scala
      1. From scala-lang.org
      2. From tutorialspoint.com
    4. Groovy
      1. From codehaus.org
      2. Learn by fixing groovy unit test cases at groovykoans.org
  6. Refactoring
    1. Article by Martin Fowler
  7. The Game of Life cellular automation
    1. The explanation of the game at: Wikipedia
    2. Working implementation with java source code at bitstorm
    3. At math.com
    4. Another implementation in java, by Bragadeesh

2 thoughts on “Learn advanced programming using OOP and Design Patterns

  1. It is quite valuable to know about ‘Technical Debt’ , You have named very rightly about the dept. Every developer in the current IT industry needs it this article. Looking forward to see your conversation based explanation.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s