Clean Architecture
PART III Design Principles
Chapter 7 – 9
Robert C. Martin
Glossary
1. Assertion [əˈsɜːʃᵊn] – is a statement that is used to ensure that certain conditions are met during
the execution of a program. (Утверждение)
2. Axis of Change [ˈæksɪs ɒv ʧeɪnʤ] - refers to the parts of a software system that are most likely
to change frequently over time. By identifying these areas, developers can focus their efforts on
optimizing them for flexibility and maintainability, and reduce the risk of causing unintended
side effects when making changes. (Ось изменений)
3. Components [kəmˈpəʊnənts] - is a self-contained, reusable unit of software that performs a
specific set of functions. (Компоненты)
4. Controller [kənˈtrəʊlə] – is a component that manages the flow of data between the model and
the view components of an application. (Контроллер)
5. Class [klɑːs] - is a fundamental building block of object-oriented programming (OOP). A class is a
blueprint, or template, for creating objects that have similar characteristics or functionality. It is
a logical entity that defines a set of attributes and methods that are common to all instances of
the class. (Класс)
6. CFO [siː-ɛf-əʊ] (Chief Financial Officer) - refers to the senior executive responsible for managing
the financial operations and strategies of an IT organization. (Финансовый директор)
7. COO [siː-əʊ-əʊ] (Chief Operating Officer) – person who is responsible for overseeing the day-today operations of an organization. (Главный операционный директор)
8. CTO [siː-tiː-əʊ] (Chief Technology Officer) - is an executive-level position within an organization
responsible for overseeing and managing the technology strategy, research and development
(R&D) activities, and technology-related operations. (Технический директор)
9. CCP [siː-siː-piː] (Common Closure Principle) - in design interface typically stands for "ClickChange-Press". It is a commonly used design pattern where users click on an element, see a
change in the interface, and then need to press a button or confirm the change to complete
their action. (Общий принцип закрытия)
10. DBA [diː-biː-eɪ] (Database Administrator) - is a skilled professional who is responsible for the
installation, configuration, maintenance, and monitoring of databases. (Администратор базы
данных)
11. Facade pattern [fəˈsɑːd ˈpætən] - is a design pattern that provides a simplified interface for a
complex system of software components. The pattern is designed to hide the complexity of the
system and provide a simpler interface to clients or users. (Шаблон проектирования)
12. Footer [ˈfʊtə] – is a section of a file or document that appears at the end, and typically contains
additional information or data about the contents of the file or document. (Нижний
колонтитул)
13. Header [ˈhɛdə] – is a section of a file or message that contains metadata or other information
about the content that follows it. (Верхний колонтитул)
14. Implement [ˈɪmplɪmənt] - is a verb that means to translate a design or specification into code
that can be executed on a computer. (Внедрять)
15. Inheritance [ɪnˈhɛrɪtəns] – is a fundamental concept in object-oriented programming (OOP),
wherein a class can derive from (or inherit) the properties and behavior of another class.
(Наследование)
16. Interactor [ˌɪntərˈæktə] - is a design pattern that is used to encapsulate a single use case or
operation in an application. (Взаимодействующий фактор)
17. Java-style [ˈʤɑːvə-staɪl] – several naming conventions for interfaces.
18. Module [ˈmɒʤuːl] - is a self-contained unit of software that performs a specific function and can
be implemented independently from other modules. (Модуль)
19. OCP [əʊ-siː-piː] (Open-Closed Principle) - states that software entities (classes, modules,
functions) should be open for extension but closed for modification. This means that the
behavior of software components should be able to be modified or extended without changing
the existing code. (Принцип "Открыто-закрыто")
20. OOP [əʊ-əʊ-piː] (Object oriented programming)- is a programming paradigm that models realworld concepts through software objects. It focuses on reusability, encapsulation, inheritance,
and polymorphism to create modular code. (Объектно-ориентированное программирование)
21. Presenters [prɪˈzɛntəz] - is a design pattern that separates the presentation logic from the user
interface (UI) logic in a user interface (UI). (Докладчики)
22. REST [rɛst] (Representational State Transfer) – is a software architectural style that defines a set
of constraints for creating web services. (Передача представительского статуса)
23. Ruby [ˈruːbi] - is a programming language that was created by Yukihiro Matsumoto in the mid1990s. It is an object-oriented language that is known for its simple and elegant syntax, as well
as its focus on productivity and expressiveness.
24. Software [ˈsɒftweə] - refers to a set of instructions or programs that tell a computer what to do,
or in other words, a collection of computer programs, procedures, and documentation that
perform specific tasks on a computer system. (Программное обеспечение)
25. SOLID [ˈsɒlɪd] (Single responsibility, Open-closed, Liskov substitution, Interface segregation,
Dependency inversion) - five object-oriented programming principles, designed to make
software development more organized, scalable, and maintainable.
26. Source code [sɔːs kəʊd] – refers to the human-readable representations of computer programs
that are written in a specific programming language (Исходный код)
27. SRP [ɛs-ɑː-piː] (Single Responsibility Principle) - states that a class should have only one reason
to change. In other words, a class should have only one responsibility, or only one specific
purpose to accomplish. This principle encourages developers to create classes that are focused
and do not have multiple unrelated responsibilities. (Принцип единой ответственности)
28. Superclass [ˌsuːpəˈklɑːs] – is the parent class from which one or more child classes inherit
properties and behaviors. (Суперкласс)
29. Transitive dependency [ˈtrænsɪtɪv dɪˈpɛndənsi] - refers to a situation where a library or package
used by an application depends on another library, which in turn depends on yet another library,
and so on. (Переходная зависимость)
30. URL [juː-ɑːr-ɛl] (Uniform Resource Locator)- is string of characters that identifies the location of a
resource on the internet.
31. View [vjuː] – is model of a representation of data that is displayed to a user or system. (Вид)
Summary
Сhapter 7 (SRP: THE SINGLE RESPONSIBILITY PRINCIPLE)
SRL is a principle that functions should have only one specific purpose which is usually applied to
break down large functions into smaller ones, like the Single Responsibility Principle (SRP).
The historical definition of the Single Responsibility Principle (SRP) asserts that a module should
have only one motive for being changed - which is usually for the satisfaction of users and stakeholders.
The terms 'user' and 'stakeholder' are ill-suited in describing the Single Responsibility Principle
(SRP) since changes in the system usually involve a group of people and not just one person or entity;
hence the term 'actor' is used, resulting in the finalized version of the principle dictating that a module
should be accountable to one and only one actor.
The term "module" typically refers to a source file but it can also refer to a set of cohesive
functions and data structures that abide by the Single Responsibility Principle (SRP). Violating the SRP
can lead to undesirable effects, so it's important to focus on cohesion to ensure that code remains
responsible to a single actor.
The Employee class example from a payroll application illustrates the violation of the Single
Responsibility Principle where the three methods, calculatePay(), reportHours(), and save() that belong
to three different actors are kept in the same class, making them dependent on each other; thus, any
modification made to one method can unexpectedly affect the performance of the other methods and
as a result, cause financial losses.
Keeping different methods in a single source file that is responsible for multiple actors can lead
to frequent merges that are risky and can result in unexpected changes that jeopardize projects, leading
to financial loss.
The most straightforward solution of problem is to separate the data from the functions into
three different classes that do not know about each other. This ensures that there is no accidental
duplication of code. However, it requires the developers to keep track of all three classes. The Facade
pattern can be used to alleviate this issue. Another solution is to keep the most important business rules
in the original Employee class and use it as a Facade for the lesser functions. Each of these classes would
contain multiple private methods, and they would form a scope that only exists within the class. It is
important of organizing code in a way that is easy to manage and avoids duplication.
The Single Responsibility Principle has two other forms at different levels - the Common Closure
Principle at the component level and the Axis of Change at the architectural level.
Chapter 8 (OCP: THE OPEN-CLOSED PRINCIPLE)
The Open-Closed Principle states that a software artifact should be designed to allow for
extension without modifying its existing code, emphasizing the importance of maintainability and
minimizing the impact of changes.
The reason for studying software architecture is that if small changes in requirements lead to
significant changes in software, it signifies a failure in the design of the software system.
For example, stakeholders request a financial summary to be turned into a report with different
formatting requirements, and highlights the importance of a good software architecture to minimize the
amount of old code that has to be changed in response to new requirements. The objective is to have
close to zero changed code in such scenarios.
To minimize the amount of changed code in response to new development requirements,
software architecture involves implementing the Single Responsibility Principle to separate aspects that
tend to change for different reasons and then organizing the dependencies between those aspects
according to the Dependency Inversion Principle. By applying the SRP to a financial reporting application,
the generation of the report was separated into two different responsibilities: the calculation of the
reported data and the formatting of the information.
To prevent changes in one aspect of the software system from causing changes in another
aspect, and to ensure extensibility, we organize the source code dependencies by partitioning the
processes into classes and separating those classes into components. Each component is responsible for
a specific responsibility, such as the Controller, Interactor, Database, and Presenters/Views.
The Interactor has a privileged position in the partitioning due to its adherence to the OpenClosed Principle (OCP), which means that changes in other components, such as the Database or the
Controller, do not affect it.
Architects divide functionality based on how, why, and when it changes, and then organize that
divided functionality into a hierarchy of components. Higher-level components in that hierarchy are
protected from the changes made to lower-level components.
Transitive dependencies are a violation of the general principle that software entities shouldn't
be dependent on things they don't directly use.
The OCP is a principle that aims to create a system that is easy to extend without causing high
impact of change, by partitioning the system into components and arranging them into a dependency
hierarchy to protect higher-level components from changes in lower-level components.
Chapter 9(LSP: THE LISKOV SUBSTITUTION PRINCIPLE)
The Liskov Substitution Principle (LSP) defines subtypes by requiring that if an object of type S
can be substituted by an object of type T in a program P, with unchanged behavior of P, then S is a
subtype of T.
The License class has a calcFee() method which is used by the Billing application, and its two
subtypes, PersonalLicense and BusinessLicense, conform to the LSP, as they use different algorithms to
calculate the license fee.
The square/rectangle problem is a violation of the LSP because a Square is not a proper subtype
of a Rectangle due to differences in their mutability of height and width, which can lead to confusion for
the User, making them not substitutable. To defend against this violation, mechanisms must be added to
the User to detect whether the Rectangle is a Square.
LSP is principle of software design that focuses on interfaces and implementations, where LSP is
applicable to various forms of interfaces, including Java-style interface, Ruby classes, and REST interface.
The violation of LSP can affect the architecture of the system.
For example, can be a situation of violation of the LSP, where dispatch services need to conform
to the same REST interface, and a change in one company's naming convention can lead to special cases
and the addition of if statements in the system, which can cause security breaches and errors. The best
way to insulate the system from errors like this is to create a dispatch command creation module driven
by a configuration database, which can handle variations in the dispatch URI and format.
The LSP should be applied to the architecture level as a violation of its substitutability principle
can lead to the introduction of extra mechanisms that pollute the system's architecture.
Chapter 10 (ISP: THE INTERFACE SEGREGATION PRINCIPLE)
The Interface Segregation Principle (ISP) aims to segregate operations into interfaces to avoid
dependencies between the classes and the operations they don't use, which can cause issues like
recompilation and redeployment of the source code; hence, segregating the operations to interfaces can
optimize the system and avoid unnecessary dependencies between classes and their supporting
operations.
The implementation of the ISP is crucially dependent on language type, where statically typed
languages, like Java, create source code dependencies that force recompilation and redeployment, while
dynamically typed languages, like Ruby and Python, infer the dependencies at runtime, leading to more
flexible and less tightly coupled systems. This could lead to the conclusion that the ISP is a language
issue, rather than a matter of software architecture.
The ISP helps to avoid depending on modules that contain more than necessary, which can harm
the system's architecture at both the source code and a higher architectural level, where unnecessary
dependencies can lead to recompilation and redeployment of the entire system, or even cause failures in
critical features.
This principle applies to architecture, where including a framework that depends on a database
with unnecessary features can create similar issues.
The takeaway from the discussion of LSP and ISP is that depending on something that contains
unnecessary elements can cause unexpected issues.
url: https://share.homew.keenetic.pro/papers/martin2017clean.pdf
Ваша задача - прочитать научные статьи на английском языке (тема статей - ваша
профессиональная область).
Общий объём прочитанного - 20,000 символов (без пробелов) - это может быть одна большая
статья или несколько статей поменьше. Далее вы оформляете всё в отдельный файл следующим
образом: 1. Текст статьи 2. Summary (краткое изложение основных положений статьи; если не
уверены, как писать summary - погуглите или прочтите вот этот файл:
http://courses.washington.edu/ordinary/summary.pdf ) 3.Структура статьи (abstract, introduction и т.
д.). Вот этот файл может помочь: https://www.bates.edu/biology/files/2010/06/How-to-Write-Guidev10-2014.pdf 4. Глоссарий (выписываете ключевые термины, которые встречаете в статьях минимум 20 штук из всех статей). Структура глоссария: термин на английском - фонетическая
транскрипция - дефиниция на английском языке - перевод термина на русский.