C# Coding Solutions—Marker Interfaces and Their Dependencies

Microsoft .NET Framework, ASP.NET, Visual C# (CSharp, C Sharp, C-Sharp) Developer Training, Visual Studio

Marker Interfaces and Their Dependencies

There has been one missing piece of information in all of the discussion thus far: How does the ICommand interface implementation know what to manipulate? How are the data members _buffer and _filename of FileSaveImplementation assigned? The values of the data members do not come from thin air. This is a problem with minimalist or marker interfaces; they do not provide the mechanism to define the state of the class instance. The minimalist or placeholder interfaces delegate the task to the class and tell the class, "figure it out yourself!" That’s a challenge for the class no matter how it is structured.

The challenge of the minimalist marker interface is to properly manage dependencies. The minimalist marker interfaces imply that the types that implement the interfaces have as few dependencies as possible. Ideally you would have no dependencies, but that is impossible. Figure 4-2 illustrates the types of dependencies that a marker interface might require.

In Figure 4-2 there are four potential dependencies: the Application Object Reference, IMarker Object Reference, IMarker State, and IMarker State Exchange. The arrows in the diagram represent the directions of the dependencies. The dependencies are defined as follows:

• Application Object Reference: A reference from an IMarker interface instance to the Application itself. This reference is necessary so that the IMarker interface can save files, manipulate text, or delete items.

• IMarker Object Reference: A reference from the Application to the IMarker interface instance. This reference would be a collection reference held by a class like CommandImplementationsManager.

• IMarker State: A reference from the Application to an IMarker interface instance. This type of reference is not common and should be avoided. However, it can occur when state in the Application references state in the IMarker interface instances. The reason why this dependency exists in the first place is so that you do not have the same data in multiple places. If at all possible the state should be referenced dynamically by the Application using accessor methods.

• IMarker State Exchange: A reference that can occur when two IMarker interface instances reference state from each other. The reason this happens is the same reason the IMarker State reference happens. This reference should be avoided and ideally an accessor method that dynamically finds the appropriate IMarker interface instances should be used.

Figure 4-2. Dependencies of a placeholder interface implementation