Understanding Clean Code in Android
Прежде чем приступить к написанию кода, лучше понять, как управлять кодом и как сделать ваш код масштабируемым.
“You are reading this “article” for two reasons. First, you are a programmer. Second, you want to be a better programmer” — Robert C. Martin
Представьте, что вы в библиотеке и ищете несколько книг. Если библиотека отсортировала и классифицировала свои книги, вы найдете свои книги быстрее. Кроме того, классный дизайн интерьера и архитектура позволят вам чувствовать себя комфортно в библиотеке, пока вы ищете свои книги.
Точно так же, как написание книг, если вы хотите создать что-то великое, вы должны уметь писать и аккуратно организовывать свой код. Если у вас есть члены команды или кто-то еще, у кого есть ваш (унаследованный) код, им просто нужно увидеть имена переменных, пакеты или классы, и они сразу поймут. Им не нужно произносить «F**k» и начинать писать его заново с нуля.
What is “Clean Code”?
Что такое “Чистый код”?
Как видите, недостаточно быстро завершить разработку, если другие не могут понять ваш код, потому что это станет еще одним техническим долгом.
В вашем коде есть определение «Чистый», если его легко понять всем в команде. Чистый код может быть прочитан и улучшен разработчиком, отличным от его первоначального автора. Вместе с понятностью кода приходит читаемость, изменчивость, расширяемость и ремонтопригодность.
— Must I care about it?
Должен ли я заботиться об этом? Причина, по которой вы должны заботиться о своем коде, состоит в том, что ваш код будет описывать ваш мыслительный процесс другим. Вот почему вы должны начать думать о том, чтобы сделать ваш код более элегантным, простым и читабельным.
Characteristics of a Clean code
Характеристики чистого кода
- Your code should be elegant: Ваш код должен быть элегантным. Ваш код должен вызывать у вас улыбку, как у хорошо продуманной музыкальной шкатулки или хорошо спроектированной машины.
- Your code has been taken care of: О вашем коде позаботились. Кто-то нашел время, чтобы сохранить его простым и упорядоченным. Уделил должное внимание деталям и позаботился о нем.
- Your code has to be focused: Ваш код должен быть сфокусирован. Каждая функция, каждый класс, каждый модуль демонстрируют целеустремленное отношение, которое остается совершенно не отвлеченным и не загрязненным окружающими деталями.
- Contains no duplication. Не содержит дублирования.
- Runs all the tests. Выполняются все тесты .
- Minimize the number of entities such as classes, methods, functions, and the like. Минимизируйте количество объектов, таких как классы, методы, функции и тому подобное.
Одно из различий между умным программистом и профессиональным программистом заключается в том, что профессионал понимает, что ясность - это главное. Профессионалы используют свои способности во благо и пишут код, понятный другим. - Роберт С. Мартин
Create Meaningful Names
Создавайте значимые имена. Выбор хороших имен требует времени, но экономит больше, чем требуется. Имя переменной, функции или класса должно отвечать на все большие вопросы. Он должен рассказать вам, почему он существует, что он делает и как он используется. Если имя требует комментария, то имя не раскрывает его намерения.
Давайте рассмотрим пример:
— Class Names
Имена классов. Классы и объекты должны иметь имена существительных или имен существительных, таких как Customer, WikiPage, Account и AddressParser. Избегайте таких слов, как Manager, Processor, Data или Info в названии класса. Имя класса не должно быть глаголом.
— Method Names
Имена методов. Методы должны иметь имена глагола или глагольные фразы, такие как PostPayment, DeletePage или Save. Аксессоры, мутаторы и предикаты должны быть названы по их значению и иметь префикс Get, Set и соответствует стандарту конкретного языка.
— Use Problem Domain Names
Используйте проблемные доменные имена. Если для того, что вы делаете, нет “программиста ( programmer-eese)” , используйте имя из проблемного домена. По крайней мере, программист, который поддерживает ваш код, может спросить эксперта по домену, что это значит.
Прежде чем мы продолжим, сделайте перерыв и сделайте кофе или перекусите. : D
Хорошо, теперь мы продолжаем писать код, используя принципы S.O.L.I.D.
Writing your code using S.O.L.I.D Principles
Написание кода с использованием принципов S.O.L.I.D. Эти принципы придуманы Робертом К. Мартином (дядя Боб). SOLID — это термин, описывающий набор принципов проектирования для хорошего кода.
Single Responsibility Principle — SRP
Принцип единой ответственности — SRP. Это означает, что каждый класс должен нести одну ответственность. Никогда не должно быть более одной причины для изменения класса. То, что вы можете добавлять в свой класс все, что вы хотите, не означает, что вы должны это делать. Разделите большие классы на более мелкие и избегайте классов Бога.
Давайте рассмотрим пример:
У нас есть RecyclerView.Adapter с бизнес-логикой внутри onBindViewHolder.
Это делает RecyclerView.Adapter не имеющим единой ответственности, потому что он имеет бизнес-логику внутри onBindViewHolder. Этот метод отвечает только за настройку данных своего представления.
Open-Closed Principle — OCP
Принцип открытости-закрытости. Программные объекты должны быть открыты для расширения, но закрыты для модификации. Это означает, что если вы пишете класс A, а затем ваши товарищи по команде хотят внести изменения в функцию внутри класса A, то они могут легко сделать это, расширив класс A, вместо того, чтобы вносить изменения в класс A.
Простым примером будет класс RecyclerView.Adapter. Вы можете легко расширить этот класс и создать собственный настраиваемый адаптер с настраиваемым поведением, не изменяя существующий класс RecyclerView.Adapter.
Liskov Substitutions Principle — LSP
Дочерние классы никогда не должны нарушать определения типов родительского класса.
Это означает, что подкласс должен переопределять методы родительского класса, которые не нарушают функциональность родительского класса. Например, вы создаете интерфейсный класс с событием onClick(), а затем подписываетесь на него в MyActivity и назначаете ему всплывающее действие при вызове onClick().
Interface Segregation Principle — ISP
Принцип разделения интерфейса (ISP) гласит, что ни один клиент не должен зависеть от методов, которые он не использует.
Это означает, что если вы хотите создать класс A и реализовать его в другом классе (класс B), он не должен переопределять все методы класса A внутри класса B. Чтобы сделать его понятным и простым для понимания.
Давайте рассмотрим пример: внутри вашего activity вам нужно реализовать SearchView.OnQueryTextListener() и метод onQuerySubmit().
Как этого добиться? Просто напросто вы создаете событие обратного вызова и класс расширяется на SearchView.OnQueryTextListener().
А вот как это реализовать в вашем View:
Или, если вы используете Kotlin, вы можете использовать функцию расширения:
И, наконец, вот как это реализовать:
Dependency Inversion Principle — DIP
Код зависит от абстракций и не зависит от конкреции.
Определение дядей Бобом принципа инверсии зависимостей состоит из двух пунктов:
- Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций.
- Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Модули высокого уровня, которые обеспечивают сложную логику, должны легко использоваться повторно и не подвергаться изменениям в модулях низкого уровня, которые предоставляют служебные функции. Чтобы достичь этого, вам нужно ввести абстракцию, которая отделяет модули высокого и низкого уровня друг от друга.
Простой пример — шаблон MVP, у вас есть объект интерфейсов, который помогает нам взаимодействовать с конкретными классами. Это означает, что классам пользовательского интерфейса (Activity / Fragment) не нужно знать фактическую реализацию методов в Presenter. Классы пользовательского интерфейса не должны знать или заботиться об изменениях.
Давайте посмотрим на это в следующем примере кода:
Теперь давайте посмотрим на это в UserActivity:
Мы создаем интерфейс, который абстрагирует реализацию presenter, и наш класс представления сохраняет ссылку на PresenterInterface.
Conclusion
Заключение. Зрелые программисты знают, что идея о том, что все является объектом, является мифом. Иногда вам действительно нужны простые структуры данных с процедурами, работающими с ними. С этого момента вы должны начать думать о том, как именно реализовать задачу и о будущей перспективе вашего кода, который будет легко обновить.
Я знаю, что если вы уже создали приложение с бессмысленными именами, классами Бога, кодом для спагетти, поверь мне, я сделал то же самое. Вот почему я делюсь с вами своими знаниями о чистом коде от дяди Боба, и это также является для меня напоминанием, и я надеюсь, что помог вам понять это.
Happy Coding :)
Перевод статьи: medium
