Приложения? Я пишу только cgi-скрипты для обработки форм.
	Только структурное программирование (функции, инклуды). Быстро и просто.
	В основном структурное программирование, но использую классы для сложных структур, работы с БД.
	Реализую MVC, активно использую для этого классы, их методы, наследование и перегрузку.
	Строго придерживаюсь ООП, помимо прочего, использую пространства имен, области видимости, интерфейсы, трейты (traits), клонирование и автозагрузку классов.
	Комбинирую технологии самым неожиданным образом. Подробности в комментариях.
	Не изобретаю велосипедов, выбираю конкретный фреймворк (symfony, kohana, yii...) и делаю всё по гайдлайнам.
	Не могу влиять на архитектуру приложения и способ разработки. Делаю так, как сказал начальник.
	Не разрабатываю приложений. Я только конфигуратор CMS. Иногда дописываю к ним модули/плагины.

Проголосовало 906 человек. Воздержалось 456 человек.

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

Создаём свойства

При создании свойства класса, может возникнуть вопрос, как его объявить: private или protected?
Отличаются эти варианты тем, что protected виден классам-наследникам, а private нет.
И это даёт нам возможность скрыть от наследников переменную, чтобы они не напортачили в ней.
То есть, в большинстве случаев мы должны стремиться к тому, чтобы все свойства были private.

Классу-наследнику, вполне возможно, потребуется получать это свойство — для этого в родителе можно создать protected метод.

class Example
{
	private $field;

	protected function getField()
	{
		return $this->field;
	}
}

Ссылка на первую часть
Ссылка на вторую часть
Ссылка на третью часть

Ввод данных

Любой инсталлятор должен давать пользователю возможность вводить некоторые стартовый параметры, например, путь к папке, куда будет инсталлирована программа, строка подключения к базе данных, и т.д. Причем, хотелось бы, чтобы это были не просто текстовые поля, а поля, дающие возможность удобного вода данных. Если это путь установки программы, то помимо текстового поля должна быть кнопка «Browse…», если это строка подключения к БД, то пусть рядом будет кнопка для выбора или создания источника данных и т.д.

Ссылка на первую часть
Ссылка на вторую часть

Контентные и контейнерные команды

Некоторые команды подразумевают работу с файлами, изначально хранимыми на компьютере разработчика пакета. Понятно, что эти файлы нужно вместе с пакетом (а желательно, прямо внутри пакета) доставить к потребителю пакета. Попробуем для начала представить себе как это будет работать.
У нас есть экземпляр класса PackageBuilder, которому при конструировании мы указываем аргумент PackageBody, содержащий в себе, помимо всего прочего, команду Command, которая представляет собой корневой узел дерева команд пакета. Метод SaveResult() экземпляра класса PackageBuilder должен рекурсивно обойти все дерево, и для тех команд, которые используют контентные файлы, расположенные на компьютере разработчика, включить в тело пакета содержимое всех этих файлов. В тело пакета он также должен включить xml-файл, в который будет сериализован сам PackageBody с полным описанием пакета и выполняемых им команд.

Ссылка на первую часть

Транзакции.

Напомню, что я собирался реализовать механизм транзакций, позволяющий откатывать блоки операций при возникновении ошибки внутри блока, защищенного транзакцией. Сначала надо решить вопрос с ответственностью за сохранение состояния и за откат операции. Скажу сразу, что архитектура, которую я приведу ниже вырисовалась у меня не сразу, а только после нескольких попыток проектирования и реализации макета, пока у меня не получилось то, что получилось.
Для того, чтобы архитектура транзакций была легко наращиваемой, воспользуемся как и ранее наследованием. При этом возложим ответственность за сохранение состояние и откат к сохраненному состоянию на саму команду. Учтем при этом, что не все команды являются по сути транзакционными. Например, чтение из реестра не может быть частью транзакции, потому что оно ничего не изменяет в системе. А вот запись в реестр – это уже часть транзакции. И создание файла – это часть транзакции.
А поэтому объявим еще один абстрактный класс TransactionalCommand, унаследуем его от класса Command.

Данная статья написана по следам статьи Steve Yegge. A portrait of a n00b (с подачи хабраперевода). Для меня основной посыл статьи прозвучал так — меньше комментариев, меньше классов, меньше методов, больше кода. Делайте код плотнее, не усердствуйте в моделировании. Мне сложно судить это видение мира, да и вообще вопрос комментариев как таковых больше умозрительный. Но вот что засело во мне стальной иглой, так это проблема тестирования такого плотного кода.

Хочу представить вам функцию-конструктор классов createClass.
Чем хорош этот конструктор:
1. Сам код выглядит более читабельным и понятным
2. Поддержка множественного наследования
3. Поддержка абстрактных методов
4. Наследование статических методов и свойств класса
5. Умный метод instanceOf (проверяет по всей цепочке классов)