> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/general-paradigms/principles/locality-of-behaviour.md).

# locality of behaviour

* Design pattern
* Focuses on the idea:
  * The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code
* The idea of cohesion
* Generally conflicts with DRY and Separation of concerns
* Helps reduce complexity, by keep code in one place or closer together instead of being separated
* organizing and structuring software components in a way that maximizes the coherence and proximity of related functionality
* locality of behavior suggests that modules or components should contain and manage related functionality in a cohesive manner.

## Why

* reduce dependencies and improve the efficiency and understandability of the software system.
* it reduces the need for long-range communication or extensive data exchange between distant components, which can introduce complexity, decrease performance, and make the system harder to maintain.
* promotes high cohesion, where each component or module focuses on a single, well-defined responsibility or functionality. This improves code readability, maintainability, and reusability.
* Reduced Coupling: By organizing components based on their related behavior, the principle helps reduce unnecessary dependencies between components. Looser coupling enhances the flexibility and modularity of the software system, making it easier to modify or replace individual components without affecting the entire system.
* Performance Optimization: Locality of behavior can contribute to better performance by minimizing long-distance data access or communication. When related code or data is placed closer together, it reduces the need for frequent context switching and improves data caching efficiency.
* enhances the system's comprehensibility. Developers can more easily understand and reason about the codebase because related functionality is grouped together, making it easier to follow the flow of data and control.
* simplifies the process of maintaining and debugging software. When a bug or issue arises, developers can more quickly locate and isolate the relevant components, reducing the time and effort required for troubleshooting.

## Disadvantages

* there is a possibility that similar or related functionality might be duplicated across different components. This can lead to code redundancy, increased maintenance effort, and a higher chance of introducing inconsistencies if the duplicated code is not properly managed
* can sometimes lead to rigid component designs that are tightly coupled. This can limit the flexibility and reusability of individual components since they may become highly dependent on specific contexts or interdependencies within the system
* Determining the appropriate boundaries for components based on locality of behavior can be challenging. It requires careful analysis and understanding of the system's requirements and dynamics. If the boundaries are not chosen correctly, it may result in either overly large components with low cohesion or overly small components with excessive inter-component communication overhead.
* it is not always the most optimal design principle in every situation. In some cases, enforcing strict locality of behavior may result in trade-offs that negatively impact overall performance. For example, breaking up highly cohesive components into smaller ones may introduce additional overhead due to increased inter-component communication.
* In large and complex software systems, enforcing strict locality of behavior can become challenging. As the system grows, maintaining a clear and consistent organization of related functionality might become more difficult. This can lead to increased complexity and decreased understandability, especially for developers who are new to the system.

## Links

* <https://htmx.org/essays/locality-of-behaviour/>
* <https://www.eloquentarchitecture.com/locality-of-behavior/>
* <https://dev.to/ralphcone/new-hot-trend-locality-of-behavior-1g9k>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hanfak.gitbook.io/workspace/general-paradigms/principles/locality-of-behaviour.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.