Registry.instance.endpoint_for("myservice")
ConfigrationStore.instance.get("password")

XMLServiceAdapter.new(xml_serv).call(json)
DatabaseORM.new(connection).all_users

CloudFacade.start_vm('ubuntu', ports: [80])

SubscriberNotificationDecorator.new(blog_post).publish

input_element.add_change_listener(handler)

self.current_state.handle_play_pause_button

if (self.can_fish?) {
self.drive_to_lake; self.fish(lake)
}

price = total + tax_strategy.calc(total)
model.serializer_strategy.convert(values)

def create_configuration_store {
return Hash.new
}

current_os.gui_factory.create_button()

Don't Repeat Yourself

DRY ensures that every piece of knowledge has a single source of truth.

useful because assumptions, requirements and implementations always change.

avoid duplication in classes, comments, data schema and configuration.

violation

class Line {
attr_accessor :x1, :y1, :x2, :y2, :length
}

• prevents bugs from unknown code dependencies
• averts inconsistent data or config
• avoids outdated docs & comments
• introduces indirections making it harder to reason

Premature Optimization

Weighing the benefits of optimization maximizes business value.

useful because we only have limited resources for a project.

avoid optimization areas of low impact or growth.

violation
introduce a cluster deployment when the server is mostly idle.

• frees staff to satisfy customer needs
• prevents layers of complexity too early
• iteratively measuring focuses effort on areas with most impact
• lack of consideration may lead to fundamental design flaws or performance issues when scaling
• refactoring for optimization may also improve maintainability

Single Responsibility

Keeping classes to a single responsibility reduces effort by isolating changes.

useful because requirements evolve along different axes.

avoid mixing responsibilities that are changed by different individuals/groups.

violation

employee.calculate_pay
employee.store_in_db

• decouples implementations based on what is likely to change together
• lowers efforts for building & testing
• prevents side-effects concerning other responsibilities during modifications
• keeps dependencies to a minimum when re-using classes
• introduces needless complexity when followed to strictly

High Cohesion

High cohesion balances module complexity and coupling to group only related functions together.

useful because changing overloaded classes is risky.

avoid combining methods without unifying purpose or concept.

violation
a utility class

• reduces module complexity due to its restricted scope
• increases maintainability & testability because changes affect smaller classes
• improves reusability because modules provide independent building blocks
• assesses cohesion types: coincidence (worst), logic, time, procedure, data, sequence, function (best)

Loose Coupling

Loose coupling minimizes the knowledge required to use another class.

useful because autonomous components are easier to reuse and cheaper to adapt.

avoid large class signatures, accessing internals & bi-directional dependencies.

violation

def send_letter(user) {
address = user.db_row.first_name + ...
}

• reduces impact of changes and replacements
• facilitates reuse of components by leveraging general interfaces
• promotes interchangeability & testability by hiding details
• reduces amount of information passed
• tempts to over-engineer

Encapsulation

Encapsulation hides information about the internal representation of an object.

useful because implementation strategies are likely to change.

avoid direct access to classes' members.

violation

y = point.coordinates_floats[1]

• eases use by separating how to use the class from its implementation
• reduces complexity by hiding details
• protects the class's integrity by controlling access to its fields
• encourages testing & reuse by limiting dependencies between components
• stabilizes interfaces by limiting them
• allows improving implementations without affecting class users

Abstraction

Abstraction generalizes a class by reducing it to its essential concept.

useful because mental capacity is limited.

avoid copying code more than twice.

violation

teacher.postgres_storage.age += 0.7

• offers simpler, higher-level classes focussing on their purpose
• limits the range of concepts to be aware of
• facilitates reuse by making classes universal
• hides complexity by removing details
• tempts to introduce unnecessary complexity
• may leak concrete implementation details or prevent fixing them

Open & Closed

The

open & closed principle allows extension without changing existing code.

useful because modifying working code introduces risk.

avoid remodeling classes in use.

violation
global variables

• limits scope of changes through early anticipation of possible extensions
• allows reuse by designing stable interfaces
• improves maintainability & testing by confining work to new classes
• reduces bugs by leaving existing code alone
• requires experience to predict & balance useful abstractions
• must be broken to introduce unforeseen extensions

Separation of Concerns

Separating concerns focusses classes on one aspect or topic.

useful because large classes overwhelm.

avoid writing giant methods or classes.

violation

ui_widget.title = account.balance + transfer.amount

• simplifies reuse, testing & maintenance by splitting responsibilities
• insulates classes from failures by introducing clear boundaries
• allows replacing behaviour without the need to understand related classes
• lowers cognitive load by isolating topics
• focusses attention upon a single aspect
• may introduce more complexity/code than the separation is worth

Keep It Simple, Stupid

KISS implements the solution in the easiest way possible

useful because familiarity with the current context fades over time.

avoid adding complexity for making it more beautiful.

violation

additionService.instance.process(1, 2)

• focusses the solution on the problem at hand
• improves readability by reducing the number of concepts to remember
• employs well-known patterns to leverage common knowledge
• keeps code simple enough that anyone on the team can understand it
• may be used as an excuse to neglect code health

You Ain't Gonna Need It

YAGNI delays adding functionality until it is absolutely necessary.

useful because upfront planning often fails to project the future accurately.

avoid investing into structures that will only pay off later.

violation
presumptive features

• reduces time and effort spent on functionality that brings no value
• shortens time to market by easing analysis, implementation & testing
• improves velocity due to reduced scope, complexity & unused code
• maximizes the time to learn from (less complex) architectures
• keeps the cost of wrong projections to a minimum

Dependency Inversion

Dependency Inversion lets higher-level classes prescribe lower-level interfaces.

useful because lower-level classes change more often than higher-level ones.

avoid declaring direct dependencies from top to bottom.

violation

def highlevel_method() {
LowLevel.new(1,2,3)
}

• encourages reusability of high-level classes by dynamically injecting classes
• eases low-level changes by allowing to swap implementations
• simplifies code by being able to uniformly work with alternate classes
• steers the design process away from low-level details
• improves testability
• adds complexity for generalization

Convention over Configuration

Convention over Configuration provides structural & configurational defaults.

useful because learning a technology's specifics may be overwhelming.

avoid explicitly asking for non-essential configuration choices.

violation

class Sale < DatabaseModel {
table_name 'sales'
}

• lowers the barrier to learn a new technology or project through common structures
• decreases the number of decisions to be made by the developer
• retains flexibility because defaults can be overridden
• reduces the amount of redundant code
• leads to adhering to conventions when another approach is more appropriate