How Interfaces Changed Inherits Forever

In the earliest Agile Business Suite (AB Suite®) releases, there was principally the AB Suite Class – an amazing object that could either be a model of reuse or container of data. You could transform a Class with only two properties: Multiplicity and Inherits.

Multiplicity

When an AB Suite Class is created, the Multiplicity property defaults to zero. This means the object cannot hold data and is a definition for reuse by other Classes. Any other value means the object can hold data and pass information around the application, either from a screen to a file or to a database for storage.

As you can see below, the two variations of the Class have a different icon based on the Multiplicity property. It’s only when you start using them in the logic that you see their true behavior. Invoking a method on a Class requires it to be able to hold data for that action to succeed. That’s why, in the example below, the “AClass” (with a Multiplicity property of 0) is in error and the “BClass” (with a Multiplicity property of 1) is valid.

A Class with a Multiplicity property other than zero is typically referred to as an Attribute with a reusable definition.

Inherits

When an AB Suite Class has its Inherits property set to another Class, it typically means it’s extending the definition and forming a subclass. However, in earlier AB Suite releases, if the Class had no members and a Multiplicity property other than zero, the Attribute would instantiate the Class it was inheriting and reuse the definition – but not extend it.

This proved confusing to developers steeped in Object-Oriented programming, as to them, “inheritance” only applies to a subclass. But with the transitional power of the AB Suite Class, this dual behavior persisted until Interfaces were introduced – “iGraphical” in AB Suite Release 5.0 and “iSerializable” in AB Suite Release 6.1.

Interfaces

Interfaces are essentially a template for a Class to imitate. Many AB Suite shops use Interfaces to allow disparate Classes to be operated on collectively, leading to a massive reduction in coding.

That said, Interfaces do offer another benefit: introducing runtime behaviors. Specifically, the “iGraphical” Interface defines the Attributes to be interacted with via the Agile Business Suite Client Framework, while the “iSerializable” Interface defines the Attributes that can be converted to and from an XML string.

So, how did the Interface change Inherits forever?

The Interface is a relatively new AB Suite entity. But just like Classes, an Interface is composed of Attributes. These Attributes can be primitive in nature or a composition of other Interfaces, but they cannot be an instance of a Class.

To limit the proliferation of Attributes, Interfaces needed a way to reuse definitions – to basically function like Inherits without the subclass capability. So, we introduced a way to create Attributes without the need for a Class.

Created with the “Add Attribute” command, this new Attribute has no Inherits, a Multiplicity that can never be zero, and a Template property to specify the definition. Below is an example of how we create an Attribute that represents an instance of the “BInterface” object.

Note that the concept of instantiation was removed from the Inherits property in AB Suite Release 7.0. In AB Suite 7.0, all Inherits that act as instantiation were automatically converted to use the Template property.

With the new “Add Attribute” command and Template property in the latest AB Suite release, defining Classes and Interfaces could not be simpler. And that makes it easier to allow Inherits to get on with the job of defining subclasses. If you have any questions about these capabilities, or need help putting them to use in your organization, please email us at ABSuite@unisys.com.