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

Статья достаточно простая, в ней рассматриваются очевидные вещи, но надеюсь, что она будет интересна начинающим программистам, которые пока встречались со словами из первого абзаца только на лекциях по программированию. (На самом деле эта статья и есть кусочек практического занятия по программированию.)

Настала пора мысленно вернуться на четыре с небольшим года назад ко блогозаписи «Simple “Class” Instantiation» из блога Джона Резига, прославленного создателя необыкновенно удобной библиотеки jQuery. И вернёмся.

Однако же, так как я вовсе не вижу её в результатах поиска на Хабрахабре по слову «Resig», то поневоле приходится думать, что эту полезную блогозапись никто не удосужился перевести (или хотя бы пересказать) за четыре прошедших года — мне придётся, стало быть, самостоятельно пересказать блогозапись Резига прежде, чем я исполню моё главное намерение: поразмыслить вслух, почему же предложенный Резигом способ решения указанной им проблемы так и не сделался общераспространённым. И перескажу. (Сам этот пересказ ужé был бы полезен читателю, даже кабы я к нему ничего от себя не прибавил. А я прибавлю.)

---

Шестого декабря 2007 года Резиг рассмотрел, что получается, когда в джаваскрипте используется операция «new» для создания объекта (в языках с классами мы сказали бы «экземпляра класса»):

function User(first, last){
   this.name = first + " " + last;
}

var user = new User("John", "Resig");

Резиг справедливо подметил, что для начинающих программистов на джаваскрипте не вполне очевидно, что появление «this» в коде функции указывает на то, что перед нами конструктор объекта. (Я от себя в скобках прибавлю: если функция находится в недрах некоторой библиотеки, то это обстоятельство нуждается также и в документировании — а не то пользователь библиотеки не многим будет отличаться от новичка: исходный код с телом функции читают не все, тем более что он нередко применяется в минифицированном, не читаемом виде.)

Поэтому, рассудил Резиг, рано или поздно кто-нибудь попробует вызвать «User()» без «new» и тем получит на свою голову сразу две неприятные проблемы. Во-первых, переменная «user» останется неопределённою: функция «User()» задумана ведь как конструктор, а значения она никакого не возвращает. Во-вторых, что ещё хуже, попытки обращения к «this» изнутри такого (некорректно вызванного) конструктора неизбежно приведёт к засорению глобального пространства имён — а это чревато зловещими и трудноуловимыми последствиями. Обе проблемы Джон Резиг продемонстрировал на примере:

var name = "Resig";
var user = User("John", name);
// здесь переменная «user» не определена
// БОЛЕЕ ТОГО: значение «name» теперь ужé не «Resig»!
if ( name == "John Resig" ) {
   // фигассе!…
}

При разработке Web-приложений мы обязательно сталкиваемся с проблемами рендеринга HTML-страниц. Обычно эти проблемы решает шаблонизатор — собственно PHP или какой-нибудь парсер шаблонов. Если приложение большое и страницы содержат множество блоков, то сложность шаблонов может резко возрасти, а у разработчиков появляется желание упростить работу с ними. В ход идут разные техники, но обычно это выделение в шаблонах повторяющихся блоков и правильная их декомпозиция — включая наследование шаблонов.

Оформим начатое в habrahabr.ru/blogs/javascript/130495/ в удобный для использования метод .inherit4 конструктора Constr, чтобы, фактически построить модель классов и наследования (она будет более мощной, чем классическая, но это побочный эффект). Если у Вас нет желания подключать Mootools с аналогичной моделью, будет достаточно этого метода на 2 КБ несжатого кода, чтобы нормально работать с прототипным наследованием и иметь пару дополнительных методов: доступ к методам предков .ancestor('имя_метода', номер_поколения_предка) и расширение хешей. Применение всех 3 методов позволяет исключить из лексикона слова prototype и constructor, продолжая работать с тем и другим, и делает код легко читаемым.

При работе с наследованием иногда возникает желание иметь функцию доступа к методу предка (методу родительского класса) — в конструкторе (аналоге класса для Javascript) или в методе-потомке, потому что, бывает, что новый класс переопределяет его. Не просто какую-нибудь функцию (метод), а с совершенно понятной записью, чтобы название говорило само за себя, и имеющую доступ к указанному поколению предков (не «пра-пра-пра-», а «пра- 3 раза»).

Возьмём за основу метод прототипного наследования, который максимально эффективен тем, что производит минимум действий при описании цепочек наследуемых классов и при этом максимально поддерживает базовые операции и свойства наследования: instanceof, constructor. Для доступа к предку он создаёт свойство .superclass.

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

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

JavaScript, как никакой другой язык, нуждается в именно таком объяснении. Функциональная природа, скрытая за Си-подобным синтаксисом, и непривычная прототипная модель наследования поначалу сильно сбивают с толку. Давайте мысленно понизим уровень JavaScript до простого процедурного, наподобие Си. Отталкиваясь от этого «недоязыка», переизобретем функциональное и объектно-ориентированное программирование.

Привет, хабрачеловеки!

Захотелось вот поделиться сокровенным знанием по этой теме. К тому же материалов по этому, достаточно важному принципу проектирования классов и их наследования, в Рунете как-то негусто. Имеются формулировки вида:

«Пусть q(x) является свойством верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.» © Wikipedia

Но они выносят мой мозг меня совершенно не радуют.

Если хочется услышать объяснение этой хрени умной фразы — прошу под кат.

В Питоне совсем не важно, что вы поместите в определение класса. Это могут быть строки, числа, объекты, переменные. В третьем Питоне можно даже передавать именованные аргументы.