Как стать автором
Поиск
Написать публикацию
Обновить
19.03

ООП *

Объектно-ориентированное программирование

Сначала показывать
Порог рейтинга
Уровень сложности

Паттерны ООП в примерах для iOS

Время на прочтение48 мин
Количество просмотров150K

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


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

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

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

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

Объектный пул и быстрое создание объектов в куче

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

Архитектура агрегаторов: паттерны веб-сервисов (Часть 1)

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

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

Внутреннее устройство llst, часть 3. Магия JIT, или как ускорить виртуальную машину в 50 раз

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

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

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

Что так с ООП и ФП, и что не так с программированием

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



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

Что не так с ООП и ФП

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

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

Squeak: Моделирование систем массового обслуживания

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

Пару слов о Squeak


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

Active Record против Data Mapper-а для сохранения данных

Время на прочтение4 мин
Количество просмотров84K
Эти 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 — просто метод-заглушка, заменяющий бизнес логику.
Читать дальше →

Из опыта создания кружка программирования для детей

Время на прочтение6 мин
Количество просмотров26K

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


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

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


Читать дальше →

Правильно программируем. Используем полиморфизм. Общая логика игровых персонажей

Время на прочтение23 мин
Количество просмотров78K

Unity3D. ИСПОЛЬЗУЕМ ПРЕИМУЩЕСТВА ООП. ПОЛИМОРФИЗМ


ВНИМАНИЕ!
Сразу хочу предупредить, читайте комментарии к статье, там KumoKairo предложил более совершенный подход к решению поставленных в статье задач.


Доброго времени суток. В этом уроке мы рассмотрим несколько важных приемов программирования на движке Unity 3D. Думаю, статья поможет как начинающим, так и опытным игроделам.

Целью статьи ставлю осознание мощи и безграничной удобности использования всех прелестей ООП. В частности ПОЛИМОРФИЗМ. Кроме того затронем несколько других важных вопросов.

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

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

Живая бифидопрограмма

Время на прочтение5 мин
Количество просмотров8.2K
image
То, что происходит внутри программы очень похоже на деятельность команды из нескольких человек. У каждого члена команды есть своя задача и, скорее всего, своё «рабочее место» к которому никто кроме него не должен прикасаться. Коллеги могут давать друг другу поручения и передавать какую-нибудь информацию о рабочем процессе. Они могут просить друг у друга помощи и могут оказывать её. Как и у любой команды у них есть начальник, в задачу которого входит взаимодействие с пользователем и координация действий внутри команды.

При таком взгляде на программу она оживает, и всё происходящее внутри неё начинает обретать какие-то образы. Распределив все рабочие процессы и задачи по различным «работникам» начинаешь понимать как всё должно работать.

Исходные коды плеера, на который я когда-то потратил кучу времени, уже давно пылятся на жестком диске. Я писал это приложение в течении года когда появлялось настроение. В конце концов у меня иссяк энтузиазм и плеер был забыт. И вот недавно мне в голову пришла идея архитектуры, которая, как оказалось, отлично к нему подходит — о ней далее и пойдет речь. Я выделю «работников» в приложении, и распределю роли так, чтобы у каждого работника была чёткая, максимально простая, и понятная задача.
Читать дальше →

Tell-Don’t-Ask

Время на прочтение2 мин
Количество просмотров18K
Tell-Don’t-Ask является принципом, который помогает вспомнить, что объектно-ориентированное программирование предназначено для связки данных и функций для их обработки. Он напоминает нам, что вместо того, чтобы спрашивать данные у объекта, мы должны сказать объекту что с ними делать. Для этого все поведение объекта надо заключить в его методы.
image
Читать дальше →

Паттерн Стратегия на Javascript

Время на прочтение7 мин
Количество просмотров35K
От переводчика:
Я собрался изучить новый для меня паттерн Стратегия, но не нашёл толкового русского описания его реализации на javascript. Статья на wiki пугает своей сложностью, а наглядность примера оставляет желать лучшего. По этому и взялся за перевод этой статьи, одновременно разбираясь, что же из себя представляет данный паттерн.
Спойлеры и текст, выделенный серым, являются моими комментариями.

