Sample Object Orientated code

Why is learning to code these days so hard ?

If your just starting out trying to learn how to write application code it will not take you long before you hit one of the biggest walls and choices to be made, this being do you learn Procedural or OOP(Object Orientated) – programming. Having to make this choice however has not always been the case.

I can clearly remember the moment I first read about Object orientated programming it was in a 1990’s copy of the British magazine PC-WORLD, during one dinner time. I had finished making some lunch with a cup of tea and opened the articles page. After I had finished, I put cleaned the then empty cup closed the magazine and returned to my desk.

My first reaction to the initial concepts which had been very well outlined, was to dismiss this information as just another completely unnecessary addition to the core of application development. At the time there was a lots of so called programming aids – newly available , including GUI based development aids that just failed to work and cost a lot of time before being confined to a shelf.

Today in 2015 even though I have embraced Object Orientated coding a lot more than back then, I still have this overwhelming sense that as a whole its an unnatural method for a programmer to develop applications – here is why I feel this way.

Before OOP came into existence, today being included in many of the pre-exisitng, then followed by new programming Languages, Programming code I feel was more natural in its structure, its readability and in its design.

The main claimed difference between procedural code and OOP code relates not so much to the style of the code itself but to how you approach the design of your applications in the first place.

With Procedural based programming, it is claimed that the programmer is first thinking of the actions to be performed before relating them to the data, Actions first then moving onto the type of data needed to produce the required results.

Personally I don’t feel this is the case or ever was the case. Having taken main application specifications and design briefs – before the existence of OPP, the format of the required application data always came first. I worked with designed documents that detailed all the data and its needed format, followed by flow charts etc that detailed all the required actions to be performed in order and on these sets of data.

OOP design states that application design should start with the objects (Data, parameters and arguments – along with placing these features into classes that relate to like minded objects) involved in the application model being developed, only then moving to any actions (Methods! in OOP) to be performed with these elements.

So how to define what really is the main difference between the two coding concepts ?

Procedural programming

With procedural programming you define the data fields to be used in an application followed by the actions you need to perform on this data. Sometimes these actions will result in new data being created ( e.g. Invoice total along with a complete invoice and all its related fields ), this new data is included as a part of the applications initial design.

As its name suggests the flow of these actions is performed in a procedural path of direction, from top to bottom unless otherwise needed, divided into specific functions/Procedures. Core application data is passed between these functions with any data values stored in new resulting data fields, then retained or deleted as required.

With in this flow of actions some of the applications functions/procedures may be needed many times and thus repeated, other actions only being needed once and some actions may not be needed at all in some conditions.

The program code in procedural programming is usually very self contained in that, if you print the code out you would be able to follow the flow of the program depending on defined conditions that can be clearly observed with-in the listing of the code.

Object orientated programming

let’s define a few OOP head spinning terms. The most basic set of vocabulary for OOP is a class, an object, a property, a method, and a parameter. One of the key concepts for OOP is inheritance.

A class is a set of functions that work together to accomplish a task. It can contain or manipulate data, but it usually does so according to a pattern rather than a specific implementation. An instance of a class is considered an object.

An object receives all of the characteristics of a class, including all of its default data and any actions that can be performed by its functions. The object is for use with specific data or to accomplish particular tasks. To make a distinction between classes and objects, it might help to think of a class as the ability to do something and the object as the execution of that ability in a distinct setting.

A method simply refers to a function that is encased in a class.

A parameter is a variable that is passed into a function that instructs it how to act or gives it information to process. Parameters are also sometimes called arguments.

A property is a default set of data stored in a class. A class can have multiple properties and the properties can be changed dynamically through the methods of the class.

Inheritance is one of the keys that make OOP tick. Simply put, classes can inherit methods and properties from other classes by extending them and each class can be
extended by multiple classes. This means that you can start with a base (or parent) class that contains shared characteristics among several classes. That base class can then be extended by other classes (children) that are similar but are meant for slightly different purposes. Any changes in the parent class will automatically cascade to its children.

In many conditions its much harder to read OOP code directly, it is much more like reading someones essay with references to many other books that need to be called upon in order to understand what in full the essay is saying.

Well honestly !!! even for someone who has coded for many years, just reading about OOP concepts is enough to drive you demented with in minutes of starting. Mostly sounding like a dragon consuming its own tail with fire !

When you take into account that OOP was designed to make coding easier, just getting your head around the initial concepts is bad enough.

Having coded for some years before all programmers had to embrace the jump to (Philosophy, Sorry OOP!!!) not just coding! it all feels a step to far.

I will not go into any more OOP details yet in this post anyway !, as I just wanted to outline the fundamental differences as above.

Final comments

What I will say however is that it is worth learning OOP, no matter how painful but you need to take the following into account, OOP coding is not in my belief natural, nor intuitive to us simple humans , it is not easy to document or read once finished, few development aids such as IDE’s can include full help in developing OOP code, while at the same time being perfect for Procedural code.

Yet you still need to learn how to work with OPP! URRRR!

It also needs to be noted that for many areas of coding such as shell scripting(BASH etc…) or Python scripting (not full programming!), OOP code not only has no relevance in many cases its just not possible.

Even after many years in existence you could ask if OOP methods and languages have done little more than add confusion and distraction when coding applications ?

For many it is still a dragon to be controlled. From my own point of view – this is because it is not a natural entity, as I don’t feel that we as humans approach task completion in the form of dividing tasks into (Objects, classes , methods, and Inheritance ), we just don’t!.

We see task as actions to be performed and then we start performing them, we intuitively see something to be completed and only then do we assembly to needed tools.

Can you imagine life , if every time we needed to do something, you viewed the task at hand in such a highly conceptual fashion as to divide it into methods relating to objects. If every time we asked someone to help use with something they spent the first ten minutes telling us how this action was a method that related to all the other objects they had performed these actions on ( Oh its ok , I can do this myself much faster – thank you anyway !!!! 🙂 ).

During life we have to hit many things, hammer other thing in and screw other things down but we do not stop to think how these actions/methods relate to all these objects placed into liked classes, we just get on with the task at hand.

These point however do not diminish the good sides of OOP, I will come to these in following posts and there are many good and great aspects!

I think the best path however is to forget the idea that OPP is there to help you develop easily and quickly , its not, its there to help applications fit into larger structures and wider systems than fast standalone applications.

I just want to finish by saying that OOP is only one option in writing good applications, it should be noted that you don’t have to use it at all – because if your application works, includes all the needed error handling , produces all the correct results well then its as good as it gets.

Another good reason however for learning OPP, is if you intend to work within a commercial setting, as most of the code you will be working with, both correcting or updating will most likely in 2015 be written using OPP methods, so its just one of them times you just have to jump even if the water below you is a little muddy !