The Silver Lining

Lessons & Learnings from a salesforce certified technical architect.

Salesforce: Polymorphism driven by Apex class inheritance

with 9 comments

Polywhatsthatnow? Polymorphism ” is the ability of one type, A, to appear as and be used like another type, B.

It is a facet of OOP and can best be described using the good ol’ example of the ‘Shape’ class problem (thanks Java!). Let’s suppose we’d like to create an application that drew a number of shapes on a page. At the time of analysis we know that we want to immediately support circles, but to future-proof our application we need to support the drawing of any shapes. Being Pretty Darn Good Developers(tm) we realise we should create a Shape class that has a single method used to draw itself, and any specific shapes should be derived from this class, and override that method. Make sense? Didn’t think so.

In our worked example I’ll use colours (Colour = Color my American friends:P) instead of shapes, namely, we have a repeat-tag  that will run over a list of classes. Each of these classes have a getColour() method, but certain classes are expected to return specific colours. That’s right we need a list of classes, so they need to be the same class type, but the same method in each must return different values (let’s assume without the use of conditional logic statements). Enough dilly-dallying, let’s get our code on.

To start with we’ll need an interface that dictates the ‘signature’ required of our classes.

public interface ColourInt {
	String getColour();

We’re also going to need a base colour class that ‘implements’ our interface.. Note the ‘virtual’ keyword, this allows the class to be inherited, and the method to be overridden.

public virtual class ColourClassBase implements ColourInt{

	public virtual String getColour(){
		return 'blue';

Next we’ll code up some extensions of this base class. Note the ‘extends’ and ‘override’ keywords used to inherit the base class, and override it’s method.

public class Green extends ColourClassBase{

	public virtual override String getColour(){
		return 'green';
public class Orange extends ColourClassBase{

	public virtual override String getColour(){
		return 'orange';

So we’ve got our backendish logic, now we need a way to expose it to the world. First up the page-controller,

public class ColoursController {
	public List<ColourClassBase> colours{get;set;}

	public ColoursController(){
		colours = new List<ColourClassBase>();

		colours.add(new ColourClassBase());
		colours.add(new Orange());
		colours.add(new Green());

And then the page that uses it,

<apex:page controller="ColoursController" showheader="false" standardstylesheets="false">

	<apex:repeat value="{!colours}" var="c">
		outputPanel layout="block" style="font-family: Georgia; font-size: 24px">
			outputText value="Aweful Colour Combination" style="color:{!c.colour};"/>


This demo’s nothing to write home about, but I thought I’d put it up so that you know I’m not trying to pull a fast one on you. In the real world polymorphism requires a substantial amount of analysis and technical architecturing, but the value becomes apparent when you need to plug another class type (in our case a colour) into your application.  That, and you get to feel real smarts-like.

Merry Christmas everyone, and goodwill to all.


Written by Wes

December 23, 2009 at 2:04 pm

9 Responses

Subscribe to comments with RSS.

  1. I wonder, would this example be better classified as ‘inheritance’? Polymorphism would require a single class to extend several other classes.

    While polymorphism is not directly supported in Apex, it appears possible with ‘interface’ and ‘implements’.

    Mike Leach

    December 23, 2009 at 6:18 pm

    • Agreed. There is a general definition of polymorphism, which has standard implementations within languages, but which varies across languages. I have amended the code to include Interface implementation (I was totally just checking if anyone actually reads this stuff;) and chosen to mimic the Java pattern adopted for polymorphism.


      December 23, 2009 at 8:09 pm

      • The use of interfaces in the example code certainly appears to come closer to polymorphism than inheritance. Although, I haven’t yet had a need to use it in Apex. I try to stay on the ‘happy path’ of using inheritance and instance methods when object modeling to reduce my long-term support tail 🙂

        I recall when C# did everyone a great service by abandoning polymorphism in favor of multi-interface decoration on a class. Apex appears to be supporting a similar convention.

        Mike Leach

        December 23, 2009 at 8:19 pm

      • Again this makes sense. Newer OOP principles are tending to abandon polymorphism (and some are going as far as throwing inheritance in the bin) in order to avoid the all too common problem of tall, brittle inheritance hierarchies. I have found a few situations where Polymorphism makes sense (mostly around abstracting 3rd-party comms), but I’m sure I’m far from best practices. The input is appreciated.. I think I’ve got some reading to do:)


        December 23, 2009 at 8:29 pm

  2. Thank you for writing this up. I can think of a million reasons to use this.

    However, one especially useful case for abstracting your classes is in custom components. This comes to mind because I recently had a case on this. For instance, let’s say you have a custom component that displays a sorted list of sObjects with a checkbox next to it. Typically, you would have a wrapper class that holds the checkbox Boolean value. If you define a generic interface for the wrapper class, you can specify the interface as the attribute’s type and pass in any implementation class.


    public interface Checklistable {
    public SObject record;
    public Boolean checked;

    All that’s left is to write implementations of Checklistable. The beauty is that this component becomes more generalized than, say, passing in a list of sObjects and creating the wrapper in the component’s controller.

    Another great example of this can be found on our developer site. It goes into detail on controller-to-controller communication.


    December 23, 2009 at 8:00 pm

    • Good to hear 🙂 I’m not sure if you’ve seen it, but I’ve implemented the framework you mention with Ron Hess’s recaptcha component.


      December 23, 2009 at 8:12 pm

  3. Looks like the component got cut out. Here’s an escaped version:
    <apex:component >
    <apex:attribute type=”Checklistable[]” name=”Checklist” description=”A list of sObjects that can be checked for selection.” />


    December 23, 2009 at 8:35 pm

  4. As always, a great post, Wes! 🙂


    December 25, 2009 at 3:02 pm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: