ClassInheritanceDiscussion is a part of the ObjectBasedProgramming pattern language.
The principles of the LiskovSubstitutionPrinciple and DesignByContract need to mentioned here.
In the following class hierarchy:
[1]
The way that struct for 'Non-leaf Alarm' was shown could be modified as shown below. The key is to define structs for each class in the hierarchy such that:
typedef struct { char abDescription[10], int nChangeCount, int nDescendentChangeCount, BOOL bstate } ConditionClass?; typedef struct { ConditionClass? parentClass, tsOID sIdentifier, int nParentAlarmHandle, int nNextSiblingAlarmHandle } AlarmClass?; typedef struct { AlarmClass? parentClass, int nFirstChildAlarmHandle } NonLeafAlarmClass?;As always in these matters, there are implications of doing this especially when you declare an instance of any of the subclasses of ConditionClass? the compiler *may* use indirection to access the nested struct's. An advantage comes later if you adopt this approach when we try to get polymorphic behaviour, such that the methods that we will define for ConditionClass? are equally able to operate on ANY instance of NonLeafAlarmClass? as well. We'll cover that in PolymorphicFunctionDiscussion though.
-- ScottWalsh
Memory had seldom been so scarce that we had to sacrifice maintainability. I found from experience that the FamilyFusion pattern beats the FamilySplit pattern every time in maintainability. The reason being that it is much easier to manage memory for just one type of fixed-sized data structure. Heap is not used in our systems because of various associated problems, and the memory for the instance data is typically managed using a buffer manager.
This pattern has exactly the same problem as the FamilySplit pattern when the memory is allocated from the heap or a buffer manager. However this pattern is definitely superior to the FamilySplit patterns when the instance data is allocated from the stack because only one data structure is involved. The FamilyFusion pattern still rules if a buffer manager is involved.
This pattern is worthwhile to document and add to pattern language as a companion to FamilySplit and FamilyFusion patterns. BTW it is time to find a better name for the FamilySplit pattern.
-- StephenCheng
Re: "memory had seldom...". In our case, available memory = 16K ROM and 512bytes RAM. -- KeithDerrick