design_patterns.md

Day #1

Discussed:

• Concerns/Mixins vs. Explicit classes for business logic

  • Cons for Concerns:
    • Concern will grow in responsibility and behavior
    • Concerns across repos are hard to manage
    • "floating" methods are implicit
    • Poor naming standards across teams. The behavior encompassed in a concern is not explicit. e.g. CaseStatusConcern could be improved by CaseStatusFetchable
  • Pros for Concerns:
    • If we established a naming convention such as "#{behavior}able" (e.g. Taggable, Discountable, Uploadable) then some of the cons of using concerns can be alleviated
    • Concerns folder makes it easier to identify code as opposed to creating explicit objects and putting them in app/models

• Recommendations

  • Establish guidelines for when to use a concern vs a plain ruby object
  • Agree on a folder structure for plain ruby objects
  • Revisit existing Concerns and potentially rename them or extract them into POROs (Plain Old Ruby Object)

DAY #2

Discussed: - Dependency Injection -Cons for DI -Takes more code -More complex than calling explicitly calling methods - Might be unessesary -Pros for DI -Makes code more flexible -Makes testing easier(No need for webmock) - Recommendations - People should know that DI is an option in ruby - If the reccomendation to use modules less is taken, there will be many more oportinities to use DI - DI shoudl be used on application external dependencies

Day #3

Discussed:

• Class Inheritance Pros and Cons

• Cons for Inheritance

  • When inheriting more than one level, it can become a convoluted path to follow to identify a method being invoked
  • We don't get an immediate overview of what methods, callbacks, and instance variables are defined when looking at the child class
  • Callbacks can get invoked "mysteriously" when they are higher up the inheritance chain and unknown to the child

• Pros for Inheritance

  • DRY's up the code
  • Ensures consistency of doing things across child classes
  • By declaring empty methods with raise in the base class, we can create a de-facto interface

• Recommendations

  • Inheritance is good and should be used
  • Ensure when declaring base classes that any methods that need to be defined in the child classes are defined in the parent with raise exceptions to notify developers