BBj Custom Objects Tutorial: Classes

Looking back at Sample 1, we see that the definition of the custom object class Speaker starts with the class verb, and ends with the classend verb. The line of code with the class verb can include additional qualifiers, some of which are optional.

Sample 1. A Very Simple Custom Object Class

Each custom object class must have an explicitly defined access level. Class access levels can be either of two values:

private – a private class can only be used by code in the same physical file (this is the most restrictive class access level)
public – a public class can be used by code in the same physical file or by code in other physical files (this is the least restrictive class access level)

In Sample 1, the Speaker class has an access level of public.

A custom object class can also optionally identify a class that it extends by using the extends keyword. We’ll discuss extending a class in the Superclasses and Subclasses section below.

A custom object class can also optionally identify one or more Interfaces that it implements. We have already mentioned what an interface is. See the Implements section of the Class Verb help page and the Interface Verb help page for more details on this advanced topic.

See the Class Verb help page for more details related to defining a custom object class.

Instantiating a Custom Object

An instance of a custom object class (a custom object) is created using the new operator using syntax that is similar to Java’s new operator. Until a variable has been assigned a “new” instance of an object, that variable remains “uninitialized” (null or empty) and cannot be used. Using the new operator is straightforward, as demonstrated by this line from Sample 1:

Speaker! = new Speaker()

This line creates a new instance of the class Speaker, and assigns it to the variable named Speaker! We already declared Speaker! to have the type Speaker (meaning it will hold an instance of the Speaker class). So far, so good. But what about those odd parentheses at the end of that line?

Constructors

If you are familiar with Java, you already know that Sample 1’s new Speaker() syntax tells the code to run a constructor for the Speaker class and return the newly created instance of that class. Since the code does not place any arguments between the parentheses, the compiler will look for a method on the Speaker class with the following traits:

Its name is the same as the class (Speaker)
It has no parameters (although there can be constructors that take arguments)
It has no return type

This is referred to as the default constructor for the class. By definition, every BBj custom object class has at least one constructor. If your class does not explicitly define one, then BBj (like Java) will implicitly implement a default constructor for you.

You can put BBj code in any constructor that you explicitly define. You can define as many constructor methods as you like, each with the same method name as the class and each having no return type. The compiler must be able to uniquely identify each one by its parameters, though, so you cannot define two constructors on a class that have exactly the same number and types of parameters. Here is an explicit default constructor method for the Speaker class:

Sample 3. Default Constructor for the Speaker Class

Order of Execution

There are a number of things you will need to understand about constructors and initializers and the order in which they are executed:

If a custom class does not explicitly define a constructor, then BBj will define a default no-argument constructor (the default constructor mentioned earlier)
If a custom class A has a superclass B, every constructor of A calls a constructor of B
- Every constructor of class A has access to an implicit field with the name super! that permits it to invoke whatever constructor of B’s that it prefers. For more details, see the super! section.
- If A’s constructor does not use the #super! field to specifically call a constructor of B, then BBj will implicitly call B’s default constructor
- In any case, BBj executes B’s constructor before A’s constructors
All field initializers of a custom class are executed before the constructor code is executed
All static field initializers of a custom class are executed before any non-static field initializers for that custom class.
- Static field initializers of a given custom class are only executed once in any BBj session.
If your code chains constructors (where one constructor calls another constructor), then the superclass constructor and field initializers are executed by the last constructor in that chain. In that case, instance fields will not be initialized until the chained constructor call returns, and those fields are not available as arguments to the chained constructor call.
If you use either #super!() or #this!() to invoke an explicit constructor (either for the superclass with #super!() or to chain to another constructor for this class with #this!()), the constructor call must be the first line of executable code in your constructor. You can precede them with REM comment lines, but no executable code - including PRINT statements.

Superclasses and Subclasses

A custom object class B can extend another custom class or a Java class (where we use the name “class A” to refer to either of these classes). To extend class A, use BBj’s extends keyword in the class definition along with the name of the class being extended. In this case, we refer to custom class A as the superclass of custom class B, and we refer to custom class B as a subclass of custom class A. For example, Program 2 has the class PayrollCheck (the subclass) extending the class Check (the superclass) using this syntax:

class public PayrollCheck extends Check

If you have done any reading about object-oriented design, you probably encountered the concept of inheritance. The terms superclass and subclass are similar to the parent class and child class in object-oriented discussions of inheritance.

So what does all of this mean to you? You can have a superclass (for example, Auto) and define a subclass (for example, SUV) that extends Auto. Since the subclass SUV extends the superclass Auto, it means that any instance of the custom class SUV has all of the methods and attributes of an Auto. You do not need to define the methods of the Auto class inside of the SUV class, because it already has access to them. An instance of the SUV class is also an instance of the Auto class—with any extra “extensions” that you added.

For further reading on the concept of inheritance, search the Internet for “object-oriented inheritance”, or look for the Software Development training class on the BASIS eLearning web site.

Next Step: Fields

BBj Custom Objects Tutorial Contents

BBj Custom Objects Tutorial: Introduction

BBj Custom Objects Tutorial: Interfaces

BBj Custom Objects Tutorial: Classes

BBj Custom Objects Tutorial: Fields

BBj Custom Objects Tutorial: Methods

BBj Custom Objects Tutorial: Using Custom Objects

BBj Custom Objects Tutorial: Program #1 - Writing a Check

BBj Custom Objects Tutorial: Program #2 - Protected and Private Fields

BBj Custom Objects Tutorial: Program #3: The Static Keyword

BBj Custom Objects Tutorial: Program #4 - Error Handling

BBj Custom Objects Tutorial: Program #5 - Class Inheritance

BBj Custom Objects Tutorial: Program #6 - Callback Choices

BBj Custom Objects Tutorial: Program #7 - Constructors and Field Initialization