Interface Design

<< Component Oriented Classes

Page 6: Correct Use

Now that several classes of interface have been identified that perform very similar functions, the question is: under which circumstances is it correct to use which class of interface?

The fundamental criteria for using different classes are based on whether there is a requirement for HEAVY or LIGHT, ACTION or ENTITY interfaces.

These have the obvious conditions: if there is a requirement to retain state, such as persistence, then an ENTITY interface is required. If the interface is required to interact with a generic container (e.g. COM) then a LIGHT interface is required.

LIGHT interfaces also offer more encapsulation. For example, where a Function Oriented or Object Oriented interface may expose a File object, a Service Oriented or Component Oriented interface may expose a logical name for a data source.

This makes the API architecturally more neutral and able to be manipulated from a general container, but potentially slightly slower. This feature of LIGHT interfaces also makes them strongly qualified to be used at higher architectural levels to create 'soft' walls in your code that minimise the amount of coupling and maximise the ease of testing.

Classes can also be mixed. Clarity between the types of interface can be kept if they are mixed according to composition rules. For example, it makes sense for the FileService and FileObject classes to be exposed at a higher level, but delegate actions to the FileUtility Class. See the examples below:

public class FileService
{
    public String getContents( String fileName )
    {
        try
        {
            return FileUtil.getContents( new File( fileName ) );
        }
        catch( IOException ioe )
        {
            return null;
        }
    }
}

For a FileObject, where the File has been set:

public class FileObject
{
    public String getContents()
    {
        try
        {
            return FileUtil.getContents( file );
        }
        catch( IOException ioe )
        {
            return null;
        }
    }
}

It can also be argued that the setFileName() and getFileName() methods could be added to the FileObject class or FileUtil class to create a heavier interface (see below). However, it should be remembered that these classes are still HEAVY because they expose the File object:

public class FileUtil
{
    public void setContent( String fileName, String content ) {}
    public void setContent( File file, String content ) {}

    public String getContent( File file ) {...}
    public String getContent( String fileName ) {...}
}

public class FileObject
{
    public setFileName( String fileName ) {...}
    public File getFileName() {...}
    public setFile( File file ) {...}
    public File getFile() {...}
    public void setContent( String content ) {}
    public String getContent() {...}
}

Once the FileObject has this interface, it is now a more suitable candidate for the FileComponent to delegate to:

public class FileComponent
{
    protected FileObject = new FileObject();

    public setFileName( String fileName ) {
        fileObject.setFileName( fileName );
    }
    public File getFileName() {
        return fileObject.getFileName();
    }

    public void setContent( String content ) {}
    public String getContent() {
        return fileObject.getContent();
    }
}

Central to these examples is the principle of interface exposure. Exposure of code should be carefully considered when building large-scale architectures.

Whilst design patterns make reference to the composition of classes, they make very little reference to the method signatures and their consequences on the architecture.

Unless there is a strategy in place to encapsulate your types at the architectural level, your architecture will suffer the same tightly coupled fate as poorly designed classes.

>> Next Page: LIGHT Data and Architectures

<< Back to Design

<< Back to Software Reality