What’s Wrong With My Alignment Entities? (Part 3)

Note: If you downloaded the source from the previous post, “What’s Wrong With My Alignment Entities? (Part 2)”, you may have a bare implementation of an extension application. This was not intentional; I posted the wrong source file. You can get the right file now.

In my previous post, “What’s Wrong With My Alignment Entities? (Part 2)”, we looked at the ‘AlignmentEntityCollection’ class, and the interfaces it exposes to access alignment entities. We saw how the class provides different ways of accessing the contained entities in the ‘Alignment’ object, and we provided a couple of sample commands to demonstrate the functionality. But when we looked at the output of the commands, there was something that did not make sense. Here is the output from the second command “CDS_DISPLAYALIGNMENTENTITIESBYORDER’.

When we look at the output, we notice a couple of things that do not seem right. First, the entity at sequence 5 has an ‘Entity Class’ type of ‘AlignmentSCS’. This is the same type as the entity at sequence 3, but the entity at 3 has an ‘Entity Type’ of ‘SpiralCurveSpiral’ and contains 3 sub-entities; where, the entity at 5 has an ‘Entity Type’ of ‘SpiralCurve’ and only contains 2 entities.

The underlying object model for alignments reuses some of the entity type classes to hold the information from the different entity types. Therefore to determine the type of entity, we cannot look at the ‘Class Type’ (the value returned by the ‘GetType()’ method in the alignment entity object). Instead, we need to evaluate the ‘EntityType’ property exposed by the object.

The ‘EntityType’ property exposes an enumeration value of type ‘AlignmentEntityType’, and indicates the kind of alignment entity it represents. This property is the only way the kind of entity can be determined. Using the ‘Class Type’ information instead will only lead to errors and subtle “bugs”. The ‘AlignmentEntityType’ enumeration is defined in this way:

public enum AlignmentEntityType
{
  Arc = 0x102,
  CurveCurveReverseCurve = 0x113,
  CurveLineCurve = 0x111,
  CurveReverseCurve = 0x112,
  CurveSpiral = 0x109,
  CurveSpiralSpiral = 0x110,
  Line = 0x101,
  LineSpiral = 0x107,
  MultipleSegments = 0x10b,
  Spiral = 0x103,
  SpiralCurve = 0x108,
  SpiralCurveSpiral = 260,
  SpiralCurveSpiralCurveSpiral = 0x10c,
  SpiralCurveSpiralSpiralCurveSpiral = 0x10d,
  SpiralLine = 0x106,
  SpiralLineSpiral = 0x105,
  SpiralSpiral = 270,
  SpiralSpiralCurve = 0x10f,
  SpiralSpiralCurveSpiralSpiral = 0x10a
}

Unfortunately, a lot of times we need to know the specific ‘Class Type’ when dealing with alignment entities. This is because the interface for specific types differs from one another, and if we need to do something more than what it is exposed in the common interface, we need to cast the object to the correct type. The following table shows the ‘Class Type’ used for each of the ‘Entity Types’ defined in the ‘AlignmentEntityType’ enumeration, as well as the number of sub-entities contained.

 

Entity Type	Class Type	S-E
Line	AlignmentArc	1
Arc	AlignmentCurve	1
Spiral	AlignmentSpiral	1
SpiralCurveSpiral	AlignmentSCS	3
SpiralLineSpiral	AlignmentSTS	3
SpiralLine	AlignmentSTS	2
LineSpiral	AlignmentSTS	2
SpiralCurve	AlignmentSCS	2
CurveSpiral	AlignmentSCS	2
SpiralSpiralCurveSpiralSpiral	AlignmentSSCSS	5
SpiralCurveSpiralCurveSpiral	AlignmentSCSCS	5
SpiralCurveSpiralSpiralCurveSpiral	AlignmentSCSSCS	6
SpiralSpiral	AlignmentSCS (if entity between two lines) or AlignmentSTS (if entity between two curves)	2
SpiralSpiralCurve	AlignmentSSCSS	3
CurveSpiralSpiral	AlignmentSSCSS	3
MultipleSegments	AlignmentMultipleSegments	n/u
CurveLineCurve	AlignmentCTC	3
CurveReverseCurve	AlignmentCRC	2
CurveCurveReverseCurve	AlignmentCCRC	3

There are two things to notice. First, the ‘MultipleSegments’ entity type it is not used at the moment, so you won’t have to deal with it yet. Second, the ‘SpiralSpiral’ type can be contained by one of two classes. If the entity is between two lines, the underlying model will select the ‘AlignmentSCS’ class to hold the entity, but if the entity is located between two curves (arcs), the model will select the ‘AlignmentSTS’ class to represent the entity.

This design may seem confusing, and I can agree it makes the API hard to use, or at least not intuitive. But we have to keep in mind that design decisions are triggered by the requirements of a feature, and I am sure the underlying model was designed in this way for a very good reason.

A different subject is when we need to use the API to implement our applications. Our requirements will be different and maybe this design is not well suited. Fortunately, design patterns provide a good way to encapsulate the underlying implementation and provide an interface that suit our needs. In my next post, I will use established design patterns that will allow me to modify the design design and interface to suit a different set of requirements.