[번역] Ruby Modules(루비 모듈)

💡원본글 : https://alchemists.io/articles/ruby_modules

Ruby Modules | Alchemists

 

 

루비 모듈은 높은 수준에서 다음과 같은 주요 이점을 제공합니다.

• Namespaces(네임스페이스): 네임스페이스를 지정하고, 객체를 구성하고, 객체를 중첩할 수 있습니다.
• Multiple Inheritance(다중 상속): 다중 상속을 제공하여 클래스 및 인스턴스 수준에서 기존 객체에 추가 메서드 형태로 행위를 추가할 수 있습니다.
• Functions(함수): 다른 루비 객체처럼 직접 메시지를 전달할 수 있는 순수 함수형 메서드를 캡슐화 합니다.

이 글에서는 이 기능을 살펴보는데 시간을 할애할 예정이니, 지금 바로 시작해보겠습니다.

Object Hierarchy(객체 계층 구조)

위는 아래 콘솔에서 볼수 있는 내용을 그린 그림입니다.

Module.ancestors.reverse
# [
#   BasicObject,
#   Kernel,
#   Object < BasicObject,
#   Module < Object
# ]

Class.ancestors.reverse
# [
#   BasicObject,
#   Kernel,
#   Module < Object,
#   Class < Module
# ]

모듈과 클래스를 다음과 같이 생각할 수 있습니다.

• Functional(module) - 함수형(모듈)
• Object Oriented(classes) - 객체 지향(클래스)

물론 루비의 거의 모든 것이 모듈을 포함한 객체이지만, 이는 유용한 프레임워크가 될 수 있습니다.

Namespaces(네임스페이스)

모듈은 아키텍처 내에서 객체의 네임스페이스를 지정하고 구성하는 기본 방법입니다.

module Models
  Location = Data.define :latitude, :longitude
end

물론 클래스를 서로 중첩할 수는 있지만 중첩된 클래스 안티패턴이므로 드문 경우처럼 비공개 내부 클래스가 필요한 경우가 아니라면 권장하지 않습니다. 추가 구성을 위해 네임스페이스를 중첩할 수도 있습니다.

module One
  module Two
    module Models
      Location = Data.define :latitude, :longitude
    end
  end
end

위의 방법은 모듈을 들여쓰기하여 중첩하는 권장 방법입니다. 또는 Flat 구조를 사용할수도 있지만 이는 Flat 모듈 안티패턴으로 강력히 권장하지 않습니다.

module One::Two::Models
  Location = Data.define :latitude, :longitude
end

네임스페이스로서의 모듈의 유연성 덕분에 중첩을 콘솔에 출력하여 계층 구조를 빠르게 검사 및 디버깅할 수 있습니다.

module One
  module Two
    module Models
      puts Module.nesting

      Location = Data.define :latitude, :longitude
    end
  end
end

# One::Two::Models
# One::Two
# One

위와 같이 모듈을 사용하여 코드를 구성하고 구조적 의미를 부여하는 방법(puts문 제외)이 올바른 방법입니다.

Hooks

Hook을 사용하면 객체 내에서 모듈이 정의될 때 추가 동작을 수행할 수 있습니다. 이를 통해 메타프로그래밍과 같은 고급 기능을 구현할 수 있습니다. 4가지 기존 Hook이 있습니다.

• .extended : 클래스 메서드를 확장합니다. descendant(자손)라는 단일 인자를 받습니다.
• .included : 인스턴스 메서드를 포함합니다. descendant(자손)라는 단일 인자를 받습니다.
• .prepended : 객체를 서브클래스 대신 슈퍼클래스로 만들어 앞에 오는 객체 앞에 메서드를 추가합니다. ancestor(조상)라는 단일 인자를 받습니다.
• .using : 기존 메서드를 구체화하거나 새 메서드를 삽입합니다. target 이라는 단일 인자를 받습니다. target은 세분화할 대상입니다. 세분화는 문서의 범위를 벗어나지만 더 자세히 알아보려면 세분화 문서를 참고하세요.

시각적으로는 위와 같습니다.

