ООП *

Введение

Кнопки «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).

В 2016 многие из нас пообещали себе новые свершения, например, прочесть отложенную книгу, освоить новый вид спорта или язык программирования т.п. Изучение новых технологий в чем-то сродни вышеописанным действиям. Итак, для таких энтузиастов небольшой обзор про удобные «инструменты» для разработки web-приложений на языке Java.
Новый цикл статей будет посвящена Vaadin и Liquibase.
В первой статье хочу вам рассказать о нескольких этапах для начала знакомства с этим FrameWork-ом(Vaadin). Мы поговорим о «загрузке» шаблона и первичном добавлении элементов на «макет». Немного поговорим о Liquibase. В следующих статьях планируется добавить обработку файлов xml.

На днях компания ObjectArts полностью открыла исходники и выпустила язык, и среду разработки Dolphin Smalltalk под открытой лицензией MIT! Я не смог пройти мимо, не попробовав проверить этот проект с помощью анализатора кода PVS-Studio. Могу поздравить разработчиков с тем, что у них получилось создать код высокого качества. Мне не удалось найти значимых ошибок. Однако как всегда есть некоторое количество багов и пахнущего кода. Надеюсь благодаря этой статье код станет чуть лучше.

О проекте

Dolphin Smalltalk — это среда разработки на собственном диалекте Smalltalk для Windows. Ключевыми особенностями является тесная интеграция с нативными виджетами и подсистемами операционной системы, включая COM и ActiveX, и приятный глазу графический дизайн.

Долгое время Dolphin Smalltalk был доступен в двух вариантах: условно-бесплатная ограниченная версия (community edition) и платный пакет для профессиональной разработки. Последний давал доступ ко всем функциям, включая продвинутые редакторы и публикацию приложений в standalone режиме, однако стоил около четырехсот долларов.

С помощью PVS-Studio 6.00 были проверены открытые исходники Dolphin Smalltalk Virtual Machine. Далее представлены результаты проверки статическим анализатором. Несмотря на то, что проект DolphinVM очень маленький, в его коде всё равно встречаются подозрительные места.

Ребята называющие себя Open Source Society, взяли и собрали учебный план из бесплатных MOOC курсов, для желающих изучить информатику (Computer Science). Всего в программе 50+ курсов в ходе которых можно получить знания о разных аспектах CS. Курсы собраны с таких проектов как: Coursera, edX, Udacity, и т.д. На мой взгляд получилась добротная цепочка, на освоение которой, в зависимости от интенсивности и уровня подготовки, уйдет 1-2 года.

^{Cчетчик со страницы Getting Started на момент публикации статьи}

С минуты на минуту случится то, чего ждали очень многие, и я в том числе. А именно: компания ObjectArts полностью открывает исходники и выпускает язык и среду разработки Dolphin Smalltalk под открытой лицензией MIT!

О проекте

DolphinSmalltalk — это среда разработки на собственном диалекте Smalltalk для Windows. Ключевыми особенностями является тесная интеграция с нативными виджетами и подсистемами операционной системы, включая COM и ActiveX, и приятный глазу дизайн.

Долгое время Dolphin Smalltalk был доступен в двух вариантах: условно-бесплатная ограниченная версия (community edition) и платный пакет для профессиональной разработки. Последний давал доступ ко всем функциям, включая продвинутые редакторы и публикацию приложений в standalone режиме, однако стоил около четырехсот долларов, что, по понятной причине, устраивало далеко не всех.

Похоже, что компания таки одумалась (или терять стало нечего) и решила выпустить ПО на волю. Под катом краткое описание среды разработки и размышления на тему open source будущего Dolphin Smalltalk.

На прошлой неделе я выступил с докладом об Объектно-ориентированном программировании в Мишлене, в компании, где я работаю. Я рассказывал о написании более эффективного кода, от STUPID коду SOLID коду! STUPID, а также SOLID являются акронимами, и рассматривались довольно много в течение длительного времени. Однако эти мнемоники не всегда известны, таким образом, имеет смысл распространить эту информацию.



