Object Orientated Programming (OPP), classes and Artificial Intelligence (AI)
A couple of weeks ago I wrote an article that introduced the concepts of Object Orientated Programming (OOP); in the article I touched upon classes, but said that we would write another article to explain the concept, so here it is. This article is conceptual, aimed at explaining classes and not a technical article about how to write classes, as there are plenty of those already out therein the aether " see Introducing PHP Classes as one example " so here goes …
If you cut Ayrmer Software in half, you would find two fundamental values (sorry, hate that expression) that are unshakeable: the first is about making the other person more important; the second is about keeping things simple. The latter of the two is reflected in our tag line " making complex tasks simple " that’s also our corner stone of designing classes. They are the fundamental concept of Object Orientation Programming (OOP); designing reuseable blocks of code.
There are essentially two types of programming: procedural and object orientated. Procedural programming is a structured approach that uses routines (or procedures), where as object OOP is bases upon objects (or classes). OOP is fundamental to modern programming methodologies.
So, a class is an abstract object, to put it simply. But, what is an object; well it could be a door (oh dear me, there I go again with the door analogy), a car or something more abstract like an implementation of a business rule. Objects don’t have to be tangible, in-fact objects are often abstract by their very definition. Artificial Intelligence (AI) uses objects / classes to define behaviour or environments, although at the more complex end of the scale.
As software developers, we see the world as objects and I often find myself trying to define objects in day to day life; it’s a sort of mental game. The key to creating successful class, is to ensure that it encapsulates the simplest form of an object, enabling it to be adapted (extended or inherited) for other, similar objects. Using this approach, code can be reused time and time again and benefits from reduced debugging, as the code becomes more robust the more it is used. Having said that, you have to be careful to avoid things like this: Mutant Marsupials Take Up Arms Against Australian Air Force!
As I might have previous mentioned, I often use the door analogy, but was trying to come up with something different and thought about using a person, but the first article I found " Introducing PHP Classes " used exactly that and managed to introduce the predictable contrasts between men and woman. So, I have fallen back on an old favourite of mine, a vehicle.
So bare with me a second and think of what all vehicles have in common ……
… you come up with a list yet?
I asked my wife and she came up with the following list:
This is really interesting, because she has introduced the concept of properties, methods and events used to define an object. Instruments and perhaps energy (she initially said fuel), are properties, movement is a method and an event would be when the vehicle moves. Wheel is an interesting example as it could be itself an object (if we need to regress down to that level) or a property, I.e. the number of wheels the car has.
Let’s take another look at our vehicle
- Number of Wheels
- On Purchase
- When Starting
- When Moving
- When Stopping
- When FuelEmpty
- Requires Service
- Requires Repair
Hopefully you get the idea, but the point at this stage is to define the common factors your class is designed for and how it will be implemented. Get it right and your vehicle class could be extended to be a bicycle, family car, sports car, racing car or even a tank. All of these real world objects have things in common; at the very root of OOP is building re-useable code that can be used time and time again.
So, have another think about what you vehicle class would cater for and define what they all have in common. Oh and if you are writing beautiful code, you’ll comment it and add an explanation what objects can utilise your class.
Once you have defined your base class, you can extend or inherit it. So having created your vehicle class, you could create a new class called car that inherits your vehicle class. In fact you could have a hole host of classes, e.g. tractor, lorry, tank, car, motorbike, etc. If you have the foundations correct all of these real world objects could be extensions of our vehicle class.
Classes are implemented in OOP by instances that enable a programmer to create a new instance of an object. The instance inherits all of the properties, methods and events that can then be manipulated through code to define the actual object the programmer is designing. The underlying class reduces the number of lines of code required to develop a system, thus making it far more efficient to develop the final application.
Once the programmer has created an instance " and they can make instances simultaneously, setting the properties, using the methods and triggering events. Let’s take our car, for example: we’ll need to define how many gears it has, the size of the engine, the colour, the number of seats, etc. Objects can interact with each other, in much the same way real world objects can, so you could create a class for an engine or gear box and then create a relationship between the car (based on the vehicle class and extended car class) that uses a separate class / instance for the engine and gear box. This would enable you to replace a gear box, during a service or repair.
As you can see this approach can get complex very quickly, so it’s all the more important to get your underlying classes right at the beginning, otherwise you”ll be redefining your classes pretty darned quickly. This is why defining the requirements is so important, see The importance of good business analysis and a written specification. Core to programming is the need to create a specification and if at all possible use prototypes to test concepts prior to the development phase, actually writing your classes a system will utilise to deliver the outcomes or objectives. This could be anything from enabling a Senior Management Team (SMT) to review cash flow or stock, to a pilot determining the landing speed or position of a 747.
As you have probably worked out by now, OOP is a powerful, adaptable, scalable approach to developing software! In fact it can be used for more abstract tasks like Artificial Intelligence (AI) either at a low level " traditional or symbolic AI " or at a high level " situated or behavioural AI " that represent the two core arms of AI. As you can imagine AI is more conceptual or abstract than real world objects, but OOP can still be used to model behaviour etc.
As software developers, we have used low level AI for many years " all be it at a very simplistic level " we often use business rules to trigger specific events. This could something as simple as a stock movement that triggered the reordering or replenishment of stock, so that a business has suffice to stock to meet the needs of its clients. Some of our stock control systems learn from data gathered over years, to determine or forecast anticipated stock levels. More complex systems simulate situations like an oil well drilling operation, learning from past data that defines learned behaviour / results that enable the systems to adapt to changing environments. When we first developed a simulator for the gas and oil industry, they were drilling in relatively simple situations, where as today’s wells present far more signify the challenges and the simulator has had to learn these changing conditions. As indeed has our clients, how has won dozens of the Queens Awards for enterprise.
Other examples of low level are traffic lights, that have in built logic and ground sensors to manage traffic flow. Conversely high level, is sparking debate amongst the scientific community, see Artificial Intelligence: The Inevitable Doom Of Mankind? Some are against even low level applications used for military applications, where the system doesn’t have sufficient logic to avoid unintended situations, for example Autonomous Weapons: an Open Letter from AI & Robotics Researchers (see previous link to Mutant Marsupials Take Up Arms Against Australian Air Force). In reality, all software has a degree of low level intelligence. High level is where the system could be considered to have free-thought or consciousness or act in such a way that it would be hard to argue that it doesn’t, in much the same way that you would argue an animal is intelligent. Most people would think of The Terminator films and Skynet as high level or situated or behavioural AI. Perhaps the technological singularity is the ultimate aim: a system’s ability to design another system that is better than itself.
Prolog is a is a general purpose logic programming language associated with artificial intelligence and computational linguistics where as we generally use declarative programming languages.
The objective of this article was to provide a rudimentary introduction to OOP, the concept of class and objects as well as throwing some fun stuff in like Artificial Intelligence (AI). It’s easy to get carried away with articles like this, so hopefully I have struck the right balance. For me it’s obvious to tie in the concepts of scoping, defining and documenting business requirements as well as prototyping within the same article, given that the intended audience are potential clients. At the extreme end AI goes hand in glove with OOP, which is perhaps we have got carried away as it’s such a vast topic and widely misreported by the media.
OOP is at our core, as is making things simple, hence our logo based on Piet Mondrian’s work:
The purist approach to a visual and emotional statement was the objective that the artist was trying to achieve in his deconstructive work, removing all unnecessary and distracting elements from the core message.
What excites us these days are the opportunities to develop applications that enable businesses to operate more efficiently and enable business owner / managers to make informed decisions.