Далее мы разберём примеры того, как я использую СТРАТЕГИЮ в Javascript, и как он используется реальной библиотекой, для разбиения её на небольшие части.
поехали

Ближайшие события

Понимание ООП на джаваскрипте (ES5), часть 2

Время на прочтение12 мин
Количество просмотров45K


Замечания о переводе
Поднимаю продолжение заброшенного перевода, поскольку вопросы в оригинале вплотную переплетаются с вопросами наследования, сделанными в собственной компактной библиотеке для использования без фреймворков, имеющих поддержку ООП. Пусть то и другое не оригинально, но вместе даёт понимание работы наследования.

Для полноты статьи и единого стиля, перевод начинается с вопросов наследования, несмотря на то, что они уже были упомянуты в конце первой части. Далее рассматриваются разнообразные задачи наследования так, как их рассмотрел автор. Надо сказать, что автор широко использует новые конструкции ES5 (объяснив это в конце), которые работают не во всех браузерах и заслоняют от понимания реализацию их на низком уровне языка, на котором они изначально применялись. Для настоящего понимания наследования следует обратиться к более глубокому разбору реализаций или к реализациям методов-обёрток из ES5: Object.create, Object.defineProperty, Function.bind, get и set literals, Object.getOwnPropertyNames, Object.defineProperty, Object.getOwnPropertyDescriptor, Object.getPrototypeOf. Часть их разбирается в статье (Object.create, get и set, Object.defineProperty, bind), но не всегда в порядке появления. Таким образом, статья стремится преподнести не реализацию наследования вообще, а ту реализацию, которую успели формализовать в рабочем черновике стандарта EcmaScript 5. Это лучше, чем ничего, но несколько меньше, чем полное понимание реализаций наследования.

Зато, данная часть статьи в нескольких (4) крупных примерах кода демонстрирует чистейшее прототипное наследование, которому не требуется привлекать понятие конструктора (хотя он там, в .create(), незримо присутствует), о котором много говорят и которое исключительно редко в чистом виде встречается.
Краткое содержание первой части
1. Объекты
  1.1 Что есть объекты? (список свойств)
  1.2 Создание свойств (Object.defineProperty)
  1.3 Описатели свойств (Object.defineProperty)
  1.4 Разбор синтаксиса (bracket notation: object['property'])
  1.5 Доступ к свойствам (через скобочную нотацию)
  1.6 Удаление свойств (оператор delete)
  1.7 Геттеры и сеттеры (методы доступа и записи)
  1.8 Списки свойств (getOwnPropertyNames, keys)
  1.9 Литералы (базовые операторы) объекта
2. Методы
  2.1 Динамический this
  2.2 Как реализован this
    2.2.1 Если вызывается как метод объекта
    2.2.2 При обычном вызове функции (this === global)
    2.2.3 При явном указании контекста (.apply, .call)
  2.3 Привязывание методов к контексту (.bind)
Cодержание части 2
3. Прототипное наследование
  3.1 Прототипы
  3.2 Как работает [[Prototype]]
  3.3 Переопределение свойства
  3.4 Миксины (примеси)
  3.5 Доступ к экранированным ('перезаписанным') свойствам
План части 3
4. Конструкторы
  4.1 Магия оператора new
  4.2 Наследование с конструкторами
5. Соглашения и совместимость
  5.1 Создание объектов
  5.2 Определение свойств
  5.3 Списки свойств
  5.4 Методы связывания
  5.5 Получение [⁣[Prototype]⁣]
  5.6 Библиотеки обратной совместимости
6. Синтаксические обёртки
7. Что читать дальше
8. Благодарности
Примечания

3. Прототипное наследование


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

Далее в игру вступает наследование. Оно лучше разделяет понятия, когда объекты наделяются своими методами на основе методов других объектов.

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

Чертежи в SVG формате. Часть 1 — Черновик стандарта

