When I do Object Oriented Programming with Ada, I tend to follow a design pattern that makes it easier for me and hopefully also for people reading my code.

For this post I will use the all time classic example of OOP, a Graphic User Interface framework. Here’s what a widget specification looks like:

Now let’s have a look at each element.

Type Instance is [...]

I define one tagged type (object) per package and the name of this type is always “Instance”.

As we all know, naming is the hardest thing in programming, so having to find meaningful names for both the package and type is annoying at best.

Another solution is to use plural for packages names and singular for the types:

But there is one other benefit to using the same type name in every package: easier refactoring.

We know that Ada is an amazing language when it comes to safe refactoring, thanks to its strong typing and powerful specifications. One might say that Ada provides “fearless refactoring”. The drawback is that changing the signature of a method, for instance, means a lot of code to edit.

With this design pattern, an inherited methods look exactly the same for all types:

So we can just copy/past it everywhere it is needed when the signature changes.

Using the other plural/singular naming convention, the type of “This” changes every time.

This may look like a detail but it makes sense to me, and I like the consistency of this convention.

The declaration of widgets looks like this:

Class, Acc and Any_Acc

The next types and subtype declaration follow the same idea, they are always the same for every object.

The subtype “Class” is useful when writing class-wide subprograms, e.g.:

The type “Acc” is a general access type for the instance:

The type “Any_Acc” is a access type for any object in the hierarchy:

You can even define more access types like:

And if you don’t like “Acc” you can use “Reference” or Ref, just stay consistent across your hierarchy:

subtype Parent is Widget.Instance;

Emmanuel Briot already wrote a blog post here on this pattern. Always defining a subtype that names the parent type of the object makes inherited subprogram call easy, readable and safe:

I will let you read Emmanuel’s post to see the pitfalls of other approaches.

subtype Dispatch is Instance'Class;

In Ada, dynamic dispatching on subprograms only occurs on class-wide types. This is unsettling for many, and I was myself caught by this when I started OOP in Ada.

By defining a “Dispatch” subtype, we can make dispatching call explicit, easier to spot and use:

Conclusion

I hope this pattern will be useful to some of you. Let me know in the comments what is your opinion on this, and maybe what other patterns you are using in Ada.