Джефф Бэй ввел термин объектная художественная гимнастика в своей книге Антология мыслительных работ. Это набор передовых практик и правил программирования, которые могут улучшить качество нашего кода.
Я впервые увидел эти методы, когда Rafael Dohms и Guilherme Blanco проделали большую работу по их адаптации с языка Java на PHP. Если вы пишете код на PHP и не разбираетесь в объектной художественной гимнастике, я рекомендую две из сделанных ими презентаций:
Ваш код - отстой, давайте исправим Object Calisthenics в приложении к PHP
Но что это вообще за правила? В исходной версии они:
- Один уровень отступа для каждого метода.
- Не используйте ключевое слово ELSE.
- Оберните все примитивы и строки в классы.
- Первоклассные коллекции.
- По одной точке в строке.
- Не сокращайте.
- У всех классов должно быть меньше 50 строк.
- Нет классов с более чем двумя переменными экземпляра.
- Никаких геттеров или сеттеров.
Как я упоминал ранее, Джефф создал эти правила на основе языка Java, и они нуждаются в адаптации для других сред. Так же, как Рафаэль и Гильерме сделали для PHP, нам нужно взглянуть на каждый элемент и проанализировать его, чтобы увидеть, имеет ли он смысл в Go.
В первую очередь следует учитывать само название. Художественная гимнастика происходит от греческого языка и означает серию упражнений для достижения цели, например улучшения вашей физической формы. В этом контексте упражнения улучшают кондиционирование нашего кода. Проблема заключается в термине Object, потому что этого понятия в Go нет. Поэтому я предлагаю первое изменение: с объектной художественной гимнастики на художественной гимнастики. Я оставляю поле для комментариев ниже, чтобы обсудить, хорошее ли это предложение.
Давайте проанализируем остальные пункты.
Один уровень отступа для каждого метода
Применение этого правила позволяет сделать наш код более читабельным.
Применим правило к коду:
Один результат, гораздо более читаемый, будет:
Не используйте ключевое слово ELSE
Цель этого элемента - избежать использования ключевого слова else, создавая более чистый и быстрый код, поскольку он имеет меньше потоков выполнения.
Посмотрим на код:
Мы можем применить концепцию Early Return и удалить else из функции Login:
Оберните все примитивы и строки в классы
Это правило предполагает, что примитивные типы, имеющие поведение, в нашем случае должны быть инкапсулированы в структуры или типы, а не в классы . Таким образом, мы инкапсулируем логику поведения и упрощаем поддержку кода. Давайте посмотрим на пример:
Применяя правило, используя структуры:
Другой возможный и более идиоматический рефакторинг с использованием типов:
Помимо того, что новый код удобочитаем, новый код позволяет легко изменять бизнес-правила и обеспечивать большую безопасность в отношении того, чем мы манипулируем.
Коллекции первого класса
Если у вас есть набор элементов и вы хотите ими манипулировать, создайте специальную структуру для этой коллекции. Таким образом, мы можем реализовать все связанные поведения с коллекцией в структуре, такие как фильтры, правила проверки и так далее.
Итак, код:
Может быть переделан на:
Одна точка в строке
Это правило гласит, что вы не должны связывать функции, а использовать только те, которые являются частью того же контекста.
Пример:
Мы выполним рефакторинг:
Это правило усиливает использование « Закона Деметры »:
Говорите только со своими ближайшими друзьями
Не сокращайте
Это правило не распространяется непосредственно на Go. В сообществе есть свои правила для создания имен переменных, включая причины для использования меньших имен. Я рекомендую прочитать эту главу: Практический Go: реальные советы по написанию поддерживаемых программ Go
У всех классов должно быть меньше 50 строк
Хотя в Go нет концепции классов, это правило гласит, что объекты должны быть небольшими. Мы можем адаптировать идею для создания небольших структур и интерфейсов, которые мы можем использовать посредством композиции для формирования более крупных компонентов. Например, интерфейс:
Может быть адаптирован к:
Таким образом, другие интерфейсы и сценарии могут повторно использовать Reader и Writer.
Нет классов с более чем двумя переменными экземпляра
Это правило не имеет смысла в Go, но если у вас есть предложения, поделитесь ими.
Нет геттеров / сеттеров
Как и предыдущее правило, это также не кажется адаптируемым к Go, потому что это не шаблон, используемый сообществом, как видно из этой темы Effective Go. Но предложения приветствуются.
Применяя эти правила, среди других передовых практик, можно получить более чистый, простой и легкий в обслуживании код. Я хотел бы услышать ваше мнение о правилах и предложениях по адаптации к Go.
использованная литература
Https://javflores.github.io/object-calisthenics/ https://williamdurand.fr/2013/06/03/object-calisthenics/ https://medium.com/web-engineering-vox / улучшение-качества-кода-с-художественной-гимнастикой-aa4ad67a61f1
Я адаптировал несколько примеров, использованных в этом посте, из репозитория: https://github.com/rafos/object-calisthenics-in-go
Подтверждение
Спасибо, Вагнер Риффель и Франсиско Оливейра за предложения по улучшению примеров.
Первоначально опубликовано на https://eltonminetto.net.