module Demo
  def self.extended(descendant) = super

  def self.included(descendant) = super

  def self.prepended(ancestor) = super
end

Class.new.extend(Demo).singleton_class.ancestors
# [
#   #<Class:#<Class:0x0000000130c101e8>>,
#   Demo,
#   #<Class:Object>,
#   #<Class:BasicObject>,
#   Class,
#   Module,
#   Object,
#   Kernel,
#   BasicObject
# ]

Class.new.include(Demo).ancestors
# [
#   #<Class:0x0000000130c58038>,
#   Demo,
#   Object,
#   Kernel,
#   BasicObject
# ]

Class.new.prepend(Demo).ancestors
# [
#   Demo,
#   #<Class:0x00000001222123c0>,
#   Object,
#   Kernel,
#   BasicObject
# ]

이를 좀 더 세분화하기 위해 몇 가지 참고사항을 설명합니다.

• 익명 클래스(Class.new를 통한)는 #<Class:0x00*> 로 표시되는 데모용입니다.
• descendant(자손) 과 ancestor(조상) 을 사용하면 가독성이 향상되므로 extending(확장), including(포함), prepending하는 객체의 종류를 빠르게 이해할 수 있습니다.
• extending(확장), including(포함) 시 Demo는 항상 상위 클래스입니다. 앞에 붙일 때만 Demo가 하위클래스가 됩니다. 이 계층 구조를 상기시키기 위해 including, extending 할때는 descendant(자손) 를 사용하고 앞에 붙일 떄는 ancestor(조상) 를 사용하는 이유도 여기 있습니다. 이 용어를 사용하여 자신의 코드를 가독성 있게 유지하세요.

이와 관련하여 하위 클래스가 부모 클래스에서 상속할 때 하위 클래스가 자손으로 전달되기 때문에 Class.inherited 혹은 인자로 descendant 를 사용해야 합니다.

class Parent
  def self.inherited(descendant) = super
end

모듈을 포함하고 이와 동일한 구현을 사용하는 경우 다음을 통해 클래스에 기능이 포함되어 있는지 확인하는 여러 가지 방법이 있습니다.

Example.include? Demo            # => true
Example < Demo                   # => true
Example.ancestors.include? Demo  # => true

기능 추가

다음단계로 내려가면, Module#include 에 의해 호출되는 Module#append_features 가 있습니다. 이 메서드를 구현하면, 착하게 사용할 수도 있고, 악하게 사용할수도 있습니다. 여기 #append_featrues 가 악용되는 상황을 보여드리겠습니다.

module Demo
  def self.append_features descendant
    descendant.module_eval do
      def label = "😈"
    end
  end
end

Example = Class.new { include Demo }

Example < Demo     # nil
Example.new.label  # "😈"

위에서 우리는 #include 에 의해 호출되는 #append_features 를 사용하여 후속 객체에 #label 메서드를 동적으로 생성하여 동작을 변경하고 있습니다. 이것은 #include 를 직접 호출할 때 발생하는 기본 기능을 적용하지 않게 만들어, 즉 super를 호출하지 않음으로써 #include 의 동작을 변경하는 것입니다. 이런 방식은 사용하지 마세요! #label 메서드를 누가 정의했는지 숨기면 디버깅 시 큰 고통을 초래할 수 있습니다.

좋은 측면에서는, #append_features 를 활용하여 추가적인 구현, 디버깅, 제어 검사 등을 추가할 수 있습니다. 여기서는 디버깅 목적으로 어떤 것이 포함되었는지 로그를 남기는 방식으로 #append_features 를 좋은 사례로 사용한 예시입니다.

module Demo
  def self.append_features descendant
    puts "Including #{name.inspect} in #{descendant.name.inspect}."
    super
  end
end

class Example
  include Demo
end

# Including "Demo" in "Example".

큰 힘에는 큰 책임이 따릅니다. - Uncle Ben, Spiderman

악이 아닌 선이 되세요.

Multiple Inheritance(다중 상속)

