Main Content

Abstract classes, Interfaces, PHP and Java

Archive - Originally posted on "The Horse's Mouth" - 2009-10-03 06:45:18 - Graham Ellis

Abstract classes, Interfaces, PHP and Java

Basics.

When you design code for a number of different similar type of thing (object types, classes) you don't start from scratch in each case - you define a base class which contains all the common code, and you then create subclasses by extending the original. You say that the subclass extends the base class, and you write the extension in a separate piece of source code. That way, you only have one set of fundamentals (i.e. one base class) to maintain into the future, and subclasses in which you only have to maintain the bits that are different in the subclass to the base class.


Two further steps.

1. Sometimes, you'll never actually want to create objects the are in the base class directly. My board example here shows a base class of "animal", but we never have just an animal ... we have a pet, a farm animal, a wild animal, a zoo animal, a mythical animal ... all of which are based on animals but have slight differences in some of the ways we handle them in our code. Indeed, for certain object behaviours (for example, if we call up the value of an object) there won't be common routines - they will always be in the subclasses; this lack of any method at all in the base class means that we can't actually create just an "animal" object, since it would be incomplete - there would be no way of getting back its value.

When you define an incomplete base class that you don't want people to initialize directly, and you want to require any subclass to provide one or more methods of a specific name, you can (PHP) or must (Java) declare that base class as abstract and you can (PHP) must (Java) also declare as abstract members all the things your subclasses are required to provide.

2. There will be times that you want all classes in a certain group that you create to have certain behaviours - certain methods - even through you don't want to inherit any underlying code at all from a base class. For example, you could have a whole lot of different types of objects being insurable, but no common code used for defining any of the data about that, such as terms and conditions and what the risks insured against are. If you want to use such a common way of talking to very different classes, you can (PHP) must (Java) declare an interface (like a skeleton class with no code, just a list of needed methods) and then say that your (sub)classes implement that interface.

Note:

Using Abstract classes and interfaces helps you to ensure that the subclasses that you write conform to the same API (application programmer interface) and thus allow you to process a whole series of objects of similar (but different) types through the same code - polymorphism. But you will see that I wrote "must" against Java and "may" against PHP. What's all that about?

In PHP, extra method definitions from abstract class and interface declarations only provide advise / a framework to the subclasses that use them - causing compile or run time errors if the subclasses haven't provided the extra code that is stated as being required. If you are programming in a large team with a PHP project, or the project is split between several coders who need to check up on each other's coding, they are a good idea ... my diagram has a "Sara" declaring an interface and a class to be abstract, so that she can help a "Pete" ensure that his subclasses are complete. But if Sara was writing all the classes on a small project, she may decide to save herself the extra coding, with the thought that the shorter code will be easier to follow later on. It's very much down to her analysis of the balanace of advantage.

Java, on the other hand, is heavily typed, and if you want to handle a number of objects of similar type through commonly named methods, it REQUIRES you to have them in a variable of the right type, and / or to cast them as appropriate. This additional enforcement by this particular language means that Sara wouldn't be allowed the option of saying "it's a small application / little cluster of classes and abstract declarations and interfaces are unnecessary bloat" as she could (and should) do on occasions in PHP ... no, in Java she must always use abstract and interfaces. And for the big systems that Java is used for these days, that's not a bad enforcement anyway.

Abstract classes and Interfaces are covered on our Object Oriented Programming in PHP day, and on our Java Bootcamp.