Home > Articles > Programming > Windows Programming

  • Print
  • + Share This
From the author of

Oops, Maintainability Must Be Lost!

As discussed in the last article, I consider maintainability to increase when using custom classes (at least when used well). And now I'm talking about obscure tweaks that feel a lot like premature optimizations. That must mean that maintainability loses a lot!

Nope, I don't think so. All those tweaks are done in EntityBase, and that's not where you'll spend a lot of maintenance time when it is somewhat ready. The bulk of the maintenance work is put in the subclasses; for example, when a requirement changes. As a matter of fact, one advantage of the new architecture is that you have to write very little code in the subclasses.

Currently, the only thing you have to write in the current version of the architecture is what is shown in Listing 7 and Listing 8.

Listing 7—Declarations and Code for Dealing with the Object Vector

Private Enum Properties
End Enum

Private Const LastCollapsedField As Properties = Properties.Comment
Private Const LastExpandableField As Properties = Properties.Comment
Private Const FirstComplexField As Properties = Properties.Comment

Protected Overrides Function _
_PositionForLastCollapsedField() As Integer
  Return LastCollapsedField
End Function

Protected Overrides Function _
_PositionForLastExpandableField() As Integer
  Return LastExpandableField
End Function

Protected Overrides Function _
_PositionForFirstComplexField() As Integer
  Return FirstComplexField
End Function

As shown in Listing 7, you have to define what each property in the object vector in the EntityBase means. You also have to define offsets in the object vector and answer questions from the EntityBase about the offsets.

Listing 8—An Example of a Property

Public Property PriceForEach() As Decimal
    Return DirectCast(_GetProperty _
    (Properties.PriceForEach), Decimal)
  End Get
  Set(ByVal Value As Decimal)
    _SetProperty(Value, Properties.PriceForEach, Nothing)
  End Set
End Property

Listing 8 shows an example of a property get/set. You have to write one such piece of code for each property.

Except for these, the only code you have to write in your subclasses are interesting things such as custom behavior. And that's the stuff you really want to spend the time on.

Even if you decide to use code generation and something like the Generation Gap pattern (see John Vlissides, Pattern Hatching. Addison-Wesley, 1998: ISBN 0-201-43293-5) for generating your subclasses, it's pretty nice to not have more code generated than necessary. Generating the code shown above is pretty simple.

The Generation Gap Pattern

If you apply the Generation Gap, you make the methods shown in Listing 8 overridable; and you never write custom code in those classes, but generate them and regenerate them (again and again, when you need to). Instead, you inherit them and write the custom code in the new subclasses.

  • + Share This
  • 🔖 Save To Your Account