MiG InfoCom MiG Calendar Tutorial - Manual (Page 6)

MiG InfoCom AB
MiG Calendar Product Site
www.migcalendar.com
Bug Reports
Please submit a support ticket.
Class hierarchy design notes
Easy to Extend
MiG Calendar has been developed to be easy to extend and still easy
to understand. Class design at large is similar to that of Swing’s.
Interfaces are used for places where the implementation should be
able to be switched and abstract base classes normally implements
boiler plate functionality giving the user the option to re-implement
everything by using the interface or just what matters by extending the
abstract base class.
Method Signatures
You will notice that the method signatures normally are a bit longer
that usual, with more options and boolean flags in them. Having one
method with more options compared to one method per option will
make extending that class easier since there is only one method to
override rather than many chained ones.
There is usually more than one way to change the behavior of some
class. There are the normal get/set methods that are used for simple
properties. Often the classes can be overridden to change the
behavior and for the bigger changes the implementations can be
exchanged via ‘add/remove concrete implementation’ pattern.
Immutability
Immutable objects are used extensively in MiG Calendar. Immutable
objects can not change once created and are therefore thread safe
and less bug prone due to accidental changes. The downside is that
the constructors can be rather lengthy, but that is a price we are willing
to pay for stability and simplicity.
Return type philosophy
Defensive copying (cloning) of objects returned from method calls is
normally the case, but not always. For instance getting the bounds of
an
ActivityView returns the ‘live’ object. The reason for this is
performance. The bounds will be read thousands of times per second
MiG Calendar Tutorial Page 6 / 24