Referencing classes – short or long name?

Today I would like to discuss the topic of class namespaces and the ways in which we refer to them in the code. In the case of several code reviews, I suggested to others that when they were in a given namespace, they should not repeat it when calling it. For example, to write like this:

module Carrefour
  class ShopAdapter
    def call
      PayloadValidator.call
      ...
    end
  end
end

and not like this:

module Carrefour
  class ShopAdapter
    def call
      Carrefour::ShopAdapter::PayloadValidator.call
      ...
    end
  end
end

However, while working on refactoring, I remembered that we had a similar topic in one of the previous companies. The main reason why we stuck to the second, more extensive approach, was the ease of finding the use of these classes in the project. The second reason was that we were preparing for serious, automated refactoring (script-based) and preparing the project in this way (i.e. replacing the short entry with a long one) was a requirement then.

There is probably no single, final perspective on this topic. With good namespace and code modularization based on domain layers (e.g. Carrefour as one of the parent modules that has services, adapters, etc.), and not not on structure layers (i.e. as Rails often suggests, where the main division into adapters, services, etc., and only then Carrefour), you can probably do that. Then individual modules have their own API and the full name is only used to use it from the outside.

More about modularization:

https://blog.arkency.com/physical-separation-in-rails-apps/
https://medium.com/@dan_manges/the-modular-monolith-rails-architecture-fb1023826fc4
https://progressivecoder.com/inside-shopify-modular-monolith-approach/

Leave a Reply

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