0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: методы, классы, android-разработчик, чистый код, программирование на android, принципы solid, имена, srp, ocp, lsp, isp, dip</p>
1
<p>Теги: методы, классы, android-разработчик, чистый код, программирование на android, принципы solid, имена, srp, ocp, lsp, isp, dip</p>
2
<p>Как сказал Роберт С. Мартин:<em>"Вы читаете эту статью по двум причинам. Во-первых, вы программист. Во-вторых, вы хотите программировать лучше".</em></p>
2
<p>Как сказал Роберт С. Мартин:<em>"Вы читаете эту статью по двум причинам. Во-первых, вы программист. Во-вторых, вы хотите программировать лучше".</em></p>
3
<p>Если вы действительно хотите стать<strong>продвинутым Android-разработчиком</strong>, вы должны научиться писать<strong>чистый код</strong>. Но прежде чем его написать, следует понять, как он будет масштабироваться и управляться.</p>
3
<p>Если вы действительно хотите стать<strong>продвинутым Android-разработчиком</strong>, вы должны научиться писать<strong>чистый код</strong>. Но прежде чем его написать, следует понять, как он будет масштабироваться и управляться.</p>
4
<p>В библиотеке вы быстро найдёте нужную книгу только в том случае, если все они<strong>классифицированы и отсортированы</strong>. То же самое и с кодом: он должен быть аккуратно организован. Тогда любой посторонний Android-разработчик, увидев имена переменных, классов и пакетов, легко всё поймёт. И не будет ругаться, начиная проект с нуля.</p>
4
<p>В библиотеке вы быстро найдёте нужную книгу только в том случае, если все они<strong>классифицированы и отсортированы</strong>. То же самое и с кодом: он должен быть аккуратно организован. Тогда любой посторонний Android-разработчик, увидев имена переменных, классов и пакетов, легко всё поймёт. И не будет ругаться, начиная проект с нуля.</p>
5
<h2>Что же такое "чистый код"?</h2>
5
<h2>Что же такое "чистый код"?</h2>
6
<p>Его можно назвать таковым, если он понятен всей команде, что позволяет его прочитать и улучшить.</p>
6
<p>Его можно назвать таковым, если он понятен всей команде, что позволяет его прочитать и улучшить.</p>
7
<p><strong>Характеристики</strong>: - код элегантен, как хорошо сделанная музыкальная шкатулка; - код прост, читабелен и упорядочен, уделено внимание деталям; - код сфокусирован, то есть каждый класс, модуль или функция выполняют свою конкретную задачу; - в коде отсутствуют дубликаты; - код работает на всех тестах; - код имеет минимально возможное количество объектов: классов, методов, функций и т. п.</p>
7
<p><strong>Характеристики</strong>: - код элегантен, как хорошо сделанная музыкальная шкатулка; - код прост, читабелен и упорядочен, уделено внимание деталям; - код сфокусирован, то есть каждый класс, модуль или функция выполняют свою конкретную задачу; - в коде отсутствуют дубликаты; - код работает на всех тестах; - код имеет минимально возможное количество объектов: классов, методов, функций и т. п.</p>
8
<p>Профессионал понимает, что<strong>чистота кода - это главное</strong>, поэтому он пишет код, понятный другим. Предлагаем вам ознакомиться с рядом советов, которые помогут вам написать качественный код.</p>
8
<p>Профессионал понимает, что<strong>чистота кода - это главное</strong>, поэтому он пишет код, понятный другим. Предлагаем вам ознакомиться с рядом советов, которые помогут вам написать качественный код.</p>
9
<h2>Задавайте уместные имена</h2>
9
<h2>Задавайте уместные имена</h2>
10
<p>Да, на выбор хороших имён вы потратите время, но выгода будет очевидна. Рекомендуется, чтобы имя функции, класса либо переменной отвечало на такие важные вопросы, как и зачем это нужно, что это делает, каким образом используется. Если для понимания имени его нужно комментировать - это плохое имя.</p>
10
<p>Да, на выбор хороших имён вы потратите время, но выгода будет очевидна. Рекомендуется, чтобы имя функции, класса либо переменной отвечало на такие важные вопросы, как и зачем это нужно, что это делает, каким образом используется. Если для понимания имени его нужно комментировать - это плохое имя.</p>
11
<p>К примеру:</p>
11
<p>К примеру:</p>
12
// Неудачное название переменных var a = 0 // user ages var w = 0 // user weight var h = 0 // user height // Неудачное название функций fun age() fun weight() fun height() // Неудачное название классов для получения пользовательских данных class UserInfo // Неплохие варианты названия переменных var userAge = 0 var userWeight = 0 var userHeight = 0 // Прекрасные варианты названия функций fun setUserAge() fun setUserWeight() fun setUserHeight() // Прекрасный вариант названия класса для получения пользовательских данных class Users()<h3>Имена классов</h3>
12
// Неудачное название переменных var a = 0 // user ages var w = 0 // user weight var h = 0 // user height // Неудачное название функций fun age() fun weight() fun height() // Неудачное название классов для получения пользовательских данных class UserInfo // Неплохие варианты названия переменных var userAge = 0 var userWeight = 0 var userHeight = 0 // Прекрасные варианты названия функций fun setUserAge() fun setUserWeight() fun setUserHeight() // Прекрасный вариант названия класса для получения пользовательских данных class Users()<h3>Имена классов</h3>
13
<p>При именовании и объектов, и классов нужно использовать<strong>существительные</strong>либо фразы из существительных, к примеру<strong>WikiPage</strong>,<strong>Account</strong>,<strong>Customer</strong>,<strong>AddressParser</strong>. Избегайте слов Processor, Data, Manager, Info. Имена класса<strong>не должны быть глаголами</strong>.</p>
13
<p>При именовании и объектов, и классов нужно использовать<strong>существительные</strong>либо фразы из существительных, к примеру<strong>WikiPage</strong>,<strong>Account</strong>,<strong>Customer</strong>,<strong>AddressParser</strong>. Избегайте слов Processor, Data, Manager, Info. Имена класса<strong>не должны быть глаголами</strong>.</p>
14
<h3>Имена методов</h3>
14
<h3>Имена методов</h3>
15
<p>А вот методы лучше называть глаголами или глагольными фразами, например deletePage(), save(), postPayment(). Предикаты, аксессоры и мутаторы называются по их значению, имеют префикс set, get, соответствуют стандарту<strong>JavaBean</strong>.</p>
15
<p>А вот методы лучше называть глаголами или глагольными фразами, например deletePage(), save(), postPayment(). Предикаты, аксессоры и мутаторы называются по их значению, имеют префикс set, get, соответствуют стандарту<strong>JavaBean</strong>.</p>
16
<h3>Для задач используйте доменные названия</h3>
16
<h3>Для задач используйте доменные названия</h3>
17
<p>Не можете выбрать название задачи? Используйте доменные названия! Не худший вариант, так как разработчик, поддерживающий ваш код, сможет спросить специалиста по домену, что оно означает.</p>
17
<p>Не можете выбрать название задачи? Используйте доменные названия! Не худший вариант, так как разработчик, поддерживающий ваш код, сможет спросить специалиста по домену, что оно означает.</p>
18
<h2>Пишите код с использованием принципов S.O.L.I.D.!</h2>
18
<h2>Пишите код с использованием принципов S.O.L.I.D.!</h2>
19
<p>SOLID является термином, описывающим принципы проектирования хорошего кода. Принципы придуманы Робертом К. Мартином. Давайте их перечислим: 1.<strong>SRP</strong>- принцип единой ответственности. Каждый класс отвечает за что-то одно. 2.<strong>OCP</strong>- принцип Открытости-Закрытости - объекты программы должны быть открыты для расширения, однако закрыты для модификации. 3.<strong>LSP</strong>- принцип подстановки Барбары Лисков. Дочерние классы не должны нарушать определения типов родительского класса. 4.<strong>ISP</strong>- принцип разделения интерфейса. Ни один клиент не должен зависеть от тех методов, которые он не использует. 5.<strong>DIP</strong>-принцип инверсии зависимостей, который определяется двумя пунктами: - модули высокого уровня не должны зависеть от модулей низкого уровня, при этом оба модуля должны зависеть от абстракций; - абстракции не должны зависеть от деталей, но детали должны зависеть от абстракций.</p>
19
<p>SOLID является термином, описывающим принципы проектирования хорошего кода. Принципы придуманы Робертом К. Мартином. Давайте их перечислим: 1.<strong>SRP</strong>- принцип единой ответственности. Каждый класс отвечает за что-то одно. 2.<strong>OCP</strong>- принцип Открытости-Закрытости - объекты программы должны быть открыты для расширения, однако закрыты для модификации. 3.<strong>LSP</strong>- принцип подстановки Барбары Лисков. Дочерние классы не должны нарушать определения типов родительского класса. 4.<strong>ISP</strong>- принцип разделения интерфейса. Ни один клиент не должен зависеть от тех методов, которые он не использует. 5.<strong>DIP</strong>-принцип инверсии зависимостей, который определяется двумя пунктами: - модули высокого уровня не должны зависеть от модулей низкого уровня, при этом оба модуля должны зависеть от абстракций; - абстракции не должны зависеть от деталей, но детали должны зависеть от абстракций.</p>
20
<p>Значительно повысить свой уровень в написании кода вы сможете на продвинутом курсе "<a>Android-разработчик</a>". Не пропустите!</p>
20
<p>Значительно повысить свой уровень в написании кода вы сможете на продвинутом курсе "<a>Android-разработчик</a>". Не пропустите!</p>
21
<p><em>Статья подготовлена специально для OTUS на основании материала "<a>Understanding Clean Code in Android</a>".</em></p>
21
<p><em>Статья подготовлена специально для OTUS на основании материала "<a>Understanding Clean Code in Android</a>".</em></p>
22
22