Question

I’m refactoring, and have run into a roadblock.

Background:

I have a base class and several inherited derived classes. The derived classes don’t always need to have the same properties. If any properties are shared among the derived classes, those properties would live at the base class level (‘Contents‘, for example).

Similarly, GoodDocument below has ‘GoodThings‘ but would not want/need to have ‘BadThings‘.

I want to treat instances of both ‘GoodDocument‘ and ‘BadDocument‘ as type ‘Document‘

public mustinherit class Document
  public property Contents as string
  public sub new()...
end class 

public class GoodDocument
  inherits Document
  public property GoodThings as string
  public sub new()...
end class

public class BadDocument
  inherits Document
  public property BadThings as string
  public sub new()...
end class

The ‘DocumentWriter‘ class will also have several derived classes: (‘GoodDocumentWriter‘ and ‘BadDocumentWriter‘).

I need to pass around the DocumentWriter.Doc as a ‘Document’ to a number of other places in the code. Doc.GoodThings would only be called from within an instance of either ‘GoodDocument’ or ‘GoodDocumentWriter’.

public mustinherit class DocumentWriter
  public property Doc as Document
  public sub new()... 
end class

public class GoodDocumentWriter
  inherits DocumentWriter
  public sub new 
    mybase.Doc = new GoodDocument
  end sub
end class

public class BadDocumentWriter
  inherits DocumentWriter
  public sub new 
    mybase.Doc = new BadDocument
  end sub
end class

Question:

• Is there a design pattern that allows for derived classes to have members that don’t exist at the base class level?

• Do all properties have to live at the base class level?

Revised

I was trying to be brief with my initial question and I made the mistake of over simplifying the situation. In short, I did realize that it should be possible to have different properties on each of the derived classes. (I typed that in a tongue-in-cheek manor and didn’t mean to keep it in the final post).

I realize now that the problem that I was experiencing was really symptomatic of a larger issue which needed addressing.

It appears that I was encountering compiler complaints that could be corrected by further refactoring and looser coupling. While others answered the basic question that I posed, Ryan Gross’ example really helped kick start some new ideas.

Thanks!

Answer 1

What you should do in this case is define the operations that can be performed on instances of Document in an interface. In your case maybe there is a WriteThings operation, so you would have:

public interface Writeable {
    public sub WriteThings();
}

Then in your derived classes you would implement the method to utilize the internal data of the class. For example:

public mustinherit class Document implements Writeable
  public property Contents as string
  public sub new()...
  public sub WriteThings();
end class 

public class GoodDocument
  inherits Document
  public property GoodThings as string
  public sub new()...
  public sub WriteThings()
     //Do something with GoodThings
  end sub
end class

public class BadDocument
  inherits Document
  public property BadThings as string
  public sub WriteThings()
     //Do something with BadThings
  end sub
  public sub new()...
end class

Finally, client code that needs to call WriteThings accesses it through an interface:

public mustinherit class DocumentWriter
  public property Doc as Writable
  public sub new()... 
  public sub PerformWrite()
    Doc.WriteThings();
  end sub
end class

It is generally not a good idea to build several parallel class hierarchies. In this case, one DocumentWriter class should be able to write any class that implements Writeable by invoking its WriteThings method.