CHAPTER 16
Conforming to Interfaces in an Interface-Free Language

WHAT’S IN THIS CHAPTER?            

• Understanding the benefits of interfaces in other languages
• Gaining the benefits of interfaces in JavaScript
• Simplifying consumption of an object with the Interface Segregation Principle
• Producing a registry in which you can define and enforce interfaces

WROX.COM CODE DOWNLOADS FOR THIS CHAPTER

The wrox.com code downloads for this chapter are found at www.wrox.com/go/reliablejavascript on the Download Code tab. The files are in the Chapter 16 download and individually named according to the filenames noted throughout this chapter.

In a 2014 commercial for Google’s business products (https://www.youtube.com/watch?v=bA0Hmhnl1oE), a videoconference is just finishing:

• GOOGLER: So yeah, I think we’re good. I think that about wraps it up. So ...
• WOMAN #1: Great. I’ll send a follow-up email.
• GOOGLER: I don’t ... There’s nothing much to follow up on so I ...
• WOMAN #2: Well, I think we should regroup.
• GOOGLER: We just regrouped. This is the regrouping.
• MAN #1: Cool. I’ll ping you later.
• GOOGLER: You’re pinging me now. What do you want to ping about?
• MAN #2: Next steps?
• GOOGLER: There are no next steps. We just solved them.
• MAN #3: Huh. All right ...

A conversation between a JavaScript programmer and a C# or Java programmer could go much the same way. The JavaScripter throws some objects together and the C# or Java developer keeps insisting, “You can’t do that! The program will fall apart without some interfaces to describe the objects.” The JavaScript developer says, “No, there are no next steps. We just solved the problem.”

Yet any JavaScripter who has worked on a team of more than one must admit that misunderstandings do occur. A member function that used to be called makeAWidget is renamed to makeWidget, breaking downstream code. An object literal’s member variable is named in the singular, objectID, but someone puts an array of object IDs in it. (Hard to believe, but we have seen it happen.)

Strongly typed languages do their best to catch these misunderstandings at compile time, often by using interfaces. What is an interface, and why do programmers in these languages think they are worthwhile?

UNDERSTANDING THE BENEFITS OF INTERFACES

An interface describes a class, but has no executable code. Listing 16-1 shows an interface in C#.

---

LISTING 16-1: A C# interface

public interface IDoThings
{
    void ThingOne();
    int  ThingTwo();
}

---

With that interface defined, a class can inherit from it, thereby promising to implement it, as in Listing 16-2.

---

LISTING 16-2: A C# class implements the interface

public DoThings : IDoThings
{
    public void ThingOne()
    {
        // Function body
    }

    public int ThingTwo()
    {
        // Function body
    }
}

---

If the class fails to implement everything defined in the interface, the compiler will throw an error.

To a JavaScript programmer, this may seem like a lot of trouble. You’re saying everything twice: once in the interface and again in the class. And so it is, but the trouble is not without repayment.

The surface benefit is that an interface makes clear what consumers of the class can expect, and what programmers of similar classes should implement.

Interfaces also act as a sort of double-entry accounting. If the implementation goes out of balance with the interface, the compiler will tell you about it.

On a deeper level, interfaces open a whole world of possibilities to the software engineer, enabling him to solve problems more elegantly. The Strategy Pattern you met in Chapter 13 is one example. When implemented in a strongly typed language, each algorithm implements a common interface. There is no need for a factory method to create the chosen algorithm; dependency-injection software can wire up the desired one through runtime configuration.

Every time you have coded a Jasmine spy in the unit tests throughout this book, you have used the interface philosophy, with the spy implementing the same interface as the real object. Of course, in JavaScript the interface is only implied, but in a strongly typed language it would be explicit and therefore more reliable.

Of the five pillars of SOLID software design you met in Chapter 1, three of them are interface-oriented. The Liskov Substitution Principle (the L in SOLID) states that all implementers of an interface should adhere to the same semantics. The Dependency Inversion Principle (the D) had consumers of a class “own” the interface from which the class inherited. The Interface Segregation Principle (the I) is the subject of the next section.

UNDERSTANDING THE INTERFACE SEGREGATION PRINCIPLE

As much as you may strive to make classes coherent and no larger than necessary, sometimes a consumer of a class needs only a fraction of its capabilities.

As an example, consider the attendee object from Chapter 6, reproduced here as Listing 16-3.

---

LISTING 16-3: attendee.js

var Conference = Conference || {};
Conference.attendee = function(firstName, lastName){
  'use strict';

  var attendeeId,
    checkedIn = false,
    first = firstName || 'None',
    last = lastName || 'None',
    checkInNumber;

  return {
    setId: function(id) {
      attendeeId = id;
    },
    getId: function() {
      return attendeeId;
    },

    getFullName: function(){
      return first + ' ' + last;
    },

    isCheckedIn: function(){
      return checkedIn;
    },

    checkIn: function(){
      checkedIn = true;
    },

    undoCheckIn: function() {
      checkedIn = false;
      checkInNumber = undefined;
    },

    setCheckInNumber: function(number) {
      checkInNumber = number;
    },

    getCheckInNumber: function() {
      return checkInNumber;
    }
  };
};

---

If JavaScript had interfaces, attendee might implement two of them, which Listing 16-4 presents in pseudocode. One is designed for consumers who care only about an attendee’s personal information, the other for consumers oriented toward managing the check-in process.

---

LISTING 16-4: Two possible interfaces in attendee.js

Interface attendeePersonalInfo:
    setId:            function(id)          returns undefined
    getId:            function()            returns a non-negative integer
    getFullName:      function()            returns a string

Interface attendeeCheckInManagement
    getId:            function()            returns a non-negative integer
    isCheckedIn:      function()            returns a boolean
    checkIn:          function()            returns undefined
    undoCheckIn:      function()            returns undefined
    setCheckInNumber: function(number)      returns undefined
    getCheckInNumber: function()            returns a non-negative integer

---

Now suppose several functions in other modules each take an attendee object as an argument. Suppose further that you wish to change attendee’s getFullName method. The functions in the other modules nicely show attendees as arguments (assuming the arguments were named helpfully), but you have no easy way to know which functions your change to getFullName will affect. Sure, you could do a text search for “getFullName” but then you’d also turn up like-named methods in other objects (maybe presenter or sponsor).

This is one problem that the Interface Segregation Principle is designed to solve. The consuming functions, instead of having arguments called attendee, could have attendeePersonalInfo or attendeeCheckInManagement arguments. Then, at a glance, you would know which functions your change might affect (again assuming the arguments are named in a non-deceptive manner).

Furthermore, if you needed to mock an argument for unit-testing, or inject another version of the object, you would be able to draw a tighter boundary around the attendee’s members that you actually need to mock or implement.

Finally, a developer who really only cares about the attendeePersonalInfo portion of an attendee only has to master that small API. A properly segregated interface will make his life easier.

These benefits are enforced in strongly typed languages, but they are certainly available in JavaScript if you’re willing to program outside the box.

In the next section, you’ll build a module by which you can define and enforce interfaces. The module is called contractRegistry because interfaces act as contracts between modules that define functionality and modules that consume it, and because in the next chapter you will use contractRegistry’s capabilities for purposes that are not, strictly speaking, interface-related.

USING TEST-DRIVEN DEVELOPMENT TO CREATE A CONTRACT REGISTRY

The contract registry as developed in this chapter will have the following capabilities, developed in this order:

1. Define a contract (interface).
2. Tell whether an object fulfills a contract.
3. Assert that an object fulfills a contract, throwing an Error if it does not.
4. Turn off all contract enforcement so your program can run faster in production.
5. Attach an aspect to enforce a contract on an object. (In concrete terms, this will mean adding an aspect to the function that creates the object, to inspect its return value.)

Figure 16.1 gives an advance peek at the passing unit tests you’ll aim for.

Figure 16.1

Defining a Contract

A contract definition will consist of a name for the contract and a function that can evaluate an object and return true or false according to whether the object fulfills the contract. The define method, then, has this signature:

function define(contractName, evaluator)

Incidentally, having an evaluator function act as an “interface” is quite different from other languages’ conception of interfaces as static data. This is not only necessary but welcome. It is necessary because JavaScript has no built-in way to evaluate conformance to an interface, and you must code it somewhere. It is welcome because a function can do much more than any data-oriented, interface-description language ever could. Plus, with a function riding along as a first-class object, it feels nice and JavaScripty, doesn’t it?

With several chapters of test-driven development behind you, there is no need to belabor every step toward creating this method. Listing 16-5 shows its tests.

---

LISTING 16-5: Unit tests for the define method (code filename: Interfaces\contractRegistry_01_tests.js)

describe('contractRegistry', function() {
  'use strict';
  var registry;

  beforeEach(function() {
    registry = ReliableJavaScript.contractRegistry();
  });

  describe('define(contractName,evaluator)', function() {

    it('throws if contractName is not a string',function() {
      expect(function() {
        registry.define(undefined,function() {});
      }).toThrow(new Error(registry.messages.nameMustBeString));
    });

    it('throws if evaluator is not a function', function() {
      expect(function() {
        registry.define('myContract','not a function');
      }).toThrow(new Error(registry.messages.evaluatorMustBeFunction));
    });

    it('does not throw if contractName is a string and evaluator is a function',
    function() {
      expect(function() {
        registry.define('myContract',function() {});
      }).not.toThrow();
    });
  });
});

---

As usual, test-driven development begins with the error conditions. Beyond that, there’s not much you can test when define is the only method in the object. You can’t even test that it defines anything. However, until it does you won’t get very far with the fulfills method (up next). Even so, you resist getting ahead of the tests and code only what’s necessary to make the above tests pass. The result is Listing 16-6.

---

LISTING 16-6: Implementation of the define method (code filename: Interfaces\contractRegistry_01.js)

var ReliableJavaScript = ReliableJavaScript || {};
ReliableJavaScript.contractRegistry = function() {
  'use strict';

  return {
    define: function define(contractName, evaluator) {
      if (typeof contractName !== 'string') {
        throw new Error(this.messages.nameMustBeString);
      }
      if (typeof evaluator !== 'function') {
        throw new Error(this.messages.evaluatorMustBeFunction);
      }
    },

    messages: {
      nameMustBeString: 'The contract name must be a string',
      evaluatorMustBeFunction: 'The evaluator must be a function',
    }
  };
};

---

The tests pass, as shown in Figure 16.2.

Figure 16.2

Determining Whether a Contract Is Fulfilled

The fulfills method will look like this:

function fulfills(contractName, obj)

It will return true if obj fulfills the named contract or false if it does not. Before you get to that, you first test the obvious error condition: that the named contract is not in the registry (see Listing 16-7).

---

LISTING 16-7: First test of the fulfills method (code filename: Interfaces\contractRegistry_02_tests.js [excerpt])

  describe('fulfills(contractName,obj)', function() {

    it('throws if contractName is not in the registry',function() {
      function expectThrow(contractName) {
        expect(function() {
          registry.fulfills(contractName,{});
        }).toThrow(new Error(
          registry.getMessageForNameNotRegistered(contractName)));
      }
      [undefined,'abc'].forEach(expectThrow);
    });
  });

---

In previous chapters, you saw how exposing an object’s error messages allows unit tests to verify the exact errors. Sometimes, error messages include variable data. To keep the code DRY, the procedure for incorporating the variable data in a message is put in a function, getMessageForNameNotRegistered.

You can make the test pass (see Figure 16.3) with the code highlighted in Listing 16-8.

Figure 16.3

---

LISTING 16-8: Make fulfills fail if contractName is not registered (code filename: Interfaces\contractRegistry_02.js)

var ReliableJavaScript = ReliableJavaScript || {};
ReliableJavaScript.contractRegistry = function() {
  'use strict';
  var registry = {};

  return {
    define: function define(contractName, evaluator) {
      // *** Omitted for clarity. ***
    },

    fulfills: function fulfills(contractName, obj) {
      if (!registry[contractName]) {
        throw new Error(this.getMessageForNameNotRegistered(contractName));
      }
    },

    messages: {
      nameMustBeString: 'The contract name must be a string',
      evaluatorMustBeFunction: 'The evaluator must be a function',
      nameMustBeRegistered: "The contract '_' is not in the registry",
    },

    getMessageForNameNotRegistered: function getMessageForNameNotRegistered(
    contractName) {
      return this.messages.nameMustBeRegistered.replace('_',contractName);
    },
  };
};

---

The new object at the top, registry, will hold the registrations, but so far define isn’t putting anything there because no unit test has demanded it. This will finally catch up to you when you attempt to make the next tests (see Listing 16-9) pass.

---

LISTING 16-9: Tests that the fulfills method returns true or false depending on whether the contract is fulfilled (code filename: Interfaces\contractRegistry_03_tests.js)

describe('contractRegistry', function() {
  'use strict';
  var registry,
      isArray = 'isArray',
      ary = [1,2,3];

  beforeEach(function() {
    registry = ReliableJavaScript.contractRegistry();
    registry.define(isArray,Array.isArray);
  });

  describe('define(contractName,evaluator)', function() {
    /*** Argument-checking omitted for clarity. ***/
  });

  describe('fulfills(contractName,obj)', function() {

    /*** Previously discussed test omitted. ***/


    it('returns true if the object fulfills the named contract',function() {
      expect(registry.fulfills(isArray,ary)).toBe(true);
    });
    it('returns false if the object does not fulfill the contract', function() {
      expect(registry.fulfills(isArray,'not an array')).toBe(false);
    });
  });
});

---

The tests verify that fulfills returns true or false appropriately. They use a contract whose name is stored in the isArray variable. Near the top of the listing, note the following line:

registry.define(isArray,Array.isArray);

It uses JavaScript’s Array.isArray method as isArray’s contract-evaluator. Quick, lazy, and you know it works. Gotta love it, right?

The tests are in all kinds of hurt (see Figure 16.4) but are instantly set right (see Figure 16.5) when you add just one line to define and one to fulfills, to use the registry object installed earlier. The working code appears in Listing 16-10.

Figure 16.4

Figure 16.5

---

LISTING 16-10: Finishing the define method (code filename: Interfaces\contractRegistry_03.js)

var ReliableJavaScript = ReliableJavaScript || {};
ReliableJavaScript.contractRegistry = function() {
  'use strict';
  var registry = {};

  return {
    define: function define(contractName, evaluator) {
      // *** Argument checking omitted. ***
      registry[contractName] = evaluator;
    },

    fulfills: function fulfills(contractName, obj) {
      // *** Argument checking omitted. ***
      return registry[contractName](obj);
    },

    // *** snip ***
  };
};

---

Steps 1 and 2 of the outline at the top of this section are now complete. Next, it will be useful to have a method that asserts that a contract is fulfilled, throwing an error if it is not.

Asserting That a Contract Is Fulfilled

The assert method is similar to fulfills:

function assert(contractName, obj)

It should use the fulfills method to determine whether the contract is fulfilled, rather than duplicating the code. A test that ensures this also ensures that the argument-checking you have already put in fulfills will be carried into assert. That is the first test of Listing 16-11. The other two verify the core functionality of assert.

---

LISTING 16-11: Testing the assert method (code filename: Interfaces\contractRegistry_04_tests.js [excerpt])

  describe('assert(contractName, obj)', function() {

    it('is based on fulfills(contractName, obj)', function() {
      spyOn(registry,'fulfills').and.callThrough();
      registry.assert(isArray,ary);
      expect(registry.fulfills).toHaveBeenCalledWith(isArray,ary);
    });

    it('does not throw if obj fulfills contractName', function() {
      registry.assert(isArray,ary);
    });

    it('throws if obj does not fulfill contractName', function() {
      var notAnArray = 'abc';
      expect(function() {
        registry.assert(isArray,notAnArray);
      }).toThrow(new Error(
        registry.getMessageForFailedContract(isArray,notAnArray)));
    });
  });

---

Just a few lines make the tests pass, as shown in Listing 16-12.

---

LISTING 16-12: The assert method (code filename: Interfaces\contractRegistry_04.js)

var ReliableJavaScript = ReliableJavaScript || {};
ReliableJavaScript.contractRegistry = function() {
  'use strict';
  var registry = {};

  return {
    // *** define and fulfill methods omitted ***

    assert: function assert(contractName,obj) {
      if (!this.fulfills(contractName,obj)) {
        throw new Error(this.getMessageForFailedContract(contractName,obj));
      }
    },

    messages: {
      // *** Other messages omitted ***
      failedContract: "The following does not fulfill contract '_': "
    },

    // *** snip ***

    getMessageForFailedContract: function getMessageForFailedContract(
    contractName, obj) {
      return this.messages.failedContract
          .replace('_',contractName)+ obj;
    }
  };
};

---

Bypassing Contract Enforcement

You might like the option to switch off all enforcement of contracts once your product has passed QA, particularly if your evaluator functions are time-consuming. (Keep in mind that you’re free to make them much more elaborate than Array.isArray!)

The easiest, most efficient way to do this is to place an object’s contracts in a separate .js file, and simply exclude that file from the production release. You will see an example of this in the next section.

With four of the requirements crossed off the list, only one remains.

Creating an Aspect to Enforce a Contract on a Returned (Created) Object

You could use what has been developed so far to enforce a contract on any object you create. For example, you could define and assert the two attendee-related contracts in the attendee module, as shown in Listing 16-13.

---

LISTING 16-13: Defining and asserting contracts on attendee (code filename: Interfaces\attendee_01.js)

var Conference = Conference || {};
Conference.attendee = function(firstName, lastName, registry){
  'use strict';

  var // *** snip ***
    attendeePersonalInfo = 'Conference.attendee.personalInfo',
    attendeeCheckInManagement = 'Conference.attendee.checkInManagement';

  function fulfillsPersonalInfo(att) {
    return typeof att.setId === 'function' &&
           typeof att.getId === 'function' &&
           typeof att.getFullName === 'function';
  }

  function fulfillsCheckInManagement(att) {
    return typeof att.getId === 'function' &&
           typeof att.isCheckedIn === 'function' &&
           typeof att.checkIn === 'function' &&
           typeof att.undoCheckIn === 'function' &&
           typeof att.setCheckInNumber === 'function' &&
           typeof att.getCheckInNumber === 'function';
  }

  registry.define(attendeePersonalInfo, fulfillsPersonalInfo);
  registry.define(attendeeCheckInManagement, fulfillsCheckInManagement);

  var ret = {
    setId: function(id) {
      attendeeId = id;
    },
    getId: function() {
      return attendeeId;
    },

    // *** Other functions omitted for clarity. ***
  };

  registry.assert(attendeePersonalInfo, ret);
  registry.assert(attendeeCheckInManagement, ret);

  return ret;
};

// Sample usage
var registry = ReliableJavaScript.contractRegistry();
var a = Conference.attendee('Rock','Star', registry); // Does not throw.

---

That works, but it suffers from the drawback that the contract-enforcement is embedded in the object itself, somewhat violating the Single Responsibility Principle. Many developers would prefer an aspect-oriented solution.

The attachReturnValidator method that will be developed shortly attaches an aspect to a function that creates an object, where that object is supposed to conform to an interface. It looks like this:

function attachReturnValidator(funcName, funcObj, contractName)

With that function available, you can place the contract-related code outside of attendee. If you put such code in a separate file, then after QA is complete you can exclude the file from the shipped version, eliminating the overhead from the release.

Listing 16-14 shows how the attendee module from Listing 16-3, which has no injection or use of the registry, can be modified with an aspect thanks to attachReturnValidator. The modification is done through a separate file, attendeeContracts.js, which you would not include in the production release. It contains a function that creates the contracts for the two “interfaces” and then attaches aspects to Conference.attendee that ensure that any object it returns conforms to those interfaces.

---

LISTING 16-14: Using an aspect to assert a contract on attendee (code filename: Interfaces\attendeeContracts.js)

var Conference = Conference || {};

// Call this function to install aspects that will verify that
// attendees created by Conference.attendee(firstName, lastName)
// are valid.
Conference.attendeeContracts = function attendeeContracts(registry) {
  'use strict';

  var attendeePersonalInfo = 'Conference.attendee.personalInfo',
      attendeeCheckInManagement = 'Conference.attendee.checkInManagement';

  function fulfillsPersonalInfo(att) {
    return typeof att.setId === 'function' &&
           typeof att.getId === 'function' &&
           typeof att.getFullName === 'function';
  }

  function fulfillsCheckInManagement(att) {
    return typeof att.getId === 'function' &&
           typeof att.isCheckedIn === 'function' &&
           typeof att.checkIn === 'function' &&
           typeof att.undoCheckIn === 'function' &&
           typeof att.setCheckInNumber === 'function' &&
           typeof att.getCheckInNumber === 'function';
  }

  registry.define(attendeePersonalInfo, fulfillsPersonalInfo);
  registry.define(attendeeCheckInManagement, fulfillsCheckInManagement);

  registry.attachReturnValidator('attendee',Conference,
                                  attendeePersonalInfo);
  registry.attachReturnValidator('attendee',Conference,
                                  attendeeCheckInManagement);
};

// Sample usage:
// In application startup, instantiate a registry and attach aspects.
var registry = ReliableJavaScript.contractRegistry();
Conference.attendeeContracts(registry);
// Aspect installations for other modules would follow.

// Later, when an attendee is created, the aspects will ensure
// that it is valid.
var a = Conference.attendee('Rock','Star'); // Does not throw.

---

---

NOTE The sample code that invokes attendeeContracts at the bottom of Listing 16-14 is just to give you the general idea. A much cleaner procedure will be developed in Chapter 17.

---

Now to develop the attachReturnValidator method.

The contractRegistry_tests.js download for this chapter contains the error-checking tests. Of more interest are the tests of the aspect functionality (see Listing 16-15).

---

LISTING 16-15: Tests of the return value-checking aspect (code filename: Interfaces\contractRegistry_tests.js [excerpt])

  describe('attachReturnValidator(funcName, funcObj, contractName)',
  function() {
    var funcName = 'func',
        funcObj,
        returnValue = [1,2,3];

    beforeEach(function() {
      funcObj = {},
      funcObj[funcName] = function() {
        return returnValue;
      };
    });

    describe('aspect functionality', function() {

      it('returns the return value if it fulfills the contract',function() {
        registry.attachReturnValidator(funcName,funcObj,isArray);
        expect(funcObj[funcName]()).toEqual(returnValue);
      });

      it('throws if the return value does not fulfill the contract',
      function(){

        var isNumber = 'isNumber';
        registry.define(isNumber, function isNumber(ret) {
          return typeof ret === 'number';
        });
        registry.attachReturnValidator(funcName, funcObj, isNumber);
        expect(function() {
          funcObj[funcName]();
        }).toThrow(new Error(
          registry.getMessageForFailedContract(isNumber,returnValue)));
      });
    });
  });

---

The tests use an object, funcObj, and its member called funcName, which are set up in the beforeEach. The call funcObj[funcName]() returns an array (returnValue), so it conforms to the Array.isArray evaluator set up at the top of the test module, which you have already seen.

The first test is straightforward. After applying the aspect to the target function, it verifies that a call through the aspect to target returns the value unscathed.

In the second test, a different return validator is attached—one that expects the return value to be a number. When the return value turns out to be an array, the aspect should throw an error.

Skipping all the TDD steps with which you’re now very familiar, Listing 16-16 shows the completed attachReturnValidator function. After some argument-checking, it uses the Aop.around method introduced in Chapter 2 to capture the target function’s return value, assert that it fulfills the contract, and then return it.

---

LISTING 16-16: The attachReturnValidator method (code filename: Interfaces\contractRegistry.js [excerpt])

    attachReturnValidator: function attachReturnValidator(
    funcName, funcObj, contractName) {
      var self = this;
      if (typeof funcName !== 'string') {
        throw new Error(self.messages.funcNameMustBeString);
      }
      if (typeof funcObj !== 'object') {
        throw new Error(self.messages.funcObjMustBeObject);
      }
      if (typeof contractName !== 'string') {
        throw new Error(self.messages.nameMustBeString);
      }

      Aop.around(funcName,
        function(targetInfo) {
          var ret = Aop.next(targetInfo);
          self.assert(contractName,ret);
          return ret;
        }, funcObj);
    }

---

The completed contractRegistry allows you to assert anything you wish about a newly created object, either as an aspect (refer to Listing 16-14) or in the object’s code itself (refer to Listing 16-13).

If you prefer the aspect-oriented approach, you may wish to review the Module Pattern and Functional Inheritance in Chapter 3, as both of those object-creation patterns are aspect-friendly.

SUMMARY:

Interfaces, a staple of strongly typed languages, confer benefits that JavaScript programmers might secretly wish they could have. These include:

• Clarifying what consumers of a class can expect
• Detecting unwanted changes to a class’s semantics
• Enabling elegant design patterns, which make your code more flexible and robust

The Interface Segregation Principle further simplifies the work of an object’s consumers and helps the object’s developers scope out ramifications of any changes.

In this chapter, you worked through the development of the contractRegistry, an object that can define and enforce interfaces JavaScript-style.

The next chapter takes this one step further, using the contractRegistry to validate arguments passed to a function. With both the inputs and the output guarded by contracts, you will have taken a significant step toward creating reliable JavaScript.