ООП *

В этой статье я расскажу о некоторых новшествах, появившихся в проекте AMatch с момента написания первой статьи.

Напомню, что AMatch — класс, с помощью которого валидация входных параметров из большого набора if-ов превращается в удобную, лаконичную запись. К примеру:

Example: simple

$match = AMatch::runMatch($params)
	->doc_id(0, '<') // Левое значение меньше
	->subject_id(0, '!=') // Не равен нулю
;
$result = $match->stopMatch();
if (!$result) {
	die(var_export($match->matchComments(), true)); // для наглядности умрём
}

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

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

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

В последние лет 15-20 появилось невероятное количество новых языков программирования. Многие из них представляются как «истинные» объектно-ориентированные языки или, как минимум, языки с поддержкой объектно-ориентированного программирования (ООП). Во всяком случае, особенно подчёркивается то, что на этих языках можно вести разработку, придерживаясь объектно-ориентированной методологии. Чтобы язык программирования являлся ООП-языком, он должен реализовывать некоторую Объектную модель. В связи с тем, что ООП из вида программирования превратилось в нечто, что ближе к концепции и методологии, разные языки стали придерживаться более-менее одной и той же объектной модели. Но, кроме того, эти языки обросли разными синтаксическими конструкциями, часть из которых относится к так называемому «синтаксическому сахару», которые позволяют производить некоторые часто осуществляемые действия над объектами более компактно.
В связи с тем, что в большинстве языков программирования объектная модель сильно усложнена, попробуем определить описание, так скажем, «ровной» Объектной модели, убрав из неё по возможности всё лишнее.

Вступление

Как все мы знаем javascript это язык в котором очень просто выстрелить себе в ногу. Работая с этим языком уже почти пять лет, я не раз сталкивался с тем, что javascript предоставляет очень скудные инструменты для создания абстракций высокого уровня. А, создавая полноценные MVVM/MVP приложения, сталкиваешься с тем что, основной проблемой является трудность сохранить код и абстракцию в чистоте, не говоря уж о полноценном следовании SOLID принципам.

Со временем я пришел к пониманию, что один из основных паттернов который смог бы мне помочь -это Dependency Injection. И я решил поэкспериментировать с ним в JS.
Конечно, JS не предоставляет инструментов для полноценного следования этому паттерну (элементарное отсутствие тех же рефлекшенов), поэтому я решил поставить для себя несколько Acceptance Criteria, которых я хотел бы достигнуть адаптировав этот паттерн к такой уникальной среде как JS.

После появления статей типа "Я не знаю ООП" — возникает желание внести ясность, «сорвать покровы» и «докопаться до истины».

Принципы объектно-ориентированности

Обычно выделяют (читай: на собеседовании требуют назвать) четыре «принципа объектно-ориентированного программирования»: абстракцию, инкапсуляцию, наследование и полиморфизм.

На мой взгляд (не говоря о том, что абстракция и полиморфизм могут быть запросто отнесены к подразделам наследования), принцип тут один, в общем, тот же самый, что при проектировании баз данных: представление всего в виде объекта — некоторой штуковины со свойствами. Набор обычно бывает фиксированным, и тогда говорят о классе объектов, а даже если понятия класса и нет, то наличие свойств с определёнными названиями подразумевается логикой программы, т.е. нечто типа класса в виде некоего минимального набора свойств всё равно присутствует. В общем, воззрения восходят к давнему С-шному/паскалевскому типу данных struct/record. Потом к этому добавили немного «функциональности» (в смысле функционального программирования): значением свойства может быть функция, причём такая, которая имеет доступ к самой структуре/записи, значением одного из свойств которой она является. Сей феномен, в лучших традициях немецкого латиноязычного нейминга (когда опция называется «вариантом», а степень числа — «потенцией»), назвали «методом». Желание повторно использовать код, в сочетании с представлением каждого предмета как некоего подобия паскалевской «записи», привело к появлению концепции «наследования».

Вдохновившись статьей Еще раз о каррировании и частичном применении в PHP, в голову пришла реализация частичного применения метода, именно метода, а не функции.

Есть интересная идея реализации некоторого обработчика суперглобальных массивов, на примере суперглобального массива $_REQUEST.
Простой способ получить, обработать, обезопаситься за полученные данных с формы и тп. выглядит

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

Суть метода предельно проста: если каждый объект является переменной какой-либо области видимости или простым («стековым») членом другого объекта, то даже при аварийном закрытии программы от необработанного исключения, всегда будет происходить корректная очистка. Задача заключается в том, чтобы свести всё многообразие динамических сценариев к этой схеме.

Всем привет.

Неделя статей на хабре посвященная ООП. Последняя статья вызвала у меня кучу эмоций и, к сожалению, очень плохих эмоций. Мне очень не понравилась статья. Почему? Потому что в ней передаются какие-то отрицательные эмоции об использовании ООП. Эмоции вызваны лишь тем, что человек не до конца понимает всю силу ООП и хочет убедить всех в том что ООП зло. Самое печальное что люди начинают прислушиваться и кидаться ужасными доводами, не имеющими ничего общего с действительностью. Я думаю что студентам такие статьи противопоказаны больше чем GoF, которых я бы давал как можно раньше. :)

Начнем.

