In the last two installments of "Foundations," we looked at the issue of static v dynamic typing in ColdFusion and I argued that treating ColdFusion as a statically typed language led to disappointment and defeat. In this issue let's explore some of the possibilities available when we no longer treat ColdFusion as "Java Lite" but accept it on its own terms..

What Are "Mixins"?
In the late 1970s, a Lisp-based language called "Flavors", originating at M.I.T., introduced the idea of adding functionality from one class to another. The term, mixin, was apparently inspired by some of the ice cream parlors around the M.I.T. campus that offered customers the option of mixing such goodies as Oreos and candy bars into their standard ice cream flavors.

I've been working with Ruby lately, which also offers mixins, and I began to wonder if, freed from the constraints of static typing, (1) it might be possible and, (2) we might benefit from implementing mixins in ColdFusion.

After some thinking, talking with colleagues, and experimenting, I came up with two methods of introducing mixins and I've given them the names class-based mixins and object-based mixins. Both are quite useful but work very differently.

Class-Based Mixins
In the November issue of CFDJ, I explained how Java interfaces are used to provide for multiple-type inheritance while avoiding the problems of code conflict that multiple inheritance languages must deal with.

Java interfaces are wonderful - for Java - but they do violate a sound fundamental of creating software, dubbed the DRY (Don't Repeat Yourself) Principle. In an interview, Dave Thomas (of The Pragmatic Programmer fame) had this to say about DRY: "DRY says that every piece of system knowledge should have one authoritative, unambiguous representation."

Java interfaces push the "authoritative, unambiguous representation" of methods down to the implementing classes. There are many situations that arise where multiple implementing classes of a single interface will mean multiple code implementations.

Let me offer some example Java code to illustrate:

public interface Teacher{
     public void giveTest(Test test);
}

Here we have a very simple interface, defining what it means to be a teacher: a teacher is someone who can give a test. What does it mean to give a test? For our purposes, let's say that it entails the following:

1. Give out Test booklets
2. Answer any questions about the test
3. Monitor the students
4. Monitor the time
5. Collect the test booklets at the end of the allotted time

public class Teacher implements interfaces.Teacher{
    private String name = null;

    public Teacher(String name){
      setName(name);
    }

    public void giveTest(Test test){
      giveOutTestBooklets(test);
      monitorStudents();
      monitorTime(test);
      collectTestBooklets();
    }
    // giveOutTestBooklets, monitor Students, monitorTime,
    // and collectTestBooklets methods below...
}

Now, I'll implement the Teacher interface in another class - say, StudentTeacher:

public class StudentTeacher extends Student implements Teacher{

    public StudentTeacher(){
      // default constructor
    }

    public void giveTest(Test test){
      giveOutTestBooklets(test);
      monitorStudents();
      monitorTime(test);
      collectTestBooklets();
    }
    // giveOutTestBooklets, monitor Students, monitorTime,
    // and collectTestBooklets methods below...
}

That doesn't look like one representation to me: we have a lot of duplicated code. Fortunately, class-based mixins can help us. Let's tackle the same problem but with ColdFusion with class-based mixins.

Our first step is to create a single representation of a teacher. We'll save this as a ColdFusion template (not a CFC) called Teacher:

<cfset variables.instance.name = null />

<cffunction name="init" access="public" output="false">
     <cfargument name="name" required="true" />
     <cfset set('name', arguments.name) />
     <cfreturn this />
</cffunction>

<cffunction name="giveTest" access="public" output="false">
     <cfargument name="test" required="true" />
     <cfset giveOutTestBooklets(arguments.test) />
     <cfset monitorStudents() />
     <cfset monitorTime(arguments.test) />
     <cfset collectTestBooklets() />
</cffunction>

<!--- other methods below... --->

This is the code we're going to mix into classes. Our first class is Teacher.cfc:

<cfcomponent displayname="Teacher" extends="BaseComponent">
    <cfinclude template="Teacher.cfm" />

    <cffunction name="init" access="public" output="false">
      <cfargument name="test" required="true" />
      <cfset set('test', arguments.test) />
      <cfreturn this />
    </cffunction>
</cfcomponent>