Organização do código com módulos

As your Clojure projects grow, keeping all your code in one file or a single namespace quickly becomes unmanageable. This is where modularity comes in!

Modularity means breaking down a large system into smaller, self-contained, and independent units called modules.

• Clarity: Easier to understand specific parts.
• Reusability: Components can be used in other projects.
• Maintainability: Changes in one module are less likely to break others.

In Clojure, the primary unit for organizing code and achieving modularity is the namespace. You learned about namespaces in the previous lesson.

Each .clj file typically defines a single namespace. A "module" in Clojure often refers to a logical grouping of related namespaces, usually residing in a specific directory structure within your project.

Think of it like folders on your computer: a main folder (project) contains subfolders (modules/groups of namespaces), which contain files (individual namespaces).

Clojure projects typically follow a convention for their directory structure. This helps tools (like Leiningen or Clojure CLI) find your code and resources, and makes projects easier for others to navigate.

The most common directories you'll see are:

• src/: Contains all your primary Clojure source code files.
• test/: Holds your tests, mirroring the structure of your src code.
• resources/: For non-code assets like configuration files, templates, or static web content.

Keeping this structure consistent is a best practice for modular, manageable projects.

Clojure has a direct mapping between a namespace name and its file path within the src/ directory.

If you have a namespace named my-project.core, its definition will typically be found in src/my_project/core.clj.

• Dashes (-) in namespace names become underscores (_) in directory/file names.
• Dots (.) in namespace names become directory separators.

This convention allows Clojure to automatically locate and load your code.

To use code defined in another namespace (another module), you need to require it. The :require clause in your ns declaration does this.

When you :require a namespace, its code is loaded, and its public functions become available, usually prefixed with an alias.

Here's a common pattern:

(ns my-project.main
  (:require [my-project.utils :as utils]))

(utils/some-function)

This loads my-project.utils and creates an alias utils, allowing you to call its functions as utils/function-name.

When you :require a namespace with :as, you create a short alias. This is the most common and recommended way to use other namespaces, as it prevents naming conflicts.

Sometimes, you might want to bring specific functions directly into your current namespace without a prefix. This can be done with :refer.

(ns my-project.main
  (:require [my-project.utils :refer [greet]]))

(greet "CoddyKit") ; No prefix needed!

While convenient for a few functions, overuse of :refer can lead to confusion if multiple namespaces define functions with the same name.

Let's see how a main application namespace can use functions from other namespaces. In a real project, math-utils and string-utils would be in their own .clj files.

Here, we simulate this by defining them within the same runnable snippet for simplicity. Notice how math-utils is aliased, and capitalize-word is directly referred.

Creating effective modules goes beyond just splitting files. Good module design focuses on making your code easy to use, understand, and reuse.

• Cohesion: A module should have a single, clear responsibility. All its functions should be related to that responsibility.
• Low Coupling: Modules should depend on each other as little as possible. This reduces the ripple effect of changes.
• Clear API: The public functions of a module should be well-defined and easy to understand, acting as its interface.
• Small & Focused: Avoid "god modules" that try to do too much. Smaller modules are easier to reason about.

Consider a Clojure project with the following structure and code snippets:

src/my_lib/utils.clj:

(ns my-lib.utils)
(defn greet [name] (str "Hello, " name ";!"))
(defn farewell [name] (str "Goodbye, " name "."))

src/my_lib/core.clj:

(ns my-lib.core
  (:require [my-lib.utils :as u]
            [my-lib.utils :refer [farewell]]))

(defn run-app []
  (println (u/greet "Alice"))
  (println (farewell "Bob")))

What will be printed to the console if (run-app) is called?

You've learned how to organize your Clojure code into reusable modules!

• Namespaces are the fundamental units of modularity, mapping directly to file paths.
• A standard project structure (src/, test/, resources/) aids organization.
• The :require clause in ns allows you to load other namespaces, often with an :as alias.
• You can use :refer to bring specific functions directly into your current namespace.
• Good module design emphasizes cohesion, low coupling, and a clear API.

Mastering modularity is key to building maintainable and scalable Clojure applications. Keep practicing!