다중 상속, 흔히 mixin(믹스인)이라고 불리는 방식은 여러 객체에 공통 기능을 포함(include), 확장(exclude) 도는 전처리(prepend)할 수 있게 해줍니다. (위의 Hook 섹션에서 다룬것 처럼). 특히, 메서드를 공통 모듈로 추출하면 이 공통 모듈을 사용하는 모든 객체가 동일한 데이터 및 자식 메서드에 의존할 수 있다는 암묵적인 가정을 하게 됩니다.

module Nameable
  def full_name = [first_name, last_name].compact.join " "
end

User = Data.define :first_name, :last_name do
  include Nameable
end

User[first_name: "Jayne", last_name: "Doe"].full_name
# Jayne Doe

Nameable 모듈이 #first_name 과 #last_name 메서드가 있다고 가정하는 점에 주목하세요. 이 암묵적인 계약은 Nameable 을 이러한 메서드를 가진 객체에서 사용하게 될 것이라고 가정합니다. 이런 방식이 극단으로 치우치면, 단일 모듈에서 여러 메서드를 사용할 때, 특히 새로운 동작이 추가되면서 객체들이 서로 다르게 변화하기 시작하면, 이를 리팩터링 하거나 정리하는 것이 매우 어려워질 수 있습니다.

이것이 바로 여러 상속을 무분별하게 사용하여 복잡한 구현을 만들어내는 많은 팀들이 곤경에 빠지는 이유입니다. 예를 들어, 다섯 개 이상의 모듈로 동작을 나누고, 다음과 같은 객체가 만들어진 상황을 생각해봅시다.

class Demo
  include Comparable
  include Geolocatable
  include Indexable
  include Nameable
  include Observable
  include Searchable
end

위의 상황은 분명 극단적이지만, 여러 번 이런 경우를 목격한 적이 있습니다. 위와 같은 구현에는 몇가지 문제점이 있습니다.

• 혼란스러운 동작: Demo 클래스는 너무 많은 동작을 가지고 있습니다. 비교할수도 있고, 지리적 위치를 추적할수도 있고, 인덱싱이 가능한 등 다양한 기능이 추가되어 있습니다. 즉, 누군가 편리함과 게으름으로 인해 객체의 본래 목적을 깊이 생각하지 않고 여러 기능을 덕지덕지 붙인 것입니다. 객체의 단일 목적인 이해한 후에는, 기능을 개별 객체로 나누어 SOLID 원칙의 S 인 단일 책임 원칙(Single Responsibility Principle)을 따르는 것이 더 적절합니다.
• 순서의 중요성: 여기서 각 모듈을 알파벳 순서로 포함시켰지만, 그 순서가 항상 옳지는 않을 수 있습니다. 특히 일부 모듈이 이전 모듈과 동일한 메서드를 포함하고 있다면 문제가 될 수 있습니다. 다시 말해, 나중에 포함된 모듈이 이전 모듈보다 우선하게 되며, 이로 인해 충돌하는 동작이 발생할 수 있습니다. 주의하지 않으면 이러한 충돌은 불필요하게 복잡한 디버깅 상황을 초래할 수 있습니다.

가장 심각한 문제는 Active Support Concerns입니다. 이것은 기본적으로 다중 상속을 장려합니다. 더 나쁜 점은 Concerns가 특정한 Rails 방언이기 때문에 더 이상 순수한 Ruby 기능을 사용할 수 없다는 것입니다. 즉, 기능을 라이브러리나 gem으로 추출하여 여러 프로젝트에서 재사용하려 할 때 더 많은 노력이 필요합니다. 순수한 Ruby를 사용하는 것이 좋습니다. 그렇게 하면 필요할 때 더 자유롭게 리팩터링할 수 있는 유연성을 가질 수 있기 때문입니다.

다중 상속을 신중하게 사용하면 강력할 수 있지만, 기존 객체의 코드를 줄이기 위해 여러 메서드를 공통 모듈로 추출하는 것은 결코 현명한 선택이 아닙니다. 대신, Command Pattern을 통해 기능을 추출한 후, 필요한 시점에 의존성 주입을 통해 필요한 것을 주입하는 방법을 고려하세요. 상속보단 조합(Composition)을 사용하는 것이 장기적으로 유지가능한 코드에 훨씬 유리합니다. 또한, 더 고급스러운 Module Builder Pattern도 또 다른 해결책이 될수 있습니다.

