- A Step Toward Realism
- Overview
- New Architecture Code Examples
- The Usual Type of Client-Side Code
- A Couple of Tweaks that Help Performance
- Collapsed Objects
- Statuses in One Single Byte
- Object Vector
- NonSerialized()
- Using "Dumb" Collections
- Another Struggle with Guids
- Oops, Maintainability Must Be Lost!
- And a Few Tweaks Not Applied Yet
- A New Test Application
- Results of the Throughput Tests
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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 PriceForEach NoOfItems ProductId Comment 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
Get
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.