Далее я познакомлю вас с принципами STUPID и SOLID. Следует иметь в виду, что это принципы, а не законы. Однако, рассматривая их в качестве законов было бы хорошо для тех, кто хочет усовершенствоваться в написании кода.

В своей предыдущей статье я рассказал, как объект может просто и надежно нести ответственность за свои ресурсы.

Но есть множество вариантов владения, которые не являются персональной ответственностью объекта:

• Ресурсы, которыми владеют зависимости. При использовании Dependency Injection объект класса не только не должен отвечать за жизненный цикл своих зависимостей, он просто физически не может это делать: зависимость может разделяться между несколькими клиентами, зависимость может реализовать IDisposable, а может не реализовать, но при этом у нее могут быть свои зависимости и так далее. Кстати, этот довод сразу ставит крест на любых бизнес-интерфейсах, расширяющих IDisposable: такой интерфейс требует от своих реализаций невозможного — отвечать за себя и за того парня (зависимости)
• Ресурсы, которые при некоторых условиях не надо очищать. Это, к примеру, дурная привычка StreamReader закрывать нижележащий Stream при вызове Dispose
• Ресурсы, которые являются внешними по отношению к зависимости, но требуются клиенту в процессе ее использования. Самый простой пример — подписка на события объекта при присвоении его свойству.

Вкратце, в этой статье речь пойдёт о правиле наследования Лисков, о различии контрактов NotifyCollectionChangedAction.Reset в версиях .NET Framework 4 и .NET Framework 4.5, и о том, какой из этих двух контрактов истинный, а какой — ошибочный.

Казалось бы, данный шаблон не просто прост, а очень прост, подробно разобран не в одной известной книге.

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

Хочу поделиться своим способом реализации, который основан на минимизации изобретения велосипедов, максимальном уменьшении количества кода и увеличении его выразительности и прозрачности.

Статья посвящена такому интересному и полезному механизму (совокупностям механизмов и библиотек), как Fork/Join Framework. Он позволяет многократно ускорить вычисления, добиться максимальных результатов при обработке, используя все доступные возможности системы (процессоры).

В рамках данной статьи будет созданы классы, использующие Fork/Join Framework. В коде показан один из возможных вариантов применения параллельного программирования. Итак, начнем.

Недавно попалась на глаза занимательная статья с аналогичным названием о языке Haskell. Автор предлагал читателю проследить за мыслью программиста, решающего типичную ООП задачу но в Хаскеле. Помимо очевидной пользы расширения представлений читателей о том, что ООП — это отнюдь не «классы» и «наследование», подобные статьи полезны для понимания того, как правильно пользоваться языком. Предлагаю читателю решить ту же самую задачу, но на языке Go, в котором ООП тоже реализован непривычно.

Здравствуйте, Хабр.

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

Здравствуйте! Вас приветствует редакция сайта GeekBrains.ru, сервиса онлайн-обучения программированию. Мы решили завести блог на Хабре! Уверены, что ещё успеем рассказать и обсудить много интересного из мира программирования, ИТ и онлайн-образования. Но начнём очень просто, без особых прелюдий, с обзора бесплатного курса по основам C# и ООП от одного из наших учеников. Слоган курса гласит «Сложная концепция простыми словами». Давайте же посмотрим, насколько это соответствует действительности.

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

В этой статье я бы хотел прояснить различия между DTO (Data Transfer Object), Value Object и POCO (Plain Old CLR Object), также известным как POJO в среде Java.

Пожалуйста, начинайте читать с начала серии: habrahabr.ru/post/267441

Как не надо использовать Docker.

Чтобы понимать эту статью надо знать базовые команды Dockerfile для создания изображений и принципы объектно-ориентированного дизайна.

Открываю документацию любого официального образа сервисного ПО — например, Nginx и нахожу раздел «How to use this image». Нам предлагают создать свой образ на базе официального, скопировав в него наши файлы, настроить мапинг порта в мир, и подмонтировать свою папку с конфигами.

FROM ...
COPY  . /usr/src/myapp
WORKDIR /usr/src/myapp

Да, нам предлагают унаследовать Model от View в одном звездном классе и заплатить за хранение на Docker Hub образов наших проприетарных приложений.