Что такое паттерна в строительстве

Стандарты и Паттерны в строительстве — экономия времени и средств для ретейла

Сетевые магазины и предприятия сферы обслуживания оказались идеальным решением с точки зрения экономии времени, материальных и интеллектуальных ресурсов. Проектно-строительная компания «ФБ-групп» предлагает подобный подход представителям сетевого бизнеса, решая многие управленческие и технические проблемы строительного производства.

В переводе с английского слово standard означает образец, мерило, норма. В строительстве, как известно, стандартизация решает проблемы качества, способствует экономии времени, материальных и интеллектуальных ресурсов. Слово pattern тоже английское, и означает примерно то же – образец, модель, образчик, выкройка. Различие в оттенках значения. Стандарт – это норма, образец для подражания, воспроизведения, некий идеал. В этом слове присутствует определенный этический смысл. Паттерн – это образец для копирования. Выкройка. И никаких этических оттенков.

Понятие «паттерн» давно применяют программисты, подразумевая под ним некий кусок программы, который может быть применен для решения подобной задачи в другой программе. Примерно в этом же ключе развивалась мысль инвесторов в торговые предприятия и сферу обслуживания. Так появился ретейл. Многократно воссоздаваемая, как по единой выкройке, модель магазина, ресторана, прачечной – с тем же дизайном интерьера, с тем же ассортиментом или перечнем услуг, ценовой политикой и пр. Очевидная выгода для хозяев – экономия временных, денежных и интеллектуальных ресурсов. Выгодно и для потребителя – он заранее знает, что он получит в качестве товара или услуги, по какой цене, каков механизм расчета.

Логично было бы предлагать аналогичный стандартный подход для строительства объектов сетевых предприятий. Стандартизация, а вернее паттернизация услуг для таких клиентов также работает на стабильное качество, сокращение затрат времени и средств. С точки зрения модели управления строительным производством здесь максимальные преимущества дает проектно-строительная организация. Именно такой подход осуществляет в своей работе компания «ФБ-групп». Выбрав своим приоритетным направлением проектирование и реконструкцию предприятий ретейла, проектно-строительная компания «ФБ-групп» предоставляет весь комплекс услуг – от проектирования и подготовки разрешительной документации до реализации проекта под ключ.

Более всего такая модель подходит для фирм, специализирующихся на однотипных объектах. Досконально изучив потребности клиента в данном сегменте рынка, подрядчик имеет в своем распоряжении всю необходимую технику и оборудование, а также связи с проверенными поставщиками. Неоспоримое преимущество проектно-строительного метода – это, конечно, концепция единой команды, работающей на один результат. Как следствие, повышается технологичность проекта и его экономическая эффективность. Ведь сметы, календарный план, план по закупкам и т.д. составляются еще на стадии проектирования. Эта же концепция дает возможность использовать совмещенный график, обеспечивающий экономию времени до 30 %.

Сокращение сроков строительства за счет частичного совмещения этапов

Суть совмещенного графика состоит в том, что весь объем работ делится на несколько этапов, или пакетов, каждый из которых на своем уровне имеет стадию проектирования, обеспечения и строительства. Такое разделение становится возможным именно потому, что проектировщики и строители работают как единый слаженный механизм. Кроме того, подобные проекты уже не раз воспроизводились в основных чертах на других объектах, поэтому не возникает проблем и проволочек в получении согласований. Как только первый пакет подошел к стадии строительства, можно начинать строительно- монтажные работы. То есть проектирование и обеспечение по всему объекту еще далеко не завершено, а работы уже ведутся. В это время заканчивается предстроительная подготовка второго пакета, и строители берутся за его реализацию, пока стадии проектирования и обеспечения проходит третий пакет – и так далее.

Проектно-строительный метод и совмещенный график – это паттерны в плане организации управления строительством. Но так же могут воспроизводиться на однотипных объектах и паттерны в сфере проектирования. Столкнувшись с технической проблемой и успешно справившись с ней, специалисты «ФБ-групп» предлагают своим новым клиентам готовые решения подобных проблем. Вот несколько примеров технологических паттернов.