В текущем проекте стала часто возникать необходимость конструирования множеств разнообразных объектов по каким-то идентификаторам. Была написана одна фабрика для какого-то множества, другая. Потом пришло понимание, что мы делаем одно и то же и нужно какое-то повторяемое решение.
Проект базируется на Qt, который, как известно, имеет развитые механизмы работы с метаданными. Тем не менее конструирование объектов через QMetaObject нас не удовлетворяло по двум причинам: во-первых конструируемые объекты должны быть QObject'ами, а во-вторых при конструировании мы получаем указатель на QObject, который так или иначе придется преобразовывать, что чисто эстетически некрасиво.

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

BaseClass * instance = BaseClass::factory()->build("derived_name");

При этом, мы не хотим писать каждый раз много однообразного служебного кода. Да, мы ленивые.
И конечно же мы не хотим чтобы фабрика или базовый класс знали о всех наследниках.

Я не умею программировать на объектно-ориентированных языках. Не научился. После 5 лет промышленного программирования на Java я всё ещё не знаю, как создать хорошую систему в объектно-ориентированном стиле. Просто не понимаю.

Я пытался научиться, честно. Я изучал паттерны, читал код open source проектов, пытался строить в голове стройные концепции, но так и не понял принципы создания качественных объектно-ориентированных программ. Возможно кто-то другой их понял, но не я.

И вот несколько вещей, которые вызывают у меня непонимание.

… и функциональное программирование тоже.

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

Потому что программирование — это искусство оперирования абстрактной информацией. Это очень сложное искусство — поскольку человеческий мозг вообще не приспособлен для оперирования абстракциями.

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

Почему я люблю функциональное программирование? Потому что оно позволяет мне держать в голове workflow моих объектов в виде конвейера, где на каждом шаге применяется новая операция.

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

Когда я первый раз услышал об объектно-ориентированном программировании — сразу отнёсся к нему скептически. Честно говоря, даже не знаю, почему. Просто оно показалось мне каким-то неправильным. Но ООП очень быстро стало популярным (почему — я объясню ниже) и критика в его адрес превратилась в этакую «ругань в церкви». А объектно-ориентированность стала обязательной составляющей любого уважаемого языка программирования.

С ростом популярности Erlang часто стали задавать вопрос «— А Erlang — объектно-ориентированный?». Правильный ответ был бы «— Да что вы, нет!». Но мы не могли так заявлять в полный голос, поэтому пришлось выкручиваться. Мы придумали несколько достаточно нетривиальных ответов, которые бы представляли Erlang типа-объектно-ориентированным языком (для тех, кто больше всего тянет руку с этим вопросом), но при этом и не объектно-ориентированным для тех, кто на самом деле в теме.

Первый релиз FuelPHP, честно говоря, не был особо примечателен и не выделялся из линейки других фреймворков. Даже для меня, человека, который успел освоить к тому времени только CI и Kohana, непримечательность первой версии была очевидна. Но было нечто и то, что в этом молодом проекте завораживало. Этим “нечто”, как ни странно, была надежда. Надежда на то, что Fuel ещё расцветет нужным функционалом, который будет подпитываться свежими идеями.
Первый релиз был сплавом идей CodeIgniter, Kohana, Rails и 9-ти месячного труда, более чем сорока разработчиков. С тех пор минул год, на что потратили его разработчики и каким стал их проект? Об этом делее.

Moose — расширения для Perl 5, позволяющее упростить реализацию ООП.

Создание класса происходит очень легко:

package MyClass;
use Moose;

все, пустой класс создан. Он может иметь произвольное количество: аттрибутов, методов, суперклассов, модификаторов метода, конструктор(1шт), деструктор(1шт) и мета-класс(1шт) который содержит все метаинформацию о данном классе.

Теперь подробнее об этих составляющих:

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

• Побеседовать на тему «ООП с человеческим лицом».
• Разобраться с прототипами в javascript, коротко и сердито!
• Вспомнить, что «замыкание» это не только ценный мех… удар током.
• Написать на javascript класс Timer — этакий планировщик событий для запуска анимаций, событий, любых функций.
• Весело провести время!

Предупреждение! Если вы не ждете от статьи ничего веселого… то ошибаетесь. Людям с пониженным чувством юмора читать… еще более рекомендуется! Ну-с, приступим…

Неожиданно оригинальный подход я увидел тут в описании одной вакансии.

Дабы не сочли рекламой — всю инфу о работодателе выпилил.

Но за описание вакансии средствами ООП — однозначный респект!

public class JediJob extends GameDevJob implements IRemoteJob {
...

Полный исходник не влез до ката.

(Перевод)

Последние несколько лет я провел в изучении и экспериментах со многими языками программирования. В частности, я начал использовать Scala как основной язык, стараюсь использовать функциональный стиль везде где это возможно. Меня также весьма заинтересовал Haskell (чистый функциональный язык) и Clojure (современный диалект Лиспа).

Таким образом, я постепенно отказываюсь от объектно-ориентированной парадигмы, несмотря на то, что использовал в основном её последние 17 лет моей профессиональной деятельности. У меня появляется чувство, что объекты это то, что мешает нам писать лапидарный, структурированный и повторно используемый код.

Недавно мне задали вопрос: как бы я реализовал механизм виртуальных функций на языке C?

Поначалу я понятия не имел, как это можно сделать: ведь C не является языком объектно-ориентированного программирования, и здесь нет такого понятия, как наследование. Но поскольку у меня уже было немного опыта с C, и я знал, как работают виртуальные функции, я подумал, что должен быть способ сымитировать поведение виртуальных функций, используя структуры (struct).

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

Давайте теперь посмотрим на простой пример использования виртуальных функций в C++

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

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

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