Dr. Park Munho always emphasizes modularization.

The brain learns like this.

• Divide into small units (cells, functions)

• Bundle those units to create modules

• Modules come together to form a system

Coding is the same.

• Method: one action

• Class: one object (existence)

• Module: a higher-level framework that bundles multiple classes/methods into a larger concept

In Ruby, Modules can be used like this:

1. Namespace grouping

2. Sharing common functionality (Mixin)

3. Creating a higher-level concept that defines a domain (thematic world)

The moment you understand this,

code starts to look like a structured universe map inside the brain.

1. Namespace: A frame that divides the worldview

For example,

Let's say you want to use a class called User in multiple places.

• User for the admin page

• User for the online store

• User for the API

What if you just create it as class User everywhere?

There will be naming conflicts. It gets confusing.

Here, modules separate the worldview.

module Admin
  class User
    def info
      puts "This is a user for the admin page."
    end
  end
end

module Shop
  class User
    def info
      puts "This is a customer user for the online store."
    end
  end
end

admin_user = Admin::User.new
shop_user  = Shop::User.new

admin_user.info  # => This is a user for the admin page.
shop_user.info   # => This is a customer user for the online store.

Here, the module literally becomes:

"This is the User of the Admin world"

"This is the User of the Shop world"

serving as a framework that divides the worldview.

Park Munho's Brain Perspective

• Frame: Even with the same name, the role changes depending on the higher frame

• Dimensionalization: Rather than conceptualizing User as a flat concept,
  
  it is stored as a structure with coordinates like "Admin-User," "Shop-User"

• Modularization: It feels like creating "domain-specific drawers" in the brain

Now, your brain

gains a higher understanding that "even with the same name, if the worlds are different, they are completely different entities."

2. Mixin: A module that 'mixes in' common abilities to multiple classes

The second purpose is really powerful.

Modules can become chunks that allow reusing common functionalities.

For example,

Let's say various types of objects all "log information."

• User's action log

• Order status change log

• Payment failure log

If you copy-paste this to each class?

• Code duplication

• Maintenance nightmare

• Need to modify in multiple places for fixing one bug

Here, module + include shines.

module Loggable
  def log(message)
    time = Time.now
    puts "[#{time}] #{message}"
  end
end

class User
  include Loggable

  def sign_in
    log("User has signed in.")
  end
end

class Order
  include Loggable

  def submit
    log("Order has been received.")
  end
end

user = User.new
user.sign_in
# [2025-12-09 23:12:34] User has signed in.

order = Order.new
order.submit
# [2025-12-09 23:12:35] Order has been received.

What Happened Here

• The Loggable module modularizes the ability to "log"

• By including Loggable,
  
  that class can use the log method as if it were its own

• In other words, it feels like plugging in an ability package to multiple classes

From a Brain Perspective

• When sharing one function in multiple places,
  
  the brain bundles it as a "higher concept"

• The module plays the role of that higher concept

• Not only the code but the thought structure itself becomes abstract

"Ah, logging is not a part of User or Order,

but a higher ability shared by multiple entities."

The moment this realization comes,

coding starts to feel like designing the structure of the universe

rather than just "writing code."

3. Abstraction: Modules create a 'domain language' at a level

When you use modules well in Ruby,

the code gradually transforms into something like a "domain language."

For example, let's say there is a domain called "payment system."

module Payment
  module Gateway
    def charge(amount)
      puts "Requesting payment of #{amount} won."
    end
  end

  module Refundable
    def refund(amount)
      puts "Refunding #{amount} won."
    end
  end
end

class Order
  include Payment::Gateway
  include Payment::Refundable
end

order = Order.new
order.charge(50000)
order.refund(20000)

Here, the modules are not just functions.

They are representations of concepts of the domain in code.

• Payment::Gateway → a module representing the "payment request function"

• Payment::Refundable → a module representing the "refund function"

• Order combines these two

As you repeat this process,

your Ruby code gradually feels like this.

"The business concepts I'm thinking of are directly becoming code?"

At this point, the developer

becomes not just an implementer

but a person who designs the domain, a designer/visionary.

4. Module vs Class: What's the Difference?

Let's summarize.

In Ruby, modules do not create instances on their own.

MyModule.new won't work.

Instead:

• They become a chunk of abilities that mix into other classes or

• They become a namespace provider as a higher frame

In other words,

Classes are "existences"

Modules are "concepts/abilities/worldviews shared by existences"

5. The Real Importance is How the Brain Changes

Understanding modules evolves the brain like this.

1. Viewing code as concept units, not file units

- "Where does this feature belong?"  
    → "This is used by User, Order, and Payment together, so let's extract it into a module."

1. Domain language emerges

- Like `Payment::Gateway`, `Notification::Sender`, `Auth::Tokenizable`  
    → Unique vocabularies for your services emerge

1. Significant reduction in complexity

- Clearer places to modify:  
    "I need to change the logics for logging" → Modify only the `Loggable` module

1. Brain structure also gets organized like modules

- This directly connects to what Park Munho calls "the structuralization of knowledge."

6. Mission to Try: Creating Your Own Module

Now,

it's time to embed "modules" into your brain with an assignment.

Assignment 1: Creating a Timestamped Module

Requirements:

• Create a module named Timestamped

• Provide one method called stamp

  • When called: Output in the format [current time] message

• Include it in the Post and Comment classes for common use

Expected Flow:

module Timestamped
  # Create the stamp method here
end

class Post
  include Timestamped

  def publish
    stamp("The post has been published.")
  end
end

class Comment
  include Timestamped

  def write
    stamp("A comment has been written.")
  end
end

post = Post.new
post.publish

comment = Comment.new
comment.write

Assignment 2: Grouping Your Own Domain Modules

Pick a topic:

• Study

• Fitness

• Blog

• Shop

• Band

Example: Study domain

• Study::Trackable – a module to record study time

• Study::Report – a module to output weekly/monthly statistics

Create classes like DayStudy, TaskStudy and

include Study::Trackable to use them.

The moment you do this,

you are already a person who designs your own world in Ruby.

Conclusion: Understanding modules turns code into a 'world design language'

The flow so far:

• Method: the smallest unit of action

• Class: a framework for the existence (object)

• Module: a concept/ability/worldview shared by multiple existences

Now, when you write code

you can think like this.

"Is this a unique property of one object?"

→ Put it in a class

"Is this a function shared by multiple objects?"

→ Extract it into a module

"Is this a domain concept of this service?"

→ Define it with a module + namespace

At that moment,

coding is no longer about "learning language syntax" but

"Implementing the worldview in my head

in the form of code."

And when that feeling comes,

it truly excites you.