1.5 Evaluate an application design and implementation considering maintainability

This is not a formal blog entry for this post but just a musing about my own poor design choices after reviewing some of the material for this course.

My web app: quaildata.app

…. was my first serious attempt at creating a web app with some complexity. I learnt a lot of to do’s and don’t’s.

Original Design

The structure of my website in the beginning used two SQL tables called <<poultry>> and <<batch>> to signify a batch of quails or an individual bird.

The only difference were the following added fields (in <<batch>>):

  • is_batch: Boolean
  • total_incubated: Int
  • total_hatched: Int
  • dead_birds: Int

And the following added fields (in <<poultry>>):

  • sex: Boolean
  • alive: Boolean
  • batch: Int
  • tag: Int
  • culled: Timestamp

Here is a UML diagram of the original system tables:

This is a poor design as there is because the <<batch>> schema has multiple roles:

  1. A source of data about quail batches
  2. Forms a relational link with <<poultry>> (tight coupling)
  3. Forms a dependency as well as an inheritance

As you can see “batch is a batch” but “poultry is part of a batch”. This makes the programming difficult because the roles of each class are not defined and do not follow the “single responsibility principle”.

This design pattern breaks the SOLID design principals. Numbers 1, 2, and 3:

  1. Single responsibility principle: One class should have only a single responsibility.
  2. Open-closed principle: Components (classes, methods, etc.) should be open for extension but closed for modification.
  3. Liskov’s substitution principle: Derived types must be completely substitutable for their base types.
  4. Interface segregation principle: Clients should not be forced to depend upon the interfaces they do not use.
  5. Dependency inversion principle: Program to an interface, not to an implementation.

Current Design

I actually rewrote the website to rely on a single table <<poultry>> with an extra row called “is_batch”. This was an attempt at polymorphism but still failed the first rule of SOLID.

Here is a class diagram to show roughly how that worked.

As you can see the design still overloads the measurement table which breaks the first rule of SOLID.

Future Design

I have redesigned the system in UML form to better conform to SOLID design principals:

In this new design the following improvements have been made:

  1. Animal now inherits from Stock which allows Stock to have as little attributes as possible
  2. Animal can now have a type allowing the program to be expanded to handle more types of animals
    • language used in general to allow for birds/mammals and other animals
  3. Loose coupling is made between measurement class
  4. Measurements can now have unlimited fields as measurements are referred to as a UUID rather than an ID.
  5. Measurement types are unlimited as well due to types being implemented for them

Final Thoughts

After building a few projects I can definitely see the importance of OOP and SOLID design principals. I will be creating an Anki deck to cement the concepts better.

I am at the early stages of studying for this certification but can already see the usefulness of the subjects taught.


You can download my final UML doc here. To open it use UMLet.

Leave a comment

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