Design patterns in MyCollab (part 1)

MyCollab is the big project contains 45 sub-projects up-to-date of this published post. Its architect makes us challenge when we design the software meet all the following goals:

  • MyCollab has 3 different versions: Open Source, Ultimate, and the Cloud edition. Three editions use some shared modules, and they have the separated modules as well. The open source edition has public its source code and of course, all these open source modules must not depend on the premium modules requires in both compile and runtime phases.
  • Follow the SOLID (Object Oriented Design) to let MyCollab is maintainable, testable, and remove the code smells.
  • Keep the code clean, trackable and easy to write unit tests at any level from unit test, integration test, and automation test.
  • The speed of application must be fast, there is no entry must be called many times

We applied the Package design principles by assigning one responsibility for every module, package such as core, services, UI etc. The detail is the subject of another post in the future, the combining of these principles and practices of common design patterns helped us achieve above goals after several milestones. Let see what patterns we use in MyCollab.

Singleton

Singleton is the popular pattern. but it is the most dangerous pattern if you misuse! We almost use Singleton pattern in case we keep the immutable global variables, that helps us save time to retrieve them many times and we do not use for any purpose. Any request to add more attributes to the singleton objects must be reviewed carefully to avoid any potential issues of memory and rigid codes.

Factory and AbstractFactory

MyCollab supports 3 different versions, we have the different implementations of several features per each version. For instance, with the file feature, in MyCollab we use Amazon S3 and Cloudfront while the other versions we use the file system. The factory pattern helps us can hide the implementation and give the client type objects which it needed.

The abstract factory pattern is used to modularize the software into the sets of factory objects, it could say the abstract factory is the pattern to create the factories which create other factories. We use this pattern in the reporting module where we support reporting per each country. For instance, each report module per locale has a lot of features, which has the different implementation and the abstract factory pattern naturally fit to our needs

Builder

We use the builder pattern to construct the popup view UI component. The builder pattern helps us to abstract the creation of the popup view, while we can construct the view by collecting the set of attributes. It helps us reuse the code across the several similar components and easily to add more features to the existing builder object if needed.

Template method

We have many pages share the same functionalities in MyCollab, and using the template pattern help us to define the structure of the features that the pages are supposed to have. For instance, there are similar features among Issue, Task, Risk, or Milestone. They have the following basic features:

  • Create/Update
  • Read
  • Delete
  • Printer
  • Go to the next or previous item
  • Clone the item

They may have extra features, but all of them are the suitable candidate for the Template method pattern

Decorator

This pattern is the one we usually used in MyCollab product while we want to add the new responsibilities to an object. We have the tabular data format in MyCollab UI views, reports, and emails. Unfortunately, the data structure of tabular data from these destinations is different. Our solution is creating a class contains the basic attributes for the tabular structure and if we need more responsibility, we will wrap it into the new class without using the inheritance

and wrap the class TableViewField into the class TableViewFieldDecorator to add the generating report column feature

 

Leave a Reply

Your email address will not be published. Required fields are marked *