The factory method is a creational design pattern. It’s intent is to create instances of classes without having to explicitly call new on them.

Why would you want to do this?

The problem this pattern tries to solve is to have a mechanism for creating an instance of a class without knowing what type will be created.

The GOF defines the gactory method as:

“Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.”

Example

To be the factory method, it has to handle the actual creation of the new instance, if it doesn’t create it, it may be the template pattern or something else.

This example will try to be very descriptive:

class Transport
  def get_to_location
    # the get_new_vehicle method
    # is our factory method, which will
    # determine which vehicle to create
    vehicle = get_new_vehicle
    vehicle.drive # each vehicle class implements the drive method
  end

  def get_new_vehicle
    raise "abstract method, implement in children class"
  end

A derivative class of the Transport class will implement the factory method get_new_vehicle:

class WilburTransport < Transport
  # Wilbur wishes he drives a Ferrari :-)
  def get_new_vehicle
    Ferrari.new
  end
end

class publicTransport < Transport
  def get_new_vehicle
    Bus.new
  end
end

Some notes about the Factory Pattern

1. You should use the factory pattern when you have a class that does not know what objects it should create, or when you want the subclasses to determine the type of objects that should be created.
2. It helps with the single responsibility principle by moving the creation of objects to one part of the system making it easier to maintain.
3. Helps you conform with the open/close principle in that you can add new types of objects without breaking existing functionality.

Very often I find fellow developers struggling with design patterns. They get the question in a job interview or they need them in their daily life to build better system designs. Design patterns are a very important piece in the developers toolchain. I will explain about them and how to use them.

Design patterns are solutions to frequent problems in software design. They are kind of like a blueprint that you can customize for a recurring design problem in your code.

You cannot take a pattern and copy it from somewhere else, they are more like a concept for general problems. You can follow the details of the pattern and change it to suit you specific scenario.

Patterns are usually confounded with algorithms because they both describe typical solutions to general problems. An algorithm expresses the detailed steps to solve a problem. A pattern is a higher level description of a design solution. You can use the same pattern in different projects and the code can be different.

Design patterns are classified by their intent and purpose as:

Creational Design Patterns

Creational patterns provides mechanisms for creating objects and reuse existing code.

• Factory Method
• Abstract Factory
• Builder
• Prototype
• Singleton

Structural Design Patterns

Structural patterns explain how to assemble objects and classes into larger structures and maintining this structures flexible and efficient.

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy

Behavioral Design Patterns

Behavioral patterns are concerned with algorithms and responsibilities between objects.

• Chain of responsibility
• Command
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

I am always looking for ways to make me a better developer. This includes improving the coding process and automation of coding tasks. One area I have been improving is my writing of commit messages.

One bad habit one use to take under time constraints is to ignore documentation. Missing documentation is not important until it is, then, it is important.

That’s one area I’m trying to improve in. Good commit messages are a most often ignored form of documentation, so how do we improve them?

I became aware of Conventional Commits thanks to Enhance your git log with conventional commits. I liked the article and started writing conventional commits by hand for the last couple of days.

I wanted to automate enforcing conventional commit messages in all my projects. I googled and found the tools I needed to set it up globally for all commit messages:

• Commitizen helps writing the conventional commit message
• Commitlint check each commit for proper format
• Git global hooks fail if the commit message does not follow the standard

Commitizen

Commitizen is a handy script that prompts and builds the parts of a conventional commit message.

The first step is to install it: (taken from their README)

npm install -g commitizen

Install your prefered commitizen adapter globally, for example cz-conventional-changelog:

npm install -g cz-commitizen-changelog

Create a .czrc file with the path of the commitizen adapter

echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc

After Commitizen installs instead of using git commit, you create a commit using git cz.

First it will ask for the type of commit:

Then it will ask for a commit subject, description, breaking changes and open issues:

Now that the commit is ready we can continue to the next step.

Commitlint

Commitlint is a tool that will lint your commit message and notify you if it adheres to a standard you’ve chosen.

Global installation is as easy as Commitizen’s. We need to configure some stuff that’s not in the README.

Install the CLI and the configuration you want:

npm install -g @commitlint/cli @commitlint/config-conventional

Create a global config file:

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > ~/commitlint.config.js

That’s all. You can test it to make sure the install is correct:

echo 'must fail' | commitlint

If you want to see a passing message try:

echo 'fix(broken links) fix broken links in homepage'

now we are ready to tie all together …

Git Hook

Commitlint doesn’t do much by it’s own, until it’s placed in a git hook. From inside this hook we will fail the commit message if it does not follow the standard.

Like with the earlier packages, I wanted to set this up for all my projects without having to go and configure each. so I added a global git hook. (Topic for a later post)

