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

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

ActiveRecord даже хуже, чем ORM

Вероятно, вы помните, что я думаю об ORM, очень популярном паттерне. Если кратко, это побуждает нас превращать объекты в DTO - в результате, вся парадигма программирования переходит от объектно-ориентированного подхода к процедурному. Я попытался объяснить это в JPoint и JEEConf в этом году. После каждого разговора несколько человек сказали мне, что то, что я предлагаю, называется шаблонами ActiveRecord или Repository.

ORM - это обидно

Композиционные декораторы против императивных вспомогательных методов

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

Контейнеры для вставки зависимостей загрязняют код

В то время как инъекция зависимостей (aka, «DI») - естественный метод создания объектов в ООП (известный задолго до того, как термин был введен Мартином Фаулером), Spring IoC, Google Guice, Java EE6 CDI, Dagger и другие структуры DI превращают его в Анти-шаблон.

Я не собираюсь обсуждать очевидные аргументы против «инъекций сеттера» (например, Spring IoC) и «инъекции полей» (как в PicoContainer). Эти механизмы просто нарушают основные принципы объектно-ориентированного программирования и побуждают нас создавать неполные, изменяемые объекты, которые заполняются данными в ходе выполнения приложения. Помните: идеальные объекты должны быть неизменными и не должны содержать сеттеров.

Вместо этого давайте поговорим о «введении конструктора» (как в Google Guice) и его использовании с контейнерами инъекции зависимостей. Я попытаюсь показать, почему я рассматриваю эти контейнеры как избыточность.

Инкрементное выставление счетов

Когда вы нанимаете разработчика программного обеспечения (индивидуального или коллективного), существует в основном два типа контрактов: фиксированная цена или время&материал. Они принципиально разные, но правда в том, что в любом случае вы проигрываете.

 
В методологии eXtremely Distributed Software Development (XDSD) все по-другому, включая способ выставления счетов нашим клиентам. Давайте посмотрим, что происходит в традиционных контрактах и ​​какие изменения в XDSD, которые мы практикуем в Teamed.io.

Семь смертных грехов программного проекта

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

Сколько объектов инкапсулируется?

Какая строка вам нравится больше, первая или вторая:

new HTTP("http://www.google.com").read();
new HTTP().read("http://www.google.com");

В чем разница? Первый класс HTTP инкапсулирует URL-адрес, а второй ожидает его как аргумент метода read (). Технически оба объекта выполняют одно и то же: они читают содержимое домашней страницы Google. Какой из них правильный? Обычно я ненавижу говорить это, но в этом случае я должен - это зависит от точки зрения.

Определение ошибки программного обеспечения в Википедии неверно

Вот что говорит Википедия на момент написания этой статьи:

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

Я думаю, что это неполно. Это определение полностью исключает «непоследовательные» дефекты, связанные, например, с ремонтопригодностью и возможностью повторного использования.

API RESTful и веб-сайт на одном URL-адресе

Посмотрите, например, на GitHub RESTful API. Чтобы получить информацию о репозитории, вы должны сделать запрос GET для api.github.com/repos/yegor256/rultor. В ответ вы получите документ JSON со всеми подробностями репозитория yegor256 / rultor. Попробуйте, URL-адрес не требует никакой аутентификации.

Чтобы открыть тот же репозиторий на хорошей HTML + CSS-странице, вы должны использовать другой URL-адрес: github.com/yegor256/rultor. URL-адрес отличается, серверная сторона определенно отличается, но характер данных точно такой же. Единственное, что меняется - это слой представления.

В первом случае мы получаем JSON; Во втором - HTML.

Как насчет их объединения? Как использовать тот же URL-адрес и тот же механизм обработки на стороне сервера для обоих из них? Как насчет переноса всей задачи рендеринга на сторону клиента (браузер) и предоставления серверу возможности работать исключительно с данными?