Как известно, классическое ООП покоится на трех китах
Классическая же реализация по умолчанию:
Но еще в 1986 году была обозначена серьезнейшая проблема, кратко формулируемая так:
На Хабре уже был перевод с обзором несколько месяцев назад, но недавно вышел первый релиз-кандидат PHP 7.1, а значит никаких существенных изменений больше не будет и можно сказать, какие точно изменения будут в релизе. Я решил немного оживить сухой “changelog” своим вольным переводом изменений, которые принесет нам новая минорная версия 7.х ветки.
Именно так и никак иначе: null в C# — однозначно ошибочное решение, бездумно скопированное из более ранних языков.
Этот ящик Пандоры был открыт еще при создании языка ALGOL W великим Хоаром, который позднее назвал собственную идею ошибкой на миллиард долларов.
Я не стал сильно заморачиваться и расписывать очевидные факты, но большинство моментов, которые меня пугают в коде, тут изложены. Я постарался сделать список особо лаконичным, чтобы вам не пришлось вчитываться, но и максимум понятным, чтобы даже новички поняли что так делать нельзя. В общем ниже список моих вредных советов, основанных на том, с чем я сталкиваюсь в повседневной жизни.
Итак поехали:
Читать полностью »
Концепция объектно-ориентированного программирования воспринимается разработчиками по-разному: кто-то говорит, что ей уже пора на свалку истории; кто-то кодит и не задумывается о том, что, как и почему он делает; а кто-то пытается работать в «pure OOP» парадигме, переворачивая классические паттерны с ног на голову.
В преддверии Joker 2016 мы попросили Баруха Садогурского обсудить судьбу Java и ООП с Егором Бугаенко. Что из этого получилось, слушайте в аудиоформате или смотрите в видео:
А под катом лежит полная расшифровка интервью со всеми ссылками.
Читать полностью »
Язык C++ очень часто обвиняют в неоправданной сложности. Конечно же, язык C++ сложен. И с каждым новым стандартом становится все сложнее. Парадокс, однако, состоит в том, что постоянно усложняясь, C++ последовательно и поступательно упрощает жизнь разработчикам. В том числе и обычным программистам, которые пишут код попроще, чем разработчики Boost-а или Folly. Чтобы не быть голословным, попробую показать это на небольшом примере «из недавнего»: как в результате адаптации к различным условиям тривиальный класс превратился в легкий хардкор с использованием policy-based design.
Читать полностью »
Привет, читатель. Поскольку, судя по всему, мы уже живем в будущем, то недавно я плотно засел за изучение новых фич ES6, ES7 и новых идей, предлагаемых React и Redux. И написал для своих коллег статью, в которой изложил сублимацию этих своих изысканий. Статья неожиданно получилась довольно объемной, и я решил опубликовать её. Заранее извиняюсь за некоторую непоследовательнсть изложения и отсылки к проприетарному коду из наших проектов — но думаю, что это всё же может помочь некоторым из вас лучше понять то, куда движется мир JavaScript и почему не стоит игнорировать происходящее в нём.
Я расскажу про свои мысли о компонентых моделях, классах, декораторах, миксинах, реактивности, чистой функциональности, иммутабельных структурах данных и ключевой идее React. Сразу скажу — я не являюсь пользователем React, и все изложенное это результат чтения его документации и технических статей, объясняющих его архитектуру. То есть, некоторое идеализированное преставление, которое безусловно лишь упрощенная модель того, как оно всё на самом деле обстоит.
В последнее время участились статьи и обсуждения на тему прощания с ООП и поиски смысла, который Алан Кэй изначально вкладывал в это понятие.
I made up the term “object-oriented”, and I can tell you I didn't have C++ in mind
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is “messaging”.
The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.
Late binding allows ideas learned late in project development to be reformulated into the project with exponentially less effort than traditional early binding systems (C, C++, Java, etc.)
I’m not against types, but I don’t know of any type systems that aren’t a complete pain, so I still like dynamic typing.
В связи с этими обсуждениями, часто всплывает мысль о том, что Erlang/Elixir очень хорошо удовлетворяют критериям, которые Кэй предъявлял к понятию «объектно-ориентированный». Но далеко не все знакомы с этими языками, поэтому возникает непонимание как функциональные языки могут быть более объектно-ориентированными, чем популярные C++, Java, C#.
В этой статье я хочу на простом примере с exercism.io показать как выглядит ООП на Elixir.
В конце концов, вы должны быть в состоянии:
Я в течение десятилетий программировал на объектно-ориентированных языках. Первым из них стал С++, затем был Smalltalk, и наконец .NET и Java. Я фанатично использовал преимущества наследования, инкапсуляции и полиморфизма, этих трёх столпов парадигмы объектно-ориентированного программирования. Мне очень хотелось воспользоваться обещанным повторным использованием и прикоснуться к мудрости, накопленной моими предшественниками в этой новой и захватывающей сфере. Меня волновала сама мысль о том, что я могу мапить объекты реального мира в классы и думал, что весь мир можно аккуратно разложить по местам.
Я не мог ошибаться сильнее.
Читать полностью »
Ты слышал про парня, который попрощался с OOП?
О нет. Ещё один? Что же он сказал?
Он описал все обещания OOП, и как ни одно из них на самом деле не было исполнено, и что все возможности ООП обходятся дороже, чем они реально стоят, и функциональное программирование лучше, и ...
Ох. Да, я слышал всё это раньше...
Таким образом, OOП окончательно умерло, и мы можем двигаться дальше.
Двигаться дальше к чему?
Ты чего? К следующему технологическому прорыву, конечно!
А, к этому… И что там у нас на очереди?