Functions(함수)

또다른 장점은 기능적 메서드의 논리적 그룹을 만드는 것입니다. 예를들어, 상태나 추가적인 동작이 필요하지 않은 함수들의 모음을 위해 MyModule.my_function 과 같은 방식으로 순전히 기능적인 이유로 모듈 내의 함수를 그룹화하는 것은 논리적으로 타당합니다.

이러한 작업은 extend self 와 #module_function 을 사용하여 수행할 수 있으며, 여전히 모듈을 포함(include), 확장(extend), 또는 전처리(prepend)할 수 있는 옵션도 제공합니다. 각각의 방법은 아래에 작성되어 있습니다.

Extending Self

Extending Self를 사용하면 일반적으로 인스턴스 메서드로 동작하는 메서드를 클래스 메서드로 변경할 수 있습니다.

module Demo
  extend self

  def label = "Demo"
end

Demo.label                              # "Demo"
Demo.singleton_methods.include? :label  # true

가시성은 클래스에 포함될 때도 변하지 않았습니다.

MyClass = Class.new { include Demo }
my_class = MyClass.new

my_class.label                             # "Demo"
my_class.public_methods.include? :label    # true
MyClass.singleton_methods.include? :label  # false

위 예시에서 볼 수 있듯이, Demo 모듈이 MyClass에 포함되면 #label 메서드는 인스턴스 메서드가 되고, 여전히 공개 상태로 유지됩니다.

또한 이러한 메서드들은 모두 오버라이드할 수 있습니다.

module Demo
  extend self

  def label = "Demo"
end

Demo.label # "Demo"

module Demo
  def label = "Override"
end

Demo.label # "Override"

위 코드에서 Demo 모듈의 label 메서드가 처음에 “Demo” 값을 반환하지만, 동일한 모듈 내에서 다시 정의되면서 “Override”로 오버라이드되었습니다. 이는 Ruby에서 모듈이나 클래스 내 메서드를 다시 정의하는 것이 가능함을 보여줍니다.

Module Functions

모듈의 모든 메서드를 함수로 지정하면 “self”로 확장할 때 유사한 동작을 가질 수 있지만, 더 나은 캡슐화를 위해 가시성을 변경하는 추가적인 이점을 얻을 수 있습니다.

module Demo
  module_function

  def label = "Demo"
end

Demo.label                              # "Demo"
Demo.singleton_methods.include? :label  # true

클래스에 포함될 때 가시성이 변경되지만, 이전에 self를 확장할 때와 동일한 동작을 보이는 것을 확인할 수 있습니다.

MyClass = Class.new { include Demo }
my_class = MyClass.new

my_class.label                             # `NoMethodError`
my_class.private_methods.include? :label   # true
my_class.public_methods.include? :label    # false
MyClass.singleton_methods.include? :label  # false

#label 메서드가 이제 private메서드가 되었습니다. 이는 self를 확장하는 것보다 적절한 캡슐화를 보장하는 추가적인 이점이 있습니다.

모듈 함수의 또 다른 측면은, 한 번 포함되면 원래 동작이 복사본이 된다는 것입니다.

module Demo
  module_function

  def label = "Demo"
end

Demo.label # "Demo"

module Demo
  def label = "Override"
end

Demo.label # "Demo"

module Demo
  module_function

  def label = "Override"
end

Demo.label # "Override"

원래 기능을 재정의하려고 시도할 때 원래 동작만 나타내는 것을 확인할 수 있습니다. 이는 모듈 함수를 포함하면 그것들이 원본의 복사본이 되기 때문입니다. 메서드를 재정의하고 마지막 예시에서 module_function을 사용할 때만 오버라이드가 작동하는 것을 볼수 있습니다. 이는 extend self 를 사용해 오버라이드할 경우 예기치 않게 동작이 변경되는 부작용을 일으킬 수 있다는 점에서 이점이 있습니다.

