ООП *

Когда я изучал язык Go, мне очень понравилась идея с приведением к интерфейсам по сигнатурам методов (остальная часть системы типов мне не понравилась, слишком примитивная). Это ведь статическая утиная типизация! По научному: структурная типизация.

Если вдуматься, у такого подхода куча недостатков: начиная со сложности реализации и заканчивая нарушением принципа подстановки Лисков. Ведь если у класса есть метод с нужной сигнатурой (включая название), это совсем не значит, что этот метод делает то, что ожидается.
Поэтому в мейнстрим языках, в том числе в C#, структурная типизация не поддерживается. Казалось бы на этом и сказке конец. Но недавно я осознал что в проекте, которым я сейчас занимаюсь, структурная типизация применяется. Подробности под катом.

Доброго времени суток, хабравчане!

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

Введение

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

Тема заезженная до дыр, не спорю… Вероятно, для опытных разработчиков моя статья будет мало, чем полезна. Я бы рекомендовал её к прочтению тем, кто только начал осознавать, что его коду чего-то не хватает, и что он созрел для вникания в это далёкое понятие – «паттерны». По себе помню, что довольно долгое время я путался в шаблонах, иногда даже не понимая, чем один отличается от другого. Именно этот факт стал основой для моей статьи. Примеры в ней не будут реальными. Они будут абстрактными и максимально простыми. Однако я постараюсь все примеры держать в едином контексте, чтобы можно было наглядно видеть отличия их использования в одной и той же ситуации. Я не буду нагружать классы лишним функционалом, чтобы можно было понять, какая именно часть кода имеет непосредственное отношение к шаблону. Главными героями примеров станут Factory (фабрика) и Product (продукт, производимый этой фабрикой). Возьмём это отношение за отправную точку. Возможно, в некоторых примерах это будет не очень уместно, но зато очень наглядно…

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

Добрый день коллеги, сегодня я расскажу сказку о своём опыте организации контроллеров в проекте на ZF 1 (так исторически сложилось).
В хороших книжках по ООП часто пишут, что наследованием нельзя увлекаться, нужно предпочитать делегирование или делать так, чтобы они работали совместно. К сожалению, не всегда можно быстро догадаться, как применить сухую теорию на практике (а когда наконец-то доходит, удивляешься «что тут сложного?»), поэтому надеюсь мой опыт кому-нибудь пригодится.

И так сначала о проблемной области:
31 Controller Action, большинство из них имеет методы indexAction(), addAction(), editAction(), searchAction().
проблема №1: большинство, но не все. В остальных наличие этих методов варьируется,
проблема №2: методы editAction() и addAction() массивные сами по себе, и почти одинаковые для всех контроллеров, отличаются инициализация формы, и сохранение модели.

Как я это решил, покажу сразу в коде.

Доброго времени суток!
Model-View-Presenter — довольно известный шаблон проектирования. С первого взгляда все выглядит просто: есть Модель (Model), которая содержит всю бизнес-логику экрана; Вид/Представление (View), который знает, как отобразить те или иные данные; Представитель (Presenter), который является связующий звеном — реагирует на действия пользователя во View, изменяя Model, и наоборот.
Сложность начинается, когда количество форм в проекте становится более одной.
В данной статье рассматривается:
— немножко теории;
— общие проблемы реализации MVP (а именно Passive View) под Windows Forms;
— особенности реализации переходов между формами и передача параметров, модальные окна;
— использование IoC-контейнера и шаблона Dependency Injection — DI (а именно Сonstructor Injection);
— некоторые особенности тестирования MVP приложения (с использованием NUnit и NSubstitute);
— все это будет происходить на примере мини-проекта и постарается быть наглядным.
В статье затрагивается:
— применение шаблона Адаптер (Adapter);
— простенькая реализация шаблона Контроллер приложения (Application Controller).
Для кого эта статья?
Главным образом для начинающих разработчиков на Windows Forms, которые слышали, но не пробовали, или пробовали, но не получилось. Хотя уверен, что некоторые приемы применимы и для WPF, и даже для веб-разработки.

Алан Кей, автор SmallTalk, работает над экспериментальной системой STEPS – средой, которая способна заменить собой операционную систему и прикладные программы, при этом объём кода этой среды не должен превышать 20 000 (двадцать тысяч!) строк кода. Возможно, многие об этом уже слышали. Это одна из попыток воплощения мечты любого программиста: написать всё заново и красиво. Но возможно ли это?

Тема SOLID-принципов и в целом чистоты кода не раз поднималась на Хабре и, возможно, уже порядком изъезженная. Но тем не менее, не так давно мне приходилось проходить собеседования в одну интересную IT-компанию, где меня попросили рассказать о принципах SOLID с примерами и ситуациями, когда я не соблюл эти принципы и к чему это привело. И в тот момент я понял, что на каком-то подсознательном уровне я понимаю эти принципы и даже могут назвать их все, но привести лаконичные и понятные примеры для меня стало проблемой. Поэтому я и решил для себя самого и для сообщества обобщить информацию по SOLID-принципам для ещё лучшего её понимания. Статья должна быть полезной, для людей только знакомящихся с SOLID-принципами, также, как и для людей «съевших собаку» на SOLID-принципах.

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

(Впрочем, и связь с недавно вышедшей статьей Метаклассы в Objective-C отрицать не буду.)

Данная статья представляет собой перевод статьи What is a meta-class in Objective-C?

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

За годы преподавания и коммерческой разработки я повстречал много студентов и разработчиков, которые не до конца понимают смысл слова абстракция. Из многочисленных попыток разъяснить смысл этого термина получилась настоящая статья. Что Вы найдете под катом:

• Определение понятия абстракции и объяснение откуда оно взялось в ООП.
• Объяснение на простых примерах, что такое барьер абстракции, побочный эффект абстракции.
• Как получается хардкод.

^{В первых двух абзацах оригинального текста автор описывает как он пил пиво с друзьями. Я заменил их пятничной картинкой о гимнастике из детства.}

Объектная гимнастика (англ. Object Calisthenics) — это упражнения в программировании, которые состоят из 9 правил, которые Джефф Бей описал в своей книге «The ThoughWorks Anthology». Пытаясь как можно точней следовать этим правилам, вы измените свои привычки написания кода. Это не значит, что вы должны постоянно соблюдать все эти правила. Найдите баланс и используйте только те, которые вам удобны.

Эти правила сфокусированы на читаемости, тестируемости, понятности и поддерживаемости вашего кода. Если вы уже пишите код, который читаем, тестируем, понятен и поддерживаем, тогда эти правила помогут сделать его более читаемым, тестируемым. Понятным и поддерживаемым.

Ниже я прокомментирую этих 9 правил:

1. Только один уровень отступа в методе
2. Не используйте Else
3. Оберните все примитивные типы и строки
4. Коллекции первого класса
5. Одна точка на строку
6. Не используйте сокращения
7. Сохраняйте сущности короткими
8. Никаких классов с более чем 2 атрибутами
9. Никаких геттеров, сеттеров и свойств

От переводчика

Искали тут двух русскоязычных разработчиков — на iOS и на C++ под Windows. Видел десятки выполненных тестов. Разница в знании ООП между представителями двух платформ — огромная. На C++ обычно красивый расширяемый код, как само собой разумеющееся. На Objective C картина удручающая. Почти все iOS-кандидаты не знали ООП дальше своего носа NSString'ов и AppDelegate'ов.

Понятно, что плюсы учат по Страуструпу и «банде четырёх», а Objective C — больше по туториалам и Stack Overflow. Фастфуд-обучение не оставляет места на фундаментальные вопросы… Но такой разницы я не ожидал.

Поэтому я перевёл пост, в котором даны начальные сведения о шаблонах проектирования с примерами на iOS… «начальные»? Ага, значит, будет продолжение? Нет, не будет. Дальнейшие сведения вы получите из опыта, из попыток организовать процесс написания кода с помощью паттернов. Сначала не будет получаться, вероятно, фасад здания будет торчать из дымовой трубы, но потом придёт понимание, где какие приёмы реально помогают.

Качественная разработка ПО — творческий процесс, уникальный для каждой конкретной головы. Поэтому не существует общей инструкции: if (A and (B or C)) then use Pattern_N;

Хочу поделится очередным велосипедом собственной сборки на С++. Велосипед умеет быстро создавать и выдавать объекты. В результате получаем скорость создания (не отдачи) объектов на 30% быстрее чем просто с new. Объектный пул — вещь не новая, и в общем — чего о нем и говорить то. Но как говорится — главное в деталях.

Сегодня создано много веб приложений и сервисов, у которых одинаковая цель, но различный подход к исполнению. Так как информация разбросана по сети, пользователям приходится посещать множество аналогичных сервисов для того, чтобы увеличить эффект работы. К примеру, заказчик хочет разместить задачу на тендерной площадке. Для того, чтобы увеличить количество поданных заявок, он тратит время на повторяющуюся работу: создание офера и заполнение данных о проекте — на различных фриланс-биржах. Появляются сайты агрегаторы, которые пытаются решить эту проблему, но их поддержка становится все более затруднительной с появлением новых сервисов тематики агрегатора. Необходимо интегрировать все новые функции, и структуры данных, которые отличаются от сервиса к сервису. К счастью, мы не первые, кто создает и поддерживает подобные вещи: уже существуют паттерны, которые упрощают поддержку таких приложений и позволяют создавать гибкую архитектуру. В этой статье я хотел бы привести пример архитектуры агрегатора, который позволяет объединить тендерные площадки для фрилансеров — такие как Odesk, Freelancer, Elance и другие.

Основные проблемы с которыми сталкиваются разработчики:

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

Ранее мы познакомились с языком Smalltalk, а точнее с его микро реализацией Little Smalltalk. Разобрались с синтаксисом языка, форматом представления объектов в памяти и набором основных инструкций. Теперь мы вплотную подошли к вопросам взаимодействия Smalltalk и LLVM (ради этого и затевалась вся серия статей).

Сейчас у нас есть вся необходимая база знаний для того чтобы понять, что именно делается в нашем JIT компиляторе. В этой статье мы узнаем, как байт-коды Smalltalk преобразуются в IR код LLVM, как происходит компиляция и выполнение кода, и почему это работает быстрее, чем программная интерпретация. Самые нетерпеливые могут посмотреть шеллкасты (раз и два) с циферками и бегущими строчками (не забывайте про возможность скроллинга).

Так уж завелось на хабре, что на каждую холиварную статью «Pro» всегда найдётся статья «Contra».
Я тоже решил не оставлять в одиночестве пост «Что не так с ООП и ФП».



Прямо противоречить написанному смысла не имеет, там ведь описан «вкус», а, как известно, на вкус и цвет… каждый любит свой ЯП.
Нет никакой проблемы с ООП и ФП. Чистота функций — это всего лишь инструмент, равно как и «всё является объектом».
Критика права лишь в одном — в борьбе за миллиметры хорошо видны яркие прорехи, а в любых вырожденных методах недостатки ярко проявляются.
Другое дело, что любые невырожденные методы так же имеют недостатки, только их больше, зато они не так легко заметны.
Любители С++ гнобят полное ООП, Javа гнобит Си++ за неполное ООП, Haskell гнобит другие ФП за грязные функции, остальные ФП гнобят Haskell за излишне чистые функции.
Всё имеет свою оборотную сторону медали.
Тогда почему досталось всё объектам и функциям, а не массивам и указателям?!

Я не понимаю причины существования бесконечных споров вокруг Объектно-ориентированного (ООП) и Функционального (ФП) программирования. Кажется, что такого рода вещи находятся за пределами человеческого понимая, и о них можно спорить бесконечно. Много лет занимаясь исследованием языков программирования, я увидел четкий ответ, и зачастую я нахожу бессмысленным обсуждение этих вопросов.

Если кратко, то как ООП, так и ФП неэффективны, если доходить в их использовании до крайности. Крайностью в ООП считается идея о том что “все что угодно является объектом” (чистое ОП). Крайностью для ФП можно рассматривать чистые функциональные языки программирования.

На Хабре крайне мало информации о таком языке программирования как Squeak. Я попытаюсь рассказать о нем в контексте моделирования систем массового обслуживания. Покажу как написать простой класс, расскажу его структуру и использую его в программе, которая будет обслуживать заявки посредством нескольких каналов.

Пару слов о Squeak

Squeak это открытая, кросс-платформенная реализация языка программирования Smalltalk-80 c динамической типизацией и сборщиком мусора. Интерфейс довольно специфический, но вполне удобный для отладки и анализа. Squeak полностью отвечает концепции ООП. Все состоит из объектов, даже конструкции if-then-else, for, while реализованы с их помощью. Весь синтаксис сводится к посылке объекту сообщения в виде:

<объект> <сообщение>

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

Эти 2 шаблона проектирования описаны в книге Мартина Фаулера «Шаблоны корпоративных приложений» и представляют собой способы работы с сохранением данных в объектно-ориентированном программировании.

Пример шаблона Active Record

class Foo
{
    protected $db;
    public $id;
    public $bar;
     
    public function __construct(PDO $db)
    {
        $this->db = $db;
    }
 
    public function do_something()
    {
        $this->bar .= uniqid();
    }
 
    public function save()
    {
        if ($this->id) {
            $sql = "UPDATE foo SET bar = :bar WHERE id = :id";
            $statement = $this->db->prepare($sql);
            $statement->bindParam("bar", $this->bar);
            $statement->bindParam("id", $this->id);
            $statement->execute();
        }
        else {
            $sql = "INSERT INTO foo (bar) VALUES (:bar)";
            $statement = $this->db->prepare($sql);
            $statement->bindParam("bar", $this->bar);
            $statement->execute();
            $this->id = $this->db->lastInsertId();
        }
    }
}
 
//Insert
$foo = new Foo($db);
$foo->bar = 'baz';
$foo->save();

В этом упрощенном примере, дескриптор базы данных вводится в конструкторе Foo (Использование инъекции зависимостей здесь позволяет тестировать объект без использования реальной базы данных), и Foo использует его, чтобы сохранять свои данные. Do_something — просто метод-заглушка, заменяющий бизнес логику.

Появление кружка

Предыстория этого кружка началась два года назад. К тому времени я уже несколько лет подрабатывал репетитором информатики и программирования, в основном ученики по информатике программировали на Pascal, он больше распространен в школах.
А осенью 2011 года у меня появился необычный ученик: ребенок в 4 классе очень хотел заниматься программированием, и узнав что я обучаю Delphi мы с его мамой договорились что попробуем обучить на нём. Ребенок оказался очень одарённым, и у нас получилось очень хорошие и плодотворные занятия. И многие идеи появились только благодаря его постоянному интересу к программированию.

К тому времени я работал в кружке робототехники Дворца Молодёжи Свердловской области. И у меня появилась мысль организовать такой кружок программирования у нас. Для создания этого кружка прежде всего надо было определить несколько вещей:

• на какой возраст рассчитываем. Дело в том что я много изучал психологию (закончил психфак УрГПУ), и знаю что логическое мышление начинает развиваться (и наиболее хорошо развивается) начиная с младшего подросткового возраста. И занятия программированием будут в плане развития наиболее ценны для подростков. Это прежде всего это развитие способности держать в голове большие объёмы информации, и выстроенные между ними логические связи. Итак возраст был определён минимум от 11 лет и старше (рекомендуемый возраст 13-15 лет);
• цели обучения программированию (особенно учитывая возраст детей). Первая цель как написано выше — развивающая. Вторая цель — заинтересовать, приобщить детей к этому занятию. Именно поэтому (да простят меня сторонники традиционного обучения, требующие сначала обучать на обычном языке, а потом уже на объектно-ориентированном) было четкое понимание, что именно программы с графическим интерфейсом будут интересны детям. Итак мы переходим к третьему аспекту:
• в какой среде программируем. В качестве такой среды был выбран Lazarus. Во-первых синтаксис Pascal куда проще для детей, поэтому я решил отказаться от того же С#. От Delphi пришлось отказаться, потому что учреждение областного уровня не может позволить поставить пиратский софт, а на покупку софта для нового кружка скорее всего денег бы не нашлось. Поэтому был выбран бесплатный Lazarus