I had global git hooks set up, so I added a commit-msg file with a simple script. This script compares it with commitlint, and fails if the message is not following the rules:

#!/bin/bash

cat $1 | commitlint

Conclusion

This three easy steps will enable Conventional Commit in your workflow. You will gain the most from them if you have the habit of creating atomical commits. The beauty of this workflow will be more clear when you have been using it for a while. Do a git log --one-line and see the beautiful list of commit full of context.

Once an application reaches certain size, questions about architecture begin to appear. Rails follows a Model View Controller organization and basic rules exist for clean code:

• No Fat Models – don’t allow them to get bloated
• Keep views dumb – don’t put any logic in there
• Keep controllers skinny – don’t put too much there

And it raises the first question: Where do I put all that code?

Introducing service objects

Service objects can be a class or a module in Ruby that perform an action and can help take out logic from other areas of the MVC structure. For a simple example, let’s say we have a controller like this:

class PostsController < ApplicationController
  def create
    @title = params[:title]
    @content = params[:content]
    @post = Post.new(title: @title, content: @content)
    if @post.save
      flash.notice = 'Post saved'
      render @post
    else
      flash.alert = flash_error_message(@post)
      redirect_to :new
    end
  end
end

Extracting some of this into a service object is easy once you understand the design pattern.

• create a services folder in the Rails’ app folder
• create the service object file, in this example create_post.rb
• extract the functionality to the CreatePost class/module
• reload the Rails app and try it

Service objects as modules

Using a module approach I created a service that looks very much like a factory design pattern:

module CreatePost
  class << self
    def execute(params)
      title = params[:title]
      content = params[:content]
      post = Post.new(title: title, content: content)
    end
  end
end

Which in turn made the controller a lot more manageable:

class PostsController < ApplicationController
  def create
    @post = CreatePost.execute(params)
    if @post.save
      flash.notice = 'Post saved'
      render @post
    else
      flash.alert = flash_error_message(@post)
      redirect_to :new
    end
  end
end

Service objects as classes

In some cases we need to store instance variables and other methods, if so, we use classes. Using a class, our code could be rewritten as:

class CreatePost
  def initialize(params)
    @title = params[:title]
    @content = params[:content]
  end

  def call
    Post.new(title: @title, content: @content)
  end
end

The code of the controller would be:

class PostsController < ApplicationController
  def create
    @post = CreatePost.new(params).call
    if @post.save
      flash.notice = 'Post saved'
      render @post
    else
      flash.alert = flash_error_message(@post)
      redirect_to :new
    end
  end
end

Organizing service objects with modules

When we start using services our services folder tends to grow a lot. We can manage this growth by creating a modular structure using folders and modules.

The services folder can reflect the variety of service objects and it’s different uses in our app. We group them in namespaces using Ruby modules.

module Post
  module Build
    def self.call(params)
      title = params[:title]
      content = params[:content]
      Post.new(title: title, content: content)
    end
  end
end

To achieve this we have to place them in folders that reflects our module structure to let Rails load them.

services/post/build.rb
services/post/update.rb
services/comments/build.rb
...

This way our use of service objects can scale with the growth of our app.

I have a redux-form that contains a dropdown dependent on the selected value of another dropdown.

I have a filter method to slim down the options from the state and fill my dependent dropdown, and it looks great.

I noticed that I had to select a dropdown item from the dependent dropdown to have the value updated in the store.

That’s how I found out about redux-form Action Creators. They are the internal actions from redux-form to dispatch them as we need.

My interest was to change that field when filtering the dependent dropdown options. redux-form provides the change method for cases like this.

Setting it up was as simple as:

import { bindActionCreators } from 'redux'
import { Field, change } from 'redux-form'

// other imports ...

const mapDispatchToProps = (dispatch) => ({
  updateField: bindActionCreators((field, data) => {
    change(FORM_NAME, field, data)
  }, dispatch)
})

Then using it:

this.props.updateField('dependent_field_name', newValue)

Something important to note and quoting redux’s documentation on bindActionCreators:

The only use case for bindActionCreators is when you want to pass some action creators down to a component that isn’t aware of Redux, and you don’t want to pass dispatch or the Redux store to it.

This is my first post on this blog, again.

I have been working for about a year now in a great company and part of
the effect of working with a great team is that you evolve into their strengths. Some time ago I used to blog
frequently, and it was a part of my daily routine to write more. I want to pick it up again, and I set a goal for myself
to improve my communication skills and I feel part of it is to start writing more again.

The intention is to make this a technical blog, but bare in mind that this is mine and I will post what I feel.

Thanks and welcome.