Реки, текущие вверх: к проблеме устройства канализации в цокольных и помещениях

Часто предприятие общественного питания или цех по обработке пищевых продуктов супермаркета находится в цокольном этаже. В случае, если внутриплощадочная канализация располагается на уровне первого этажа, возникают трудности с канализированием сточных вод. Согласно СП 2.3.6.1066-01, в помещениях, расположенных ниже уровня внутриплощадочной канализации, нельзя размещать сливные трапы, моечные ванны, раковины и унитазы. Эта проблема решается путем организации системы трубопроводов с применением запорных устройств (обратных клапанов) и специальных насосов – так называемая принудительная канализация.

Холодильники отключают последними: элементы системы «умный дом» для сетевых магазинов и ресторанов

В крупном торговом или развлекательном комплексе нередко возникают проблемы энергодефицита, когда выделенных мощностей не хватает на все электрические приборы. Для предотвращения таких ситуаций можно использовать автоматизированную систему отключения неприоритетных нагрузок. Эта система, без участия человека, в случае перегрузок в сети, отключает наименее важные в данный момент приборы. Например, сначала отключаются телевизоры. Если за определенный в сценарии отрезок времени параметры питающей сети либо нагрузка не приходят в норму, то отключаются какие-то осветительные приборы, затем, скажем, вентиляторы и т.д. То есть наиболее важные приборы не остаются без электропитания до последнего. Сценарий разрабатывается в соответствии с нуждами заказчика и согласуется с ним во всех мелочах.

Мультизональное кондиционирование – рентабельнее и удобнее

Система кондиционирования – одна из сложнейших инженерных коммуникаций в производственных и торговых помещениях. Распространенные повсеместно еще недавно сплит-системы оказываются нерентабельны в обширных помещениях, а кроме того и неудобны с эстетической точки зрения, ведь на каждый внутренний блок приходится наружный, размещенный на фасаде здания. Даже мульти-сплит-системы не решают принципиально этих проблем. Мультизональные кондиционеры значительно удобнее – на один наружный блок в этих системах приходится до 20 внутренних, каждый из которых работает как самостоятельный кондиционер, то есть в разных зонах можно создавать различный микроклимат. Кроме того, по энергопотреблению мультизональные системы в два раза экономичнее сплит-систем.

Применение методологических и технологических паттернов не только экономит время и материальные ресурсы. Подобно тому, как ресторан или магазин известного бренда одной своей вывеской говорит потребителю о стандарте качества своих услуг, паттерны в сфере строительства позволяют заказчику чувствовать себя уверенно. Свои новые объекты он доверит именно такому надежному подрядчику, как это делают клиенты компании «ФБ-групп», среди которых известнейшие сети ресторанов – «Елки-палки», «Русское бистро», «Тояма Токанава»; сети магазинов «Детский мир», «Азбука вкуса», «Риттер Джентльмен»; офисы крупных российский и международных компаний, таких как УралСиб, Банк Проектного Финансирования, Mirax Group и многие другие.

Производство

• Создание и ликвидация предприятий в строительстве
• Инвестиции и инвестиционный процесс
• Структура и этапы разработки бизнес-плана
• Элементы и виды страховых правоотношений
• Лицензирование строительной деятельности
• Сертификация продукции и услуг в строительстве
• Подрядные торги в строительстве
• Договорные отношения в строительстве
• Бухгалтерский учёт и аудит в строительстве

Классификация паттернов

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

Самые низкоуровневые и простые паттерны — идиомы. Они не универсальны, поскольку применимы только в рамках одного языка программирования.

Самые универсальные — архитектурные паттерны, которые можно реализовать практически на любом языке. Они нужны для проектирования всей программы, а не отдельных её элементов.

Кроме того, паттерны отличаются и предназначением. В этой книге будут рассмотрены три основные группы паттернов:

• Порождающие паттерны беспокоятся о гибком создании объектов без внесения в программу лишних зависимостей.
• Структурные паттерны показывают различные способы построения связей между объектами.
• Поведенческие паттерны заботятся об эффективной коммуникации между объектами.

• Премиум контент
  • Книга о паттернах
  • Курс по рефакторингу
  • Введение в рефакторинг
    • Чистый код
    • Технический долг
    • Когда рефакторить
    • Как рефакторить
    • Раздувальщики
      • Длинный метод
      • Большой класс
      • Одержимость элементарными типами
      • Длинный список параметров
      • Группы данных
      • Операторы switch
      • Временное поле
      • Отказ от наследства
      • Альтернативные классы с разными интерфейсами
      • Расходящиеся модификации
      • Стрельба дробью
      • Параллельные иерархии наследования
      • Комментарии
      • Дублирование кода
      • Ленивый класс
      • Класс данных
      • Мёртвый код
      • Теоретическая общность
      • Завистливые функции
      • Неуместная близость
      • Цепочка вызовов
      • Посредник
      • Неполнота библиотечного класса
      • Составление методов
        • Извлечение метода
        • Встраивание метода
        • Извлечение переменной
        • Встраивание переменной
        • Замена переменной вызовом метода
        • Расщепление переменной
        • Удаление присваиваний параметрам
        • Замена метода объектом методов
        • Замена алгоритма
        • Перемещение метода
        • Перемещение поля
        • Извлечение класса
        • Встраивание класса
        • Сокрытие делегирования
        • Удаление посредника
        • Введение внешнего метода
        • Введение локального расширения
        • Самоинкапсуляция поля
        • Замена простого поля объектом
        • Замена значения ссылкой
        • Замена ссылки значением
        • Замена поля-массива объектом
        • Дублирование видимых данных
        • Замена однонаправленной связи двунаправленной
        • Замена двунаправленной связи однонаправленной
        • Замена магического числа символьной константой
        • Инкапсуляция поля
        • Инкапсуляция коллекции
        • Замена кодирования типа классом
        • Замена кодирования типа подклассами
        • Замена кодирования типа состоянием/стратегией
        • Замена подкласса полями
        • Разбиение условного оператора
        • Объединение условных операторов
        • Объединение дублирующихся фрагментов в условных операторах
        • Удаление управляющего флага
        • Замена вложенных условных операторов граничным оператором
        • Замена условного оператора полиморфизмом
        • Введение Null-объекта
        • Введение проверки утверждения
        • Переименование метода
        • Добавление параметра
        • Удаление параметра
        • Разделение запроса и модификатора
        • Параметризация метода
        • Замена параметра набором специализированных методов
        • Передача всего объекта
        • Замена параметра вызовом метода
        • Замена параметров объектом
        • Удаление сеттера
        • Сокрытие метода
        • Замена конструктора фабричным методом
        • Замена кода ошибки исключением
        • Замена исключения проверкой условия
        • Подъём поля
        • Подъём метода
        • Подъём тела конструктора
        • Спуск метода
        • Спуск поля
        • Извлечение подкласса
        • Извлечение суперкласса
        • Извлечение интерфейса
        • Свёртывание иерархии
        • Создание шаблонного метода
        • Замена наследования делегированием
        • Замена делегирования наследованием
        • Введение в паттерны
          • Что такое Паттерн?
          • История паттернов
          • Зачем знать паттерны?
          • Критика паттернов
          • Классификация паттернов
          • Фабричный метод
          • Абстрактная фабрика
          • Строитель
          • Прототип
          • Одиночка
          • Адаптер
          • Мост
          • Компоновщик
          • Декоратор
          • Фасад
          • Легковес
          • Заместитель
          • Цепочка обязанностей
          • Команда
          • Итератор
          • Посредник
          • Снимок
          • Наблюдатель
          • Состояние
          • Стратегия
          • Шаблонный метод
          • Посетитель
          • C#
          • C++
          • Go
          • Java
          • PHP
          • Python
          • Ruby
          • Rust
          • Swift
          • TypeScript

          Паттерн строительство

          

          

          Подборка из 72 красивых картинок по теме — Паттерн строительство. Смотрите онлайн или можете скачать на телефон или компьютер в хорошем качестве совешенно бесплатно. Не забывайте оставить комментарий и посмотреть другие фотографии и изображения высокого качества, например Паттерн бизнес, Паттерн микросхема в разделе Картинки!

          Добавить комментарий:

          Еще материалы:

          

          Черчение картинки

          

          Музыкальный паттерн

          

          Картинки строительство и ремонт

          

          Паттерн барбершоп

          

          Картинки строительных инструментов

          Строитель

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

          

          Проблема

          Представьте сложный объект, требующий кропотливой пошаговой инициализации множества полей и вложенных объектов. Код инициализации таких объектов обычно спрятан внутри монструозного конструктора с десятком параметров. Либо ещё хуже — распылён по всему клиентскому коду.

          

          Например, давайте подумаем о том, как создать объект Дом . Чтобы построить стандартный дом, нужно поставить 4 стены, установить двери, вставить пару окон и положить крышу. Но что, если вы хотите дом побольше да посветлее, имеющий сад, бассейн и прочее добро?

          Самое простое решение — расширить класс Дом , создав подклассы для всех комбинаций параметров дома. Проблема такого подхода — это громадное количество классов, которые вам придётся создать. Каждый новый параметр, вроде цвета обоев или материала кровли, заставит вас создавать всё больше и больше классов для перечисления всех возможных вариантов.

          Чтобы не плодить подклассы, вы можете подойти к решению с другой стороны. Вы можете создать гигантский конструктор Дома , принимающий уйму параметров для контроля над создаваемым продуктом. Действительно, это избавит вас от подклассов, но приведёт к другой проблеме.

          

          Большая часть этих параметров будет простаивать, а вызовы конструктора будут выглядеть монструозно из-за длинного списка параметров. К примеру, далеко не каждый дом имеет бассейн, поэтому параметры, связанные с бассейнами, будут простаивать бесполезно в 99% случаев.

          Решение

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

          

          Паттерн предлагает разбить процесс конструирования объекта на отдельные шаги (например, построитьСтены , вставитьДвери и другие). Чтобы создать объект, вам нужно поочерёдно вызывать методы строителя. Причём не нужно запускать все шаги, а только те, что нужны для производства объекта определённой конфигурации.

          Зачастую один и тот же шаг строительства может отличаться для разных вариаций производимых объектов. Например, деревянный дом потребует строительства стен из дерева, а каменный — из камня.

          В этом случае вы можете создать несколько классов строителей, выполняющих одни и те же шаги по-разному. Используя этих строителей в одном и том же строительном процессе, вы сможете получать на выходе различные объекты.

          

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

          Директор

          Вы можете пойти дальше и выделить вызовы методов строителя в отдельный класс, называемый директором . В этом случае директор будет задавать порядок шагов строительства, а строитель — выполнять их.

          

          Отдельный класс директора не является строго обязательным. Вы можете вызывать методы строителя и напрямую из клиентского кода. Тем не менее, директор полезен, если у вас есть несколько способов конструирования продуктов, отличающихся порядком и наличием шагов конструирования. В этом случае вы сможете объединить всю эту логику в одном классе.

          Такая структура классов полностью скроет от клиентского кода процесс конструирования объектов. Клиенту останется только привязать желаемого строителя к директору, а затем получить у строителя готовый результат.

          Структура

          

          1. Интерфейс строителя объявляет шаги конструирования продуктов, общие для всех видов строителей.
          2. Конкретные строители реализуют строительные шаги, каждый по-своему. Конкретные строители могут производить разнородные объекты, не имеющие общего интерфейса.
          3. Продукт — создаваемый объект. Продукты, сделанные разными строителями, не обязаны иметь общий интерфейс.
          4. Директор определяет порядок вызова строительных шагов для производства той или иной конфигурации продуктов.
          5. Обычно Клиент подаёт в конструктор директора уже готовый объект-строитель, и в дальнейшем данный директор использует только его. Но возможен и другой вариант, когда клиент передаёт строителя через параметр строительного метода директора. В этом случае можно каждый раз применять разных строителей для производства различных представлений объектов.

          Псевдокод

          В этом примере Строитель используется для пошагового конструирования автомобилей, а также технических руководств к ним.

          

          Автомобиль — это сложный объект, который может быть сконфигурирован сотней разных способов. Вместо того, чтобы настраивать автомобиль через конструктор, мы вынесем его сборку в отдельный класс-строитель, предусмотрев методы для конфигурации всех частей автомобиля.

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

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

          Очевидно, что бумажное руководство и железный автомобиль — это две разных вещи, не имеющих ничего общего. По этой причине мы должны получать результат напрямую от строителей, а не от директора. Иначе нам пришлось бы жёстко привязать директора к конкретным классам автомобилей и руководств.

          // Строитель может создавать различные продукты, используя один // и тот же процесс строительства. class Car is // Автомобили могут отличаться комплектацией: типом // двигателя, количеством сидений, могут иметь или не иметь // GPS и систему навигации и т. д. Кроме того, автомобили // могут быть городскими, спортивными или внедорожниками. class Manual is // Руководство пользователя для данной конфигурации // автомобиля. // Интерфейс строителя объявляет все возможные этапы и шаги // конфигурации продукта. interface Builder is method reset() method setSeats(. ) method setEngine(. ) method setTripComputer(. ) method setGPS(. ) // Все конкретные строители реализуют общий интерфейс по-своему. class CarBuilder implements Builder is private field car:Car method reset() // Поместить новый объект Car в поле "car". method setSeats(. ) is // Установить указанное количество сидений. method setEngine(. ) is // Установить поданный двигатель. method setTripComputer(. ) is // Установить поданную систему навигации. method setGPS(. ) is // Установить или снять GPS. method getResult():Car is // Вернуть текущий объект автомобиля. // В отличие от других порождающих паттернов, где продукты // должны быть частью одной иерархии классов или следовать // общему интерфейсу, строители могут создавать совершенно // разные продукты, которые не имеют общего предка. class CarManualBuilder implements Builder is private field manual:Manual method reset() // Поместить новый объект Manual в поле "manual". method setSeats(. ) is // Описать, сколько мест в машине. method setEngine(. ) is // Добавить в руководство описание двигателя. method setTripComputer(. ) is // Добавить в руководство описание системы навигации. method setGPS(. ) is // Добавить в инструкцию инструкцию GPS. method getResult():Manual is // Вернуть текущий объект руководства. // Директор знает, в какой последовательности нужно заставлять // работать строителя, чтобы получить ту или иную версию // продукта. Заметьте, что директор работает со строителем через // общий интерфейс, благодаря чему он не знает тип продукта, // который изготовляет строитель. class Director is method constructSportsCar(builder: Builder) is builder.reset() builder.setSeats(2) builder.setEngine(new SportEngine()) builder.setTripComputer(true) builder.setGPS(true) // Директор получает объект конкретного строителя от клиента // (приложения). Приложение само знает, какого строителя нужно // использовать, чтобы получить определённый продукт. class Application is method makeCar() is director = new Director() CarBuilder builder = new CarBuilder() director.constructSportsCar(builder) Car car = builder.getResult() CarManualBuilder builder = new CarManualBuilder() director.constructSportsCar(builder) // Готовый продукт возвращает строитель, так как // директор чаще всего не знает и не зависит от // конкретных классов строителей и продуктов. Manual manual = builder.getResult()

          Применимость

          Когда вы хотите избавиться от «телескопического конструктора».

          Допустим, у вас есть один конструктор с десятью опциональными параметрами. Его неудобно вызывать, поэтому вы создали ещё десять конструкторов с меньшим количеством параметров. Всё, что они делают — это переадресуют вызов к базовому конструктору, подавая какие-то значения по умолчанию в параметры, которые пропущены в них самих.

          class Pizza < Pizza(int size) < . >Pizza(int size, boolean cheese) < . >Pizza(int size, boolean cheese, boolean pepperoni) < . >// .

          Такого монстра можно создать только в языках, имеющих механизм перегрузки методов, например, C# или Java.

          Паттерн Строитель позволяет собирать объекты пошагово, вызывая только те шаги, которые вам нужны. А значит, больше не нужно пытаться «запихнуть» в конструктор все возможные опции продукта.

          Когда ваш код должен создавать разные представления какого-то объекта. Например, деревянные и железобетонные дома.

          Строитель можно применить, если создание нескольких представлений объекта состоит из одинаковых этапов, которые отличаются в деталях.

          Интерфейс строителей определит все возможные этапы конструирования. Каждому представлению будет соответствовать собственный класс-строитель. А порядок этапов строительства будет задавать класс-директор.

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

          Строитель конструирует объекты пошагово, а не за один проход. Более того, шаги строительства можно выполнять рекурсивно. А без этого не построить древовидную структуру, вроде Компоновщика.

          Заметьте, что Строитель не позволяет посторонним объектам иметь доступ к конструируемому объекту, пока тот не будет полностью готов. Это предохраняет клиентский код от получения незаконченных «битых» объектов.

          Шаги реализации

          1. Убедитесь в том, что создание разных представлений объекта можно свести к общим шагам.
          2. Опишите эти шаги в общем интерфейсе строителей.
          3. Для каждого из представлений объекта-продукта создайте по одному классу-строителю и реализуйте их методы строительства. Не забудьте про метод получения результата. Обычно конкретные строители определяют собственные методы получения результата строительства. Вы не можете описать эти методы в интерфейсе строителей, поскольку продукты не обязательно должны иметь общий базовый класс или интерфейс. Но вы всегда сможете добавить метод получения результата в общий интерфейс, если ваши строители производят однородные продукты с общим предком.
          4. Подумайте о создании класса директора. Его методы будут создавать различные конфигурации продуктов, вызывая разные шаги одного и того же строителя.
          5. Клиентский код должен будет создавать и объекты строителей, и объект директора. Перед началом строительства клиент должен связать определённого строителя с директором. Это можно сделать либо через конструктор, либо через сеттер, либо подав строителя напрямую в строительный метод директора.
          6. Результат строительства можно вернуть из директора, но только если метод возврата продукта удалось поместить в общий интерфейс строителей. Иначе вы жёстко привяжете директора к конкретным классам строителей.

          Преимущества и недостатки

          • Позволяет создавать продукты пошагово.
          • Позволяет использовать один и тот же код для создания различных продуктов.
          • Изолирует сложный код сборки продукта от его основной бизнес-логики.
          • Усложняет код программы из-за введения дополнительных классов.
          • Клиент будет привязан к конкретным классам строителей, так как в интерфейсе директора может не быть метода получения результата.

          Отношения с другими паттернами

          • Многие архитектуры начинаются с применения Фабричного метода (более простого и расширяемого через подклассы) и эволюционируют в сторону Абстрактной фабрики, Прототипа или Строителя (более гибких, но и более сложных).
          • Строитель концентрируется на построении сложных объектов шаг за шагом. Абстрактная фабрика специализируется на создании семейств связанных продуктов. Строитель возвращает продукт только после выполнения всех шагов, а Абстрактная фабрика возвращает продукт сразу же.
          • Строитель позволяет пошагово сооружать дерево Компоновщика.
          • Паттерн Строитель может быть построен в виде Моста: директор будет играть роль абстракции, а строители — реализации.
          • Абстрактная фабрика, Строитель и Прототип могут быть реализованы при помощи Одиночки.

          Примеры реализации паттерна

          

          Не втыкай в транспорте

          Лучше почитай нашу книгу о паттернах проектирования.

          Теперь это удобно делать даже во время поездок в общественном транспорте.

          

          Эта статья является частью нашей электронной книги Погружение в Паттерны Проектирования.

          

          • Премиум контент
            • Книга о паттернах
            • Курс по рефакторингу
            • Введение в рефакторинг
              • Чистый код
              • Технический долг
              • Когда рефакторить
              • Как рефакторить
              • Раздувальщики
                • Длинный метод
                • Большой класс
                • Одержимость элементарными типами
                • Длинный список параметров
                • Группы данных
                • Операторы switch
                • Временное поле
                • Отказ от наследства
                • Альтернативные классы с разными интерфейсами
                • Расходящиеся модификации
                • Стрельба дробью
                • Параллельные иерархии наследования
                • Комментарии
                • Дублирование кода
                • Ленивый класс
                • Класс данных
                • Мёртвый код
                • Теоретическая общность
                • Завистливые функции
                • Неуместная близость
                • Цепочка вызовов
                • Посредник
                • Неполнота библиотечного класса
                • Составление методов
                  • Извлечение метода
                  • Встраивание метода
                  • Извлечение переменной
                  • Встраивание переменной
                  • Замена переменной вызовом метода
                  • Расщепление переменной
                  • Удаление присваиваний параметрам
                  • Замена метода объектом методов
                  • Замена алгоритма
                  • Перемещение метода
                  • Перемещение поля
                  • Извлечение класса
                  • Встраивание класса
                  • Сокрытие делегирования
                  • Удаление посредника
                  • Введение внешнего метода
                  • Введение локального расширения
                  • Самоинкапсуляция поля
                  • Замена простого поля объектом
                  • Замена значения ссылкой
                  • Замена ссылки значением
                  • Замена поля-массива объектом
                  • Дублирование видимых данных
                  • Замена однонаправленной связи двунаправленной
                  • Замена двунаправленной связи однонаправленной
                  • Замена магического числа символьной константой
                  • Инкапсуляция поля
                  • Инкапсуляция коллекции
                  • Замена кодирования типа классом
                  • Замена кодирования типа подклассами
                  • Замена кодирования типа состоянием/стратегией
                  • Замена подкласса полями
                  • Разбиение условного оператора
                  • Объединение условных операторов
                  • Объединение дублирующихся фрагментов в условных операторах
                  • Удаление управляющего флага
                  • Замена вложенных условных операторов граничным оператором
                  • Замена условного оператора полиморфизмом
                  • Введение Null-объекта
                  • Введение проверки утверждения
                  • Переименование метода
                  • Добавление параметра
                  • Удаление параметра
                  • Разделение запроса и модификатора
                  • Параметризация метода
                  • Замена параметра набором специализированных методов
                  • Передача всего объекта
                  • Замена параметра вызовом метода
                  • Замена параметров объектом
                  • Удаление сеттера
                  • Сокрытие метода
                  • Замена конструктора фабричным методом
                  • Замена кода ошибки исключением
                  • Замена исключения проверкой условия
                  • Подъём поля
                  • Подъём метода
                  • Подъём тела конструктора
                  • Спуск метода
                  • Спуск поля
                  • Извлечение подкласса
                  • Извлечение суперкласса
                  • Извлечение интерфейса
                  • Свёртывание иерархии
                  • Создание шаблонного метода
                  • Замена наследования делегированием
                  • Замена делегирования наследованием
                  • Введение в паттерны
                    • Что такое Паттерн?
                    • История паттернов
                    • Зачем знать паттерны?
                    • Критика паттернов
                    • Классификация паттернов
                    • Фабричный метод
                    • Абстрактная фабрика
                    • Строитель
                    • Прототип
                    • Одиночка
                    • Адаптер
                    • Мост
                    • Компоновщик
                    • Декоратор
                    • Фасад
                    • Легковес
                    • Заместитель
                    • Цепочка обязанностей
                    • Команда
                    • Итератор
                    • Посредник
                    • Снимок
                    • Наблюдатель
                    • Состояние
                    • Стратегия
                    • Шаблонный метод
                    • Посетитель
                    • C#
                    • C++
                    • Go
                    • Java
                    • PHP
                    • Python
                    • Ruby
                    • Rust
                    • Swift
                    • TypeScript
                    Похожие публикации:

                    1. Как выйти из метода c
                    2. Как научиться кодировать
                    3. Лицензия gpl что это
                    4. Сколько занимает символ в unicode