모듈을 포함하거나 확장 및 전처리할 때는 extend self 대신 module_function 을 사용하는 것이 좋습니다. 그 이유는 객체 API의 범위를 작게(private) 유지하는 것이 크게(public)유지하는 것보다 리팩토링을 더 쉽게 할 수 있고, 다른 객체가 알거나 접근해서는 안되는 데이터에 대한 접근을 최소화할 수 있기 떄문입니다. 메서드를 public으로 사용할 필요가 있을때만 해당 메서드를 public으로 만드는것이 바람직 합니다.

module_function 사용은 protected 나 private 와 유사하게 작동합니다. 한번 정의하면 그 아래의 모든 메서드가 모듈 함수가 되거나, 기호를 제공하여 특정 메서드를 모듈 함수로 지정할수도 있습니다. 예시로는 module_duction :label 입니다.

Module Builder Pattern

기본적으로 모듈은 상태를 저장하기 않기 때문에 Namespace 정리, 다중 상속, 또는 순수 함수 동작의 집합을 만들기에 적합합니다. 그렇기 떄문에 모듈은 Namespace에 매우 유용합니다. 그럼에도 불구하고, Module Builder Pattern은 클래스와 모듈을 동시에 사용할 수 있는 방법을 제공하여 최대한 기능성과 재사용성을 얻을 수 있게 합니다. Module Builder Pattern에 대한 심층적인 설명은 이 글의 범위를 벗어나므로 더 자세히 알고 싶다면 링크를 통해 학습하세요.

네이밍

네이밍은 어렵지만 매우 중요한 작업입니다. 위에서 논의한 바와 같이, 모듈의 이름을 지정할 떄 고려해야 할 두가지는 다음과 같습니다.

• 명사: 조직화를 위한 Namespace
• 형용사: 시스템의 여러 부분 간의 계약 역할을 하여 어떤 작업이 수행될 수 있으며, 어떻게 호출되어야 하는지 지정하는 인터페이스. 이 인터페이스는 Hook을 통해 다중 상속을 사용하여 인터페이스에 맞는 동작을 제공합니다.

명사의 경우 Parsers, Processors, Handlers, Clients 처럼 복수형 명사를 사용하는 것이 좋습니다. 그 이유는 동일한 네임스페이스 내에서 유사한 동작을 하는 여러 객체를 조직화하기 때문에 복수형이 논리적으로 맞기 때문입니다.

형용사의 경우, 모듈 이름에 -able 접미사를 붙이는 것이 좋습니다. 이는 Ruby 코어 라이브러리에서도 충분히 예시가 있습니다.

• Comparable
• Enumerable
• Forwardable
• Observable

어떤 사람이 -able 대신 -ing 을 제안하는 것을 본 적이 있는데, 그 주유 주장은 -ing 가 -able 보다 자연스럽게 들린다는 것이었습니다.

• Accessable → Accessing
• Containable → Containing
• Infusible → Infusing
• Searchable → Searching

흥미로운 생각이지만, 형용사 대신 동사를 사용하는 것은 지양하는 것이 좋습니다. 그 이유는 행동을 가능하게 한다는 의미에서 -able 이 강조되기 때문입니다.

즉, 행동을 수행하는 것이 아니라 가능하게 하는 것입니다. Ruby가 인터페이스를 네이밍하는 방식에서 벗어나면 모듈을 상호작용할 때 더 혼란스럽게 만들수 있습니다. 궁극적으로 일관성이 중요합니다. 추가적으로 설명하자면, 저 역시 이러한 규칙을 제가 작성한 gem에서도 따르고 있습니다.

• Containable
• Infusible
• Pipeable
• Wholable

결론

이 글이 모듈이 제공할 수 있는 모든 기능을 다룬 것은 아니지만, 여러분에게 도움이 되었기를 바랍니다. 자신의 코드를 설계할 때, 네이밍, 구조화, 객체와 메서드의 구분, 상속, 조합 등의 요소를 신중하게 고려하여 코드를 쉽게 발견하고, 이해하며, 사용할 수 있도록 하세요. 좋은 설계는 코드의 가독성, 유지 보수성, 그리고 재사용성을 크게 향상시킬 수 있습니다.