Время на прочтение4 мин
Количество просмотров20K
В интернете можно найти много разной информации о создании чертежей в формате SVG. Чаще предлагается какой-то редактор и экспорт из формата DXF в SVG. Просматривая код SVG сразу видно что там много лишнего. Созданный в одном редакторе файл SVG не всегда может корректно открыться в другом. Одно радует, что браузеры начали поддерживать SVG формат. Всюду пишут про недостатки использования SVG. А может надо придерживаться единых правил структуры файла для отображения чертежей?
Читать дальше →

Развитие пользовательских типов данных в программировании

Время на прочтение16 мин
Количество просмотров38K
Хотелось бы остановиться и посмотреть на развитие языков программирования с точки зрения развития пользовательских типов данных (ПТД).
Сразу хочу оговориться, под пользователями понимаются программисты, как люди, пишущие код на этих языках. Ну, и те, кто этот код сопровождает или просто читает.

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

Пользователи желают иметь примерно такие типы данных

Пользователи хотели иметь возможность составлять данные так, как они сами того хотят. Хотели, хотят, и наверняка будут хотеть. Всё больше, всё разнообразней и сильнее.
Именно поэтому полезно проследить за развитием пользовательских типов данных в программах и языках программирования.
Читать дальше →

Полиморфизм без виртуальных функций

Время на прочтение15 мин
Количество просмотров38K
В этой статье представлен паттерн, который может быть использован для обеспечения динамического связывания без использования виртуальных функций для вызова перегруженных методов для объектов неоднородного контейнера при его обходе.
Читать дальше →

Советы новичкам при проектировании модульных производственных систем

Время на прочтение7 мин
Количество просмотров20K
В этой статье я попытаюсь поделиться своим опытом в проектировании пользовательской бизнес-логики. Это явно не претендует на полноценный ликбез, т.к. я всего лишь вспоминаю то, через что прошёл лично я, какие ошибки я допустил, и как мне их удалось (или не удалось) исправить в будущем. Наверняка, опытные системные архитекторы уже все проходили и знают, однако надеюсь, что некоторые советы таки будут полезны.
Мы использовали (и используем) клиентскую часть на WPF/Silverlight, WCF сервисы и СУБД Oracle, Postrges, MsSQL. Код написан по MVVM, использована Prism для модульности и навигации. Не могу точно сказать, какие из тезисов подойдут для других платформ и языков.

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

Итак, поехали.
Читать дальше →

Классы в lua, или избавляемся от двоеточия

Время на прочтение4 мин
Количество просмотров30K
Как всем известно, в lua нет как таковых классов и объектов. Однако есть метатаблицы и синтаксический сахар.
С помощью указанных механизмов достаточно просто реализовать подобие классов.
В итоге и получается нечто такое:
Самый простой класс
local MyClass = {} -- the table representing the class, which will double as the metatable for the instances
MyClass.__index = MyClass -- failed table lookups on the instances should fallback to the class table, to get methods

-- syntax equivalent to "MyClass.new = function..."
function MyClass.new(init)
  local self = setmetatable({}, MyClass)
  self.value = init
  return self
end

function MyClass.set_value(self, newval)
  self.value = newval
end

function MyClass.get_value(self)
  return self.value
end

local i = MyClass.new(5)
-- tbl:name(arg) is a shortcut for tbl.name(tbl, arg), except tbl is evaluated only once
print(i:get_value()) --> 5
i:set_value(6)
print(i:get_value()) --> 6

(взято с lua-users.org/wiki/ObjectOrientationTutorial)

Всё это конечно хорошо, даже при определённой сноровке можно реализовать наследование…
Но где public и private члены класса? Дефакто в этом примере они все public. Да ещё и надо помнить, где использовать двоеточие:
MyClass:myFunc()

а где просто одну точку:
MyClass.myOtherFunc()

А статические члены класса? Неужели придётся отказываться?
Вот я и не захотел отказываться, и начал колхозить...

Вклад авторов