ООП *

В данной статье мы поговорим об основных особенностях объектно-ориентированного программирования в JavaScript:

• создание объектов,
• функция-конструктор,
• инкапсуляция через замыкания,
• полиморфизм и ключевые слова call/apply,
• наследование и способы его реализации.

В 2012 году разработчики C# из компании Microsoft создали язык TypeScript — надмножество JavaScript. Он предназначен для разработки больших приложений, от100 тысяч строк. Давайте на примерах рассмотрим синтаксис TypeScript, его основные достоинства и недостатки, а также разберём способ взаимодействия с популярными библиотеками.

Кому это будет полезно: Web-разработчикам и разработчикам клиентских приложений, интересующимся возможностью практического применения языка TypeScript.

«Я никогда не был сильным программистом, и это стимулировало меня к созданию новых мощных языков. Сегодня я работаю по двум направлениям: метапрограммирование и программирование „по-детски“, для детей в возрасте 9-14 лет.»
— Алан Кертис Кей.



Похоже, что этот мужик участвовал во всех институтах передовых разработок, связанных с ИТ.

— Работал в легендарном Xerox PARC, Atari, Apple, Disney, HP.
— Предложил концепцию Dynabook (в 1968 году), которая определила концептуальную базу для ноутбука, планшетного компьютера и электронной книги.
— Один из «отцов-основателей» объектно-ориентированного программирования (SmallTalk, 1969).
— Участвовал в создании первого персонального компьютера Xerox Alto (1973).
— Инициатор полезной движухи «Каждому ребенку по ноутбуку».
— в 2001 году, он основал исследовательский Институт Viewpoints, некоммерческую организацию посвящённую детям, обучению и передовым разработкам программного обеспечения.
— В 2006 бросил дерзкий вызов индустрии — заявил о возможности создания операционной системы с графическим интерфейсом из 20.000 строчек кода.

«Смена точки зрения дает +80 к IQ»
(A change in perspective is worth 80 IQ points)

И опять же, Алан Кей — ключевая фигура в ИТ, и при этом всего полторы переведенных статьи в Интернете. И знают про него, скорее всего, по его цитатам. Под катом — цитаты и немного выжимок из статей Кея. Ну, и великолепное выступление на TED.

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

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

Перейдем к конкретной «ходовой» задаче — объектная прослойка для работы с базами данных в PHP. Решений великое множество, начиная от PDO и заканчивая многоуровневыми (и, на мой взгляд, не совсем уместными в PHP) ORM движками.

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

Статья касается одной из концептуальных проблем ОС Фантом, ну или любой другой системы, в которой есть персистентная и «волатильная» составляющие.

Для понимания сути проблемы стоит прочесть одну из предыдущих статей — про персистентную оперативную память.

Краткая постановка проблемы: В силу того, что прикладная программа в ОС Фантом персистентна (не перезапускается при перезагрузке), а ядро — нет (перезапускается при перезагрузке и может быть изменено между запусками), в такой системе нельзя делать блокирующие системные вызовы. Обычным способом.

Здравствуйте.

Компания Embarcadero вчера объявила о выходе новой версии Delphi RAD studio XE 10.1,
Весь список изменений можно посмотреть тут, я же хочу рассказать о наиболее ценном(для нашей компании) улучшении, а именно о внедрение слабых [weak] ссылок в классический компилятор (Win32/Win64).

Выше в статье даны подробности проблемы, так что тем кто желает посмотреть что сделали в делфи прошу под кат.

Основой для языка MSH послужил язык MUMPS. MUMPS разработан где то в 80-х годах прошлого столетия, как впрочем и многие другие современные языки. Он с самого начала разрабатывался как язык для создания больших информационных систем, работы с большими распределенными данными. В связи с чем имеет некоторую специфику. Программирование на этом языке несколько отличается от программирования на других языках. Несмотря на его малую распространенность у него существует довольно устойчивое сообщество в разных частях света программистов разрабатывающих на нем информационные системы. За время своего существования MUMPS мало изменился. Некоторые элементы языка потеряли актуальность. И язык на данный момент несколько архаичен. Хотелось бы иметь более современный язык подобный MUMPS. С этой целью и создавался язык MSH. Некоторые концепции языка MSH отличаются или отсутствуют в языке MUMPS. В основном для аудитории MUMS программистов и написан данный материал, но может и другим будет интересно.

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

Здравствуйте, уважаемые читатели.

На русском языке выходит не так много универсальной неустаревающей литературы о принципах ООП. Пользуясь случаем, предлагаем скачать "Объектно-ориентированное мышление" Мэтта Вайсфельда, которой практически не осталось в бумаге. Однако подобные книги время от времени появляются, причем есть и такие, которые написаны в новаторском и прикладном стиле, а не просто перемалывают известные истины. Одна из них называется "Elegant Objects", мы серьезно задумываемся издать ее на русском языке.



Предлагаем оценить стиль и философию автора по переводу одной из последних статей из его блога.

Шаблонный метод

Когда приходится спрашивать человека, какие паттерны проектирования ему доводилось использовать, почему-то мало кто называет паттерн «Шаблонный метод» (Template Method). Вероятно, это связано с пробелом в знании номенклатуры паттернов, ибо лично я с трудом представляю себе, чтобы более-менее опытный программист ни разу не использовал такой удобный и полезный паттерн. Предлагаю ещё раз взглянуть на него поближе.

Итак, шаблонный метод.

Введение

Кнопки «Undo» и «Redo», позволяющие отменить и вернуть обратно любые пользовательские действия, а также посмотреть в списке перечень всех выполненных действий, являются стандартом де-факто для таких приложений, как текстовые процессоры и среды разработки, редакторы графики и САПР, системы редактирования и монтажа звука и видео. Они настолько привычны для пользователя, что последний воспринимает их наличие как данность, всего лишь одну функциональную возможность наряду с десятками других. Но с точки зрения разработчика требование к наличию undo является одним из факторов, влияющих на всю архитектуру проекта, определяемую на самых ранних стадиях проекта разработки.



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

Здравствуйте, уважаемые читатели.

Мы хотели бы поинтересоваться, все ли желающие уже успели прочитать замечательную книгу о Ruby под авторством Сэнди Метц в оригинале, или же ее перевод по-прежнему актуален и ожидаем.



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

Наверняка вы уже видели некоторые посты о D. Шаблоны, псевдочлены, потоки… Сегодня я вам расскажу о такой фиче языка, как UFCS, или Universal Function Call Syntax. Начнем с простого.

Рассмотрим некий класс A и функцию, принимающую указатель на его экземпляр:

class A {
	int a;
}

void foo(A a) {}

Спросите любого программиста на Си, как бы он её вызвал. Наверняка вы услышите что-то подобное:

void main() {
	auto b = new A;

	foo(b);
}

Фишка в том, что в D первый аргумент может выступать в роли базового идентификатора, чьим методом является данная функция, т.е. функцию можно вызвать следующим образом:

b.foo();

Это открывает большой простор для построения очень интересных, последовательных(и даже быстрых) конструкций.

Осторожно: в конце цветное изображение!

Позвольте небольшое предисловие — обозначу в нём цель статьи.
Я по субботам студентам младших курсов преподаю введение в шаблоны проектирования. Вот, хочу поделиться опытом, описать план нескольких первых лекций. Большинству читателей, я полагаю, сам излагаемый мной материал давно знаком, но, возможно, порядок и способ изложения покажутся любопытными.
Слишком часто, увы, нам рассказывают что-то, но не говорят, зачем это нужно, или говорят даже, но будто вскользь. Скажем, обыкновенно, говоря о C#, расскажут, что такое базовый класс и интерфейс, каким синтаксисом нужно пользоваться, чтобы написать их, приведут пример, где базовым будет класс «Птица», а наследниками «Утка» и «Орёл», но зачем всё это нужно, какая от всей — потенциально сложной — иерархии классов достигается польза, не говорят: это будто бы в тени, подразумевается само собою. И вот потому у многих учеников, ещё не успевших набить свои шишки, в голове перевёрнутая картина мира — они неплохо представляют, что за инструменты даны им в руки, но зачем они изобретены и к чему применимы, понимают смутно.
Вот поэтому я сочинил несколько учебных примеров, на которых можно показать зачем нужны некоторые подходы. Правда, придётся принять условность — будем бить из пушки по воробьям, а то и по воображаемым мишеням. Зато пристреляемся и уж во вражеский бруствер точно попадём, случись что.
Сразу скажу, что от вопросов совсем простых мы быстро перейдем к довольно сложным (ну, скажем, к компоновщику), потому читайте до конца, если уж не с начала.

Swift словарь представляет собой контейнер, который хранит несколько значений одного и того же типа. Каждое значение связано с уникальным ключом, который выступает в качестве идентификатора этого значения внутри словаря. В отличие от элементов в массиве, элементы в словаре не имеют определенного порядка. Используйте словарь, когда вам нужно искать значения на основе их идентификатора, так же как в реальном мире словарь используется для поиска определения конкретного слова. (прим.)

Swift словарь:

• Swift словарь состоит из двух общих типов: ключей (должны относиться к категории Hashable) и значений;
• Можно создавать записи посредством введения ключа и его значения;
• Значение может задаваться через ссылку на введенный ранее ключ;
• Можно удалить запись, указав соответствующий ключ;
• Каждый ключ связан с одним единственным значением.

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

Рассмотрим пример словаря, рассчитанного на 8 элементов: в нем предусмотрено максимум 7 записей (ключей, значений) и, как минимум, одно пустое место (так называемый пробел) в буфере словаря, благодаря которому происходит своеобразная блокировка поиска по выборкам/вставкам (retrivals/insertions).