Принцип DRY

Don't repeat yourself (DRY, переводится как Не повторяй себя) - это принцип разработки программного обеспечения, направленный на сокращение повторения паттернов программного обеспечения, заменяя их абстракциями или используя нормализацию данных, чтобы избежать избыточности.

Принцип DRY гласит: "Каждая часть знаний должна иметь одно, однозначное, авторитетное представление в системе". Этот принцип был сформулирован Энди Хантом и Дейвом Томасом в их книге "Прагматичный программист". Они применяют его довольно широко, включая его применения для схем баз данных, планов тестирования, систем сборки, и даже документации. Когда принцип DRY применяется успешно, модификация любого отдельного элемента системы не требует изменения других логически не связанных элементов. Кроме того, все элементы, которые логически связаны, изменяются предсказуемо и равномерно и, таким образом, синхронизируются. Помимо использования методов и подпрограмм в своем коде, Томас и Хант полагаются на генераторы кода, системы автоматической сборки и языки сценариев для соблюдения принципа DRY на разных уровнях.

DRY против WET решений

Нарушения DRY обычно называются решениями WET, которые обычно обозначают как "write every time" ("пишите каждый раз"), "write everything twice" ("пишите все дважды"), "we enjoy typing" ("нам нравится печатать") или "waste everyone's time" ("тратить время каждого"). Решения WET широко распространены в многоуровневых архитектурах, где перед разработчиком может быть поставлена задача, например, добавить поле комментария в форму в веб-приложении. Текстовая строка "comment" может повторяться в метке, HTML-теге, в имени функции чтения, закрытой переменной, DDL базы данных, запросах и т. д. Подход DRY устраняет эту избыточность за счет использования фреймворков, которые уменьшают или исключают все эти задачи редактирования, кроме самых важных, оставляя возможность добавления новых переменных знаний в одном месте.

Читайте также:

Комментарии

Отправить комментарий

Популярные сообщения из этого блога

Язык поисковых запросов в Graylog

Изображение
Синтаксис языка поисковых запросов в Graylog Синтаксис поиска очень близок к синтаксису Lucene. По умолчанию все поля сообщения включены в поиск, если вы не указали поле сообщения, в котором проводить поиск. Сообщения, содержащие термин ssh : ssh Сообщения, содержащие термин ssh или login : ssh login Сообщения, содержащие точную фразу ssh login : "ssh login" Сообщения, в которых поле type содержит ssh : type:ssh Сообщения, в которых поле type включает в себя ssh или login : type:(ssh login) Сообщения, в которых поле type содержит точную фразу ssh login : type:"ssh login" Сообщения с полем type : _exists_:type Сообщения, которые не имеют поля type : NOT _exists_:type Сообщения, которые соответствуют регулярному выражению ethernet[0-9]+ в поле type type:/ethernet[0-9]+/ По умолчанию все термины или фразы в поисковом запросе связаны между собой по логическому типу OR (ИЛИ), поэтому возвращаются все
Далее...

Хэш-таблица: разрешение коллизий

Изображение
Хэш-коллизии практически неизбежны при хэшировании случайного подмножества большого набора возможных ключей. Например, если 2450 ключей хэшируются в миллион корзин (buckets), даже при совершенно равномерном случайном распределении, в соответствии с проблемой дня рождения, существует приблизительно 95% вероятность того, что по крайней мере два ключа будут хэшированы в один и тот же слот. Поэтому почти все реализации хэш-таблиц имеют некоторую стратегию разрешения коллизий для обработки таких событий. Некоторые общие стратегии описаны ниже. Все эти методы требуют, чтобы ключи (или указатели на них) были сохранены в таблице вместе со связанными значениями. Отдельная цепочка В методе, известном как отдельная цепочка , каждая корзина (bucket) независима и имеет своего рода список записей с одинаковым индексом. Время для операций с хэш-таблицами - это время нахождения корзины (bucket) (которое является постоянным) плюс время для операции со списком. В хорошей хэш-таблице каждая корзина (
Далее...

Нормальные формы, пример нормализации в базе данных

Изображение
Кодд представил концепцию нормализации и то, что сейчас известно как первая нормальная форма (1NF) в 1970 году. Кодд продолжал определять вторую нормальную форму (2NF) и третью нормальную форму (3NF) в 1971 году, также Кодд и Рэймонд Ф. Бойс определили нормальную форму Бойса-Кодда (BCNF) в 1974 году. Неформально отношение реляционной базы данных часто описывается как "нормализованное", если оно соответствует третьей нормальной форме. Большинство отношений 3NF не содержат аномалий вставки, обновления и удаления. Нормальные формы (от наименее нормализованных до наиболее нормализованных): UNF: ненормализованная форма 1NF: первая нормальная форма 2NF: вторая нормальная форма 3NF: третья нормальная форма EKNF: Элементарный ключ, нормальная форма BCNF: нормальная форма Бойса-Кодда 4NF: четвертая нормальная форма ETNF: нормальная форма основного кортежа 5NF: пятая нормальная форма DKNF: нормальная форма ключа домена 6NF: шестая нормальная форма UNF (1970) 1NF (1
Далее...