[source code included]
PoC – Proof of Concept
This final PoC version unveils the previously hidden code, while adding some convenience functionality. I also revisited the code one more time; which is now more object-oriented (with some specific behaviors moved to the appropriate object). I hope readability and understanding have enhanced.
Here is how the logical layers and data flow can be now represented:
Figure 1. Data flow throughout the solution’s logical layers
The GUI was updated to allow the user to flatten the tree view nodes; and the ‘Source Code’ button now displays the previously hidden code:
Figure 2. TryAngels 0.0.3.0 – Main Form’s [partial view]
Some design considerations
The next figure depicts some important aspects of the model:
Figure 3. TryAngels 0.0.3.0 – Model Diagram
The solution is based on the fact that any inner triangle of a given (parent) equilateral triangle can be single or composed, pointed upwards or downwards. These possibilities is represented by the InnerTriangleTypes enumeration, and lead us to the four concrete classes shown at the bottom of the diagram.
The EqTriangle abstract class contains a Create static (factory) method, which is used to instantiate and get access to equilateral triangle objects. All calculations are performed at creation time.
The EqTriangle class has a Info property that is consumed by the ReportServices to generate a string that lists the object’s stats and is displayed in the main screen’s text box.
And the Children property of the EqTriangle class encapsulates the inner objects creation logic. It holds an Items dictionary, keyed by both the side length of the inner triangle and its type (as described above).
A convenience CompositeKey struct [value object] is used to label the Items dictionary keys. And each dictionary value holds a list of (IEnumerable) EqTriangles of its corresponding key value.
The next figure shows an example of how it works:
Figure 4. TryAngels 0.0.3.0 – Execute Sequence Diagram.
As a final note, its worthy to mention that this model could be extended to provide rotation functionality. In this case, we would recommend a two-step flexible approach.
First allow the user to choose any given values between the [float] range of 0 and 360; perhaps on a RotatableEqTriangle class. Then derive from this class to set and freeze some values in advance, in order to represent specific cardinal points, such as North (0), South (180), Lest (90), West (270), etc.
Does it make sense?