Polymorphism

Polymorphism is implemented to the PAS platform more in the tradition of C++ and C# than Java or Ruby – for reasons of efficiency and documentation.

Example

The following example service implements a simple example for polymorphism:

Our ACME example company sells adapters and connectors. Both are article types of the company that share some properties but do also have dedicated properties that apply to the distinct type.
The class diagram below shows the shared definitions in class Article, and the classes Adapter and Connector that each derive from Article (see Relationships for how to build such a structure).

Let’s assume that this company has a workflow where the article data needs to be serialized (see serialize() operation). Depending on the article category, this should be Adapter.serialize() or Connector.serialize() – which we only now at runtime.

In the execution diagram of our service model, we create an object article having the static type Article, and use article.serialize(), an abstract operation that has no implementation.

At runtime, article has a dynamic type, which, in our example, may vary between the Adapter and Connector types, depending on what type createArticle() returns. Each of them brings their own implementation that is executed, then.

Implications of abstract operations

• If a class contains abstract operations, it is not possible to create an object since we would then get an object having an undefined behavior.

• If an abstract operation is not overridden by a subclass, the Compiler will report a validation error.

• The called implementation of an abstract operation is always specified by the dynamic type.

The advantage of polymorphism is that you can define new derived classes without changing your service implementation (that uses abstract types).

In our example, that would be adding a new article type Divider, for example, that comes with it’s own serialization operation. No need to change the implementation besides that.

Related Content