<rmcreative>

RSS

Все заметки с тегом «Паттерны»

  1. Принципы GRASP

    4 июля 2022

    Набор принципов GRASP, general responsibility assignment software principles, что переводится как "общие принципы распределения обязанностей", помогает, как следует из названия, правильно выбрать в какой объект или модуль распределить определённую обязанность. Под обязанностью здесь подразумевается знание/хранение информации и/или проведение каких-либо действий.

    Принципы сформулированы в 1997 году Крэгом Ларманом в книге "Applying UML and Patterns" (на русском выходила под названием «Применение UML 2.0 и шаблонов проектирования»).

    Всего их девять. Четыре основных и пять дополнительных.

    Читаем

    Комментировать
  2. Архитектурные паттерны

    21 сентября 2019

    На форуме в очередной раз всплыл двоякий вопрос «всё ли я правильно делаю». Как и всегда, этот вопрос может подразумевать много чего, но так как был замешан архитектурный паттерн, то я не удержался напомнить про паттерны в общем.

    Архитектурные паттерны вроде clean architecture или hexagonal architecture мало чем отличаются от привычных паттернов проектирования в плане их применения. Как и с паттернами с свойственной им стадией «паттернизма», с архитектурными паттернами случается ровно то же. Практически все в определённый момент читают про очередной модный паттерн и начинают его бездумно применять. Не потому что он решает их конкретные проблемы, а потому что модно и «правильно».

    Применять любой паттерн без должного анализа решаемой проблемы вредно.

    В идеале должен происходить следующий процесс:

    • Анализ решаемой проблемы.
    • Выделение мест, которые должны быть гибкими.
    • Выделение болей. Поиск паттернов, которые могут их решить или изобретение решений (это часто не хуже).
    • Повторный анализ решения, которое получится. Можно ли проще?
    3 комментария
  3. Теория программирования: пакетные принципы и метрики

    3 июля 2019

    DevConf в этом году радуют быстрой обработкой видео. Выложили мой доклад «Теория программирования: пакетные принципы и метрики».

    Поговорим о том, как объективно выбирать пакеты для своего проекта и как правильно структурировать свой код в пакеты.

    Набор пакетных метрик известен давно, но на него не обращают достаточно внимания. Возможно, потому что он несколько формален, а может быть просто потому что всё хорошее постепенно забывается.

    Пакетные метрики позволяют формально оценить, подходит ли сторонний пакет для использования в вашем проекте или пакете, как он повлияет на общую стабильность.

    Пакетные принципы, изначально озвученные Робертом Мартином в дополнение к SOLID, показывают путь достижения оптимального соотношения поддерживаемости и гибкости.

    Смотрим

    Комментировать
  4. Хорошие программисты и сложность

    27 октября 2014

    Частенько мне встречаются хорошие, на первый взгляд, программисты: они говорят правильные вещи, цитируют отцов основателей, критикуют плохие подходы. К сожалению, на практике они нередко оказываются не настолько хороши.

    Чаще всего мешают им фанатичность, нетерпимость к альтернативам и полное отсутствие прагматичного подхода. От них часто можно услышать что-то вроде:

    • Код надо обязательно покрыть юнит-тестами на 100%. В тестах надо делать моки через мок-фреймворк.
    • Ни в коем случае нельзя писать связанный код.
    • Всегда без исключений надо следовать SOLID, DRY, GRASP и т.д.
    • Абсолютно все приложения надо строить по DDD.
    • Для доступа к данным обязательно нужен крутой ORM.
    • Писать документацию нет смысла, потому как она всегда отстаёт от кода. Код — лучшая документация.
    • Если в коде есть комментарии, код недостаточно отрефакторен. Всегда можно разделить код и назвать методы так, чтобы отразить предметную область.
    • Невозможно построить хорошую архитектуру без ООП.
    • И так далее.

    Знакомо? Всё это выливается в непрактичные решения, реальной целью которых является доказать собственную правоту и крутость сделав «как учат в умных книгах». Реальность при этом частенько не учитывается.

    Не следует забывать, для чего на самом деле мы пишем код. А именно:

    1. Чтобы он работал и решал поставленные задачи.
    2. Чтобы его могли прочитать, осознать и изменить другие программисты.

    Для пункта номер два следует вносить в код как можно меньше сложности. Оправдана она только в том случае, когда другого выхода нет.

    Это не означает, что не надо изучать шаблоны проектирования, читать Фаулера и т.д. Надо. Просто во всём надо знать меру и не бросаться применять прочитанное с особым энтузиазмом и уж, тем более, не стоит это делать, если вы не понимаете, для чего это и как оно упростит вам жизнь (и упростит ли вообще).

    39 комментариев
  5. PatternCooler

    6 июня 2009

    Довольно большой ресурс с паттернами. Даёт поменять размеры и цвет.

    Пользуемся

    3 комментария
  6. Repper — визуальное создание паттерна

    19 мая 2009

    Сервис позволяет визуально создать паттерн из любого небольшого изображения. Процесс очень занимательный и приятный.

    Пользуемся

    Выше пример того, что можно создать из фото кассового чека.

    2 комментария
  7. Pattern 8

    12 мая 2009

    Ещё один ресурс с паттернами. Условия использования жёстче, чем у AVA7 Patterns, но в любом случае — в хозяйстве сгодится…

    Пользуемся

    1 комментарий
  8. AVA7 Patterns

    25 ноября 2008

    632 замечательных паттерна для оформления фона сайтов, рабочего стола или ещё чего-нибудь.

    Пользуемся

    2 комментария