Overview - YiZhang-Paul/Mock_Up_Calculator GitHub Wiki

The application is implemented using windows form with code re-usability and maintainability in mind. Therefore, following decisions are made when designing the application:

• The application follows MVC architecture to separate business logic and output rendering, so that:

  • the implementation is largely simplified as each component has less concerns and better defined responsibilities;
  • this leads to better maintainability overall.

• The application utilizes factory method pattern for easy object creation;

• The application uses bridge pattern to structure calculator components due to following concerns:

  • at first glance, use of inheritance is more intuitive to provide varying implementations of an abstract class/interface;
  • a closer examination on the class relationships concludes that relying on inheritance heavily may create a deep level of class hierarchy that could become hard to maintain overtime;
  • behaviors in different calculators may or may not share the same implementation;
  • for example, given three calculators A, B and C: for a given behavior, if all three calculators share the same implementation, they can inherit that implementation from a super-class; on the opposite, if all three calculators have different implementations, they can implement the behavior in their own ways; however, when A and C share the same implementation while B has its own implementation, then the implementation for A and C will have to be duplicated, or B has to override the entire implementation. When this scenario applies to multiple behaviors, using inheritance will discourage code reuse and make the code hard to change;
  • the calculator interface needs to be extended;
  • therefore, bridge pattern is used to decouple the abstraction (Calculators) and its implementations (Formatter, Input Buffers, Memory Storage, etc.) so that the calculators can have different control logic while delegating most of the real work to the implementation classes. The abstraction and implementations can vary independently and thus makes the code easier to change and be reused.

• The application uses strategy pattern for the converter components:

  • all converters do the same thing: converting from one particular unit to another unit while allowing users to input some values. The only difference is the conversion rule being used by each converter (e.g. Angle, Length or Time converter);
  • encapsulating different conversion rules and inject one of them into a base converter object as needed makes the code easy to test, maintain and extend (creating a new converter is as easy as just adding a new conversion rule/table).