Object Oriented Programming for Structured Programmers - conversion training
Archive - Originally posted on "The Horse's Mouth" - 2010-12-14 15:09:15 - Graham EllisI've been programming for many years; I started off with languages like Fortran and quickly learned that it's a good idea to split the code into named chunks - which were known as FUNCTIONs and SUBROUTINEs. This means that parts of a program can be tested named chunk by named chunk, that chunks can be re-used, and can be shared between programs. And that's a good system for medium sized programs, but as they grow further (especially where a program has to cope with numerous similar data types), it begins to creak a bit, with lots of "if, elseif, elseif, elseif, else" type structures and large numbers of named blocks of code with similar names that will find the capacity of ... a sphere, a cube, a jug, a cup ... and woe betide you if you call the wrong named block of code in the wrong circumstances.
Of course, us "old programmers" are very much aware of these issues, and we design and code defensively to deal with them. But - for the larger programs, and for programs that handle lots of similar data types - there is a better approach. And that's Object Oriented programming. But it's a big step from "structured coding" to "Object Oriented Programming" and for the old hacks it means stepping back to school and learning new techniques. And the introduction to the new world of OO isn't helped by the most enormous heap of new jargon that's been introduced with it to represent some of the concepts and implementation elements.
One of the most rewarding single-day courses that we give is Object Oriented Programming in PHP course - and it's so rewarding because we help some very smart and very experienced programmers make the crossing from structured coding to OO coding - something that many of them have struggled with for a very long time. Having - at one time - been a pure structured programmer myself, I have "been there" and I have "worn the T Shirt" so I know exactly the issues that need to be addressed, and we address them without initial reference to all the jargon that accompanies OO. After the initial session, we'll say "this is a class ... this is an object" so that delegates do leave with a good appreciation of the new lingo - but they've had it gently introduced to them, not rammed down their throats from the start.
Object Orientation is applicable in many languages these days. So when I got a request "can you help me pick up the principles of OO" general terms, I jumped at the opportunity. I chose Python as my main language of demonstration; experienced programmers can pick up the basics of variable, conditionals and loops very quickly, and the OO demonstrattions during the day can be neatly written in just one or two files (in contrast to the much higher number I would have used in a language such as C++)
Outcome of day? A great success!
Demonstrations from the day
... two types of thing and a list that contains a mixture of them ... [source]
... two types again, but this time sharing a whole lot of common logic rather than having it repeated ... [source]
... how to compare two things - which is 'greater'? ... [source]
... comparing whole lists of things - which is 'greatest'? ... [source]
I was also asked to write a program using the structured idiom [in Python] and convert it to an object oriented idiom. I kinda refused - it's NOT a question of converting, but of starting from the beginning, and designing the application differently. But I did let myself write the code twice - once each way.
The data is [here] - it's railway stock on the British network, with diesel and electrical multiple units each listed carriage by carriage, individual locomotive hauled carriages listed one per line, and coaches for high speed trains done in the same way. Then there are some 'specials' - the flywheel powered cars on the Stourbridge Town line, and the Isle of Wight trains, which don't quite conform to standard rules. ((I do have the complete file if you come on the course - ALL the stock - but can't publish it here because of copyright issues!))
... the sample codes, structured ... [source]
... sample code, using an OO approach ... [source]
Object Oriented princiles REALLY need to be taught ... the examples above may show you a little, but you will learn 50 times more if you let me show you how these examples are written - the logic behind the logic. Please get in touch via our [help page] and we can set up a one-on-one day (for just a regular course price!) or come out on site if there's a large group of you. The language I'll use won't necessarily be Python - if you know Perl already, we'll use that; for C programmers, we'll look at OO via C++, and so on.
Outline of the day
Prerequisites (which can be covered in an extra 90 minute session the previous evening for experienced programmers in other languages):
To know a little about in the target language ...
variables
calculations
conditionals
loops
functions (definition and use)
Input and output
How to add comments to a program
How to run a program
On the day:
"Single Block, Structured, Object Oriented"
Then ... an explanation of OO, and of how you do a job in an OO way. The tutor will NOT start by using all these words that are part of the OO Jargon, but by the end of the day you'll see where each of them fits in.
Class, Object, Method
Constructor, Destructor
Properties or Attributes
Static and Dynamic
Muttable and Immutable
Associated Objects
Inheritanace
Subclasses, Base classes and Extended Classes
Overloading and overriding; Polymorphism
Overloading Operators
Public, Protected, Package, Private
Multiple Inheritance, Interfaces and Mixins
Transient and Serialisation
Exceptions
The demonstration will be done by taking some example data, and handling it using the approach of Object Orientation. A second demonstration will use a signifcant file of real data, showing the delegates how the principles demonstrated earlier make for real gains as the data volume and complexity increases, but you do not want to program to have a similar increase in its complexity.
Philosophy of OO Design
Design Patterns
Singleton Pattern
Factory Methods
Unified Modelling Language
Extreme Programming
What makes a programming language OO?
Things from some other code that should not happen in OO:
"What is this"
Switch
Direct access
Wrong sort of operation / wrong sort of data
Repeated code
Cardinal Values