ООП *

Предыстория: вот, кажется, совсем недавно фирма, в которой я трудился Delphi программистом, издала последний вздох и развалилась. Юридически возможно и нет, но большое число сотрудников начало искать себе новое место работы, в том числе и я. Не буду дискутировать на счет востребованости сейчас desktop подхода, да и актуальности Delphi, но я решил воспользоваться сложившейся ситуацией для смены рода деятельности. А именно изучив предложения по трудоустройству в моем регионе (мелкий областной центр) я решил стать Web разработчиком на PHP. И в итоге мои НГ праздники прошли больше за книгой, нежели за праздничным столом.

Почти сразу я столкнулся с ситуацией меня немного смутившей: как язык, на котором крутится большинство сайтов интернета, в оном уже определилось абсолютное преимущество UTF-8, не имеет более-менее вменяемой его поддержки. Прочитав о стандартном методе решения – расширении mb_strings я успокоился, но некоторое неудобство в использовании оставило свой осадок. А именно: отсутствие метода доступа к символу как элементу массива и аналогов ряда стандартных функций в их мультибайт аналогах. Но задерживаться было нельзя, я и дальше штудировал литературу и по разным вопросам обращаясь к Google, но постоянно натыкался на топики начинающих о неудобстве работы с мультибайт строками и ожидании PHP6. Честно говоря, они мне даже поднадоели. Если в прямом виде аналогов в mb_strings нет, но все необходимое для собственной реализации было.

Всем привет! С прошедшим концом света и с наступающими праздниками :)
В качестве подарка сообществу Open Source, а так же любителям антиквариата, мы (совместно с товарищем humbug) решили выложить нашу последнюю исследовательскую разработку.

Предлагаем вашему вниманию с нуля переписанную на C++ реализацию виртуальной машины, совместимую с Little Smalltalk. На данный момент написан код виртуальной машины и реализованы базовые примитивы. Humbug написал серию простых тестов, которые, тем не менее, помогли обнаружить проблемы и в оригинальной версии VM. Реализация бинарно совместима с образами оригинального LST пятой версии.

Месяц работы, 300+ коммитов. А что получилось в итоге, можно узнать под катом.

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

Прочитав недавний топик "Использование try — catch для отладки" решил все таки в качестве дополнения поделиться и своим опытом.

В этой статье предлагаю рассмотреть получение callstack’а места, где было брошено исключение в случае работы со
структурными исключениями (MS Windows). В детали работы исключений вдаваться не будем, т.к. это тянет на отдельный цикл статей (для интересующихся рекомендую Рихтера, MSDN и wasm.ru). Конечно, есть много уже готовых проектов для генерации minidump’ов (например CrashRpt или google-breakpad), так что эта статья носит больше образовательный характер.

Что делать с полученным стеком вызовов — решать вам. Можно смотреть отладчиком, можно записать в файл и смотреть сторонней программой (для этого не забудьте записать список загруженных модулей с их адресами, а так же вам понадобятся отладочные символы).

Итак, вы написали программу, запустили в отладчике — все хорошо, все нормально. Поставили в рабочий процесс — валится. Причем, в самых неожиданных местах.
Что делать?
Начинаем думать. Везде ставить try-catch… вычислительный блок будет здорово тормозить. Значит, надо сделать отладочную версию. Значит, вводим
#define __TRY__DEBUG__

Хотел бы поделиться своей находкой: IBM SOM. Согласно Википедии, жил да был некогда Microsoft с COM, и был IBM с SOM. В Windows и OS/2, соответственно. И были для них средства межсетевого взаимодействия: DCOM и — как вы думаете? — правильно, DSOM. Такая вот идиллия, что может сложиться впечатление, что это близнецы. Только вот в SOM было наследование, а в COM — нет, и в журналистских статейках, на которые ведут ссылки из Википедии, только об этом и речь.

В прошедний понедельник мне посчастливилось попасть на собеседование на Senior .Net Developer в одну международную компанию. Во время собеседования мне предложили пройти тест, где ряд вопросов был связан с .Net. В частности в одном из вопросов надо было дать оценку (истина/ложь) ряду утверждений, среди которых было и такое:

В .Net любой массив элементов, например int[], по умолчанию реализует IList, что позволяет использовать его в качестве коллекции в операторе foreach.

Быстро ответив на этот вопрос отрицательно и отдельно дописав на полях. что для foreach необходима реализация не IList, а IEnumerable, я перешел к следующему вопросу. Однако по дороге домой меня мучал вопрос: реализует ли массив все-таки этот интерфейс или нет?

Про IList я смутно помнил, что этот интерфейс дает мне IEnumerable, индексатор и свойство Count, содержащее число элементов коллекции, а также еще пару редко используемых свойств, типа IsFixedCollection(). Массив имеет свойство Length для своего размера, а Count в IEnumerable является методом расширения от LINQ, что было бы невозможно, если бы этот метод был реализован в классе. Таким образом, получалось, что массив не мог реализовывать интерфейс IList, однако какое-то смутное чувство не давало мне покоя. Поэтому вечером после интервью я решил провести небольшое исследование.

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

В этой статье хочу поделиться своим опытом использования данного инструмента в реальном проекте. Нужно было сделать удаленную админ панель и через api реализовать управление сайтами-клиентами. Требования: модульность, оптимизация под нагрузки, использование API Youtube, ЧПУ.

Далее я буду указывать конкретную задачу, а напротив опишу какие инструменты использовались и насколько эффективно:

Хочу рассказать о применении шаблона Active Record для C# на практике. Такой класс реализует извлечение и запись структуры в базу данных. Бизнес логика выносится на следующие уровни абстракции, где с таким объектом можно работать уже как с обычной структурой.

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

Использование active record объекта в коде бизнес логики выглядит вот так:

Country russia = Country.All[“Russia”];

Однажды на лекции друг рассказал мне, что существует язык программирования пони, (основанный на сериале, конечно). Он сказал, что видел его на reddit, но даже после продолжительного поиска я смог найти только пустой репозиторий на Google Code без деталей реализации. Я был очень этим разочарован, но только на несколько минут, пока не понял, что могу написать реализацию этого языка сам. Возможно, она не будет хороша или вообще используема в том смысле, что не каждый сможет написать к ней интерпретатор, но мне хотелось проверить свои умения. А ещё мне нравятся затянувшиеся шутки.

Где-то полтора года назад я начал заниматься web разработкой. Начинал с функционального программирования. Примерно пол года назад я перешел на ООП и стал использовать MVC архитектуру проектирования. Недавно появилась задача оптимизировать работу с базой данных, т. к. вся связь и работа с базой осуществлялась через один класс. Это было неудобно потому, что все время приходилось вручную писать SQL — запросы.

— Прототипное наследование — это прекрасно
JavaScript — это объектно-ориентированный (ОО) язык, уходящий корнями в язык Self, несмотря на то, что внешне он выглядит как Java. Это обстоятельство делает язык действительно мощным благодаря некоторым приятным особенностям.

Одна из таких особенностей — это реализация прототипного наследования. Этот простой концепт является гибким и мощным. Он позволяет сделать наследование и поведение сущностями первого класса, также как и функции являются объектами первого класса в функциональных языках (включая JavaScript).

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

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

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

Слишком часто стала мелькать в западных блогах и твиттере аббревиатура “DCI”. Меня удивил тот факт, что на хабре по данной тематике почти нету информации, лишь в Ruby NoName Podcast S04E09 упоминалось об этом. Любопытство взяло вверх, и я решил узнать об этом загадочном слове побольше. В процессе поиска я наткнулся на хорошую статью, написанную на английском моим земляком, Виктором Савкиным. Данная статья без обильной теории, на практических примерах показывает, что из себя представляет DCI. Далее повествование будет идти от лица Виктора.

В этой статье я расскажу о некоторых новшествах, появившихся в проекте 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, в голову пришла реализация частичного применения метода, именно метода, а не функции.