Deconstructing Apex Constructors 1

A constructor is used to create an instance of an Apex class. If a constructor is not explicitly defined then a default constructor is used. The default constructor would be equivalent to creating a constructor with an empty body that didn’t have any parameters. Often times a class is referred to as the blueprint of an object, so a constructor could be referred to as its general contractor. This can be easier understood by playing with some code examples.

Let’s first create a simple class in our Developer org with the following snippet.

Now, let’s print a couple MockAccount variables to the debug log by running the following in the Execute Anonymous window.

Default Constructor

Notice that the mockOne variable is null since we did not instantiate the variable, it has no idea what a MockAccount should look like. Whereas, mockTwo has the structure of the MockAccount class, this is because we created an instance of the MockAccount class which constructed the shell of the object.

Next, we’ll take a look at what happens when we add our own constructor instead of relying on the default constructor by changing our MockAccount class as shown below. A constructor is created almost exactly the same way as a method except that it will never have a return type and it should be named the same as the class itself.

Empty Constructor

Our results are identical as the first run because our constructor did not perform any actions. But what if we want to know the name for every instance of a MockAccount object when it’s created. We can do that by requiring a name be passed in when the object is instantiated by changing our constructor as shown below.

Now let’s go back into our Execute Anonymous window to adjust our mockTwo to pass in the acctName attribute.

Results with Name

The constructor did it’s job and set the name variable to ‘test two’! Let’s take this one step further by setting the name when one is provided but still allowing the object to be created without one. The next example will demonstrate how we can overload a constructor. Basically, we can have one or more constructors and as long as the parameters are different, the class will know which one to use based on which arguments are passed in. Let’s update the class again by adding back in the original constructor and creating a third constructor that populates both the name and acctNumber variables.

We will also update our Execute Anonymous with a couple more MockAccount variables to demonstrate how each constructor is called.

Overload Results


We could also use one constructor to call another constructor, otherwise known as constructor chaining. Update the code to match the snippet below and rerun the Execute Anonymous Window with the same code as before.

Chaining Results

The best way to get a good feel for constructors is to actually play around with some code examples like we did above. You can also find additional examples in the wonderful Apex Guide as well as the Apex Workbook!

Leave a comment

Your email address will not be published. Required fields are marked *

One thought on “Deconstructing Apex Constructors