Любой, кто имеет некоторый опыт в программировании, судит о программном коде, написанном другими, используя параметры суждения, основанные на их карьере.
В течение своей профессиональной карьеры я знал многих разработчиков, видел тысячи строк кода, и когда мне нужно оценить навыки разработчика, я в основном смотрю на два фактора:
К счастью, есть некоторые основы или принципы, которые позволяют легко научиться программировать лучше.
аббревиатура SOLID означает:
S: принцип единоличной ответственности
O: принцип открыт-закрыт
L: Принцип подстановки Лисков
I: Принцип разделения интерфейса
D: Принцип инверсии зависимостей
Начнем с первого принципа SOLID, а именно
У класса (или модуля) должна быть только одна причина для изменения - для развития.
Сама концепция очень проста, но для достижения этой простоты путь реализации может быть очень сложным. У класса должна быть только одна причина для изменения.
Но почему?
Почему так важно иметь только одну причину для изменений?
Например, если есть две разные причины для изменения, вполне возможно, что две разные команды могут работать над одним и тем же кодом по двум разным причинам. Каждый должен будет реализовать собственное решение, которое в случае компилируемого языка (такого как C ++, C # или Java) может привести к модулям, несовместимым с другими командами или другими частями приложения.
Другой пример: если вы используете интерпретируемый язык, вам, возможно, придется повторно протестировать один и тот же класс или модуль по разным причинам. Это означает больше работы, времени и усилий для контроля качества.
Определить одну особенность, которую должен иметь класс или модуль, намного сложнее, чем просто просмотреть контрольный список для запуска тестов.
Но давайте попробуем мыслить с менее технической точки зрения, то есть попробуем проанализировать пользователя нашего класса или модуля, то есть кто будет его использовать. Фундаментальный аспект, который мы всегда должны помнить, - это тот факт, что пользователи приложения или системы, которые мы разрабатываем, которые обслуживаются определенным модулем, будут теми, кто запрашивает его модификации. Те, кого обслуживают, попросят изменить класс или модуль.
Некоторые примеры модулей и их использования:
Поэтому, если первым шагом является поиск актеров или актера, который играет роль собеседника в модуле, сопоставление людей со всеми ролями может быть трудным. В небольшой компании один человек может играть несколько ролей, в то время как в большой компании может быть несколько человек, выполняющих одну роль.
Кажется более разумным определять роли, а не людей или пользователей.
Тогда:
Посмотрим несколько примеров
Предположим, у нас есть класс Book, который инкапсулирует концепцию книги и ее функциональные возможности.
учебник {
function getTitle () {
вернуть «Великую книгу»;
}
function getAuthor () {
вернуть «Алессандро Барикко»;
}
function nextpage () {
// Следующая страница
}
function printCurrentPage () {
echo «содержимое текущей страницы»;
}
}
Это вполне нормальный класс. У нас есть книга, и класс может дать нам название, они могут дать нам автора, и они могут двигаться дальше. Наконец, он также может печатать текущую страницу на экране.
Однако есть небольшая проблема.
Если подумать об акторах, участвующих в управлении объектом "Книга", кем они могут быть?
Здесь мы можем легко представить себе двух разных действующих лиц: Управление книгами (придет il библиотекарь) И Механизм предоставления данных (например, как мы хотим доставлять контент пользователю: экранный, графический пользовательский интерфейс, текстовый пользовательский интерфейс, возможно, печать).
Таким образом, у нас есть два очень разных участника, которые взаимодействуют с классом.
Вкратце, этот класс смешивает:
это может быть проблемой, поскольку нарушает принцип единой ответственности (SRP).
Как мы можем изменить, как мы можем улучшить этот код, чтобы соблюсти принцип единоличной ответственности?
Взгляните на следующий код:
учебник {
function getTitle () {
вернуть «Oceano Mare»;
}
function getAuthor () {
вернуть «Алессандро Барикко»;
}
function turn page () {
// Следующая страница
}
function getCurrentPage () {
echo «содержимое текущей страницы»;
}
}
интерфейс Принтер {
функция printPage ($ page);
}
class StampaLibro реализует Printer {
function printPages ($ page) {
echo $ page;
}
}
class HtmlPrinter реализует Printer {
function printPages ($ page) {
эхо ' '. $ page. ' ';
}
}
Этот очень простой пример показывает, как отделить представление от бизнес-логики, и в соответствии с SRP он предлагает большие преимущества в гибкости нашего проекта.
Посмотрим на другой пример:
Пример, аналогичный приведенному выше, - это когда объект может сохранять и извлекать себя из презентации.
учебник {
function getTitle () {
вернуть «Oceano Mare»;
}
function getAuthor () {
вернуть «Алессандро Барикко»;
}
function turn page () {
// Следующая страница
}
function getCurrentPage () {
вернуть «содержимое текущей страницы»;
}
function save () {
$ filename = '/ документы /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();
file_put_contents ($ filename, сериализовать ($ this));
}
}
Как и раньше, здесь мы также можем идентифицировать различных участников, таких как Управление книгами (придет il библиотекарь) И упорство. Каждый раз, когда мы хотим изменить способ перехода от страницы к странице, нам нужно изменить этот класс. У нас может быть несколько причин для перемен.
учебник {
function getTitle () {
вернуть «Oceano Mare»;
}
function getAuthor () {
вернуть «Алессандро Барикко»;
}
function turn page () {
// Следующая страница
}
function getCurrentPage () {
вернуть «содержимое текущей страницы»;
}
}
класс SimpleFilePersistence {
функция save (книга $ книга) {
$ filename = '/ документы /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();
file_put_contents ($ filename, сериализовать ($ book));
}
}
Перенос операции сохранения состояния в другой класс четко разделит обязанности, и мы сможем свободно обмениваться методами сохранения состояния, не затрагивая наш класс Book. Например, реализация класса DatabasePersistence будет тривиальной задачей, и наша бизнес-логика, построенная на книжных операциях, не изменится.
Продолжайте читать второй принцип Открыто / Закрыто ->
Ercole Palmeri
В прошлый понедельник Financial Times объявила о сделке с OpenAI. FT лицензирует свою журналистику мирового уровня…
Миллионы людей платят за стриминговые сервисы, выплачивая ежемесячную абонентскую плату. Распространено мнение, что вы…
Coveware от Veeam продолжит предоставлять услуги по реагированию на инциденты, связанные с кибер-вымогательством. Coveware предложит возможности криминалистики и исправления…
Прогнозируемое техническое обслуживание производит революцию в нефтегазовом секторе благодаря инновационному и упреждающему подходу к управлению предприятием…
