Odwoływanie się do klas – krótka czy długa nazwa?

Dzisiaj chciałbym poruszyć temat namespace’owania klas i sposobów w jaki odwołujemy się do nich w kodzie. W przypadku kilku code review zdarzyło mi się sugerować innym, aby będąc w danym namespace’ie, nie powtarzali go przy wywołaniu. Przykładowo, żeby pisać tak:

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

a nie tak:

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

Podczas pracy nad refaktoringiem przypomniało mi się jednak, że mieliśmy podobny temat w jednej z poprzednich firm. Głównym powodem, dla którego zostaliśmy przy zapisie drugim, czyli obszerniejszym, była łatwość wyszukiwania użycia tych klas w projekcie. Drugim powodem było to, że przygotowywaliśmy się do poważnego, zautomatyzowanego refaktoringu (na bazie skryptu) i przygotowanie projektu w ten sposób (tj. podmiana krótkiego zapisu na długi) była wtedy wymogiem.

Na ten temat, jak zresztą na każdy, nie ma pewnie jednej, ostatecznej perspektywy. Przy dobrej namespace’owaniu i modularyzacji kodu na bazie warstw domenowych (np. Carrefour jako jeden z nadrzędnych modułów, który ma w sobie serwisy, adaptery, itd.), a nie na bazie warstw struktury (czyli tak jak często sugerują Railsy, gdzie główny podział to adapters, services, itd. a dopiero w nich Carrefour), można tak pewnie robić. Wtedy poszczególne moduły mają swoje API i jak się korzysta z pełnej nazwy to po to, żeby z niego skorzystać.

Rozwinięcie tematu modularyzacji:

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/