ООП *

Привет хабр!

На днях мне в очередной раз на глаза попал код вида

if(someParameter.Volatilities.IsEmpty())
{
    // We have to report about the broken channels, however we could not differ it from just not started cold system.
    // Therefore write this case into the logs and then in case of emergency IT Ops will able to gather the target line
    Log.Info("Channel {0} is broken or was not started yet", someParameter.Key)
}

В коде есть одна довольно важная особенность: получателю крайне хотелось бы знать, что произошло на самом деле. Ведь в одном случае у нас проблемы с работой системой, а в другом — мы просто прогреваемся. Однако модель не дает нам этого (в угоду отправителю, который зачастую является автором модели).
Более того, даже факт "возможно, что-то не так" происходит из того, что коллекция Volatilities пуста. Что в некоторых случаях может быть и корректно.

Я уверен, что большинство опытных разработчиков встречало в коде строки, в которых заключалось тайное знание в стиле "если выставлена эта комбинация флажков, то от нас просят сделать A, B и C" (хотя по самой модели этого не видно).

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

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

Однако если же вы занимаетесь долгоиграющим — добро пожаловать под кат.

Привет, Хабр! Представляю вашему вниманию статью "Four Better Rules for Software Design" автора David Bryant Copeland. David Bryant Copeland — архитектор ПО и технический директор Stitch Fix. Он ведет свой блог и является автором нескольких книг.

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

Правила Кента из книги Extreme Programming Explained:

• Кент говорит: "Запускайте все тесты".
• Не дублируйте логику. Старайтесь избегать скрытых дубликатов, таких как параллельные иерархии классов.
• Все намерения, важные для программиста, должны быть явно видны.
• Код должен иметь наименьшее возможное количество классов и методов.

Согласно моему опыту, эти правила не совсем соответствуют нуждам проектирования ПО.

Введение в ES6

Template literals (Template strings)

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

• TDD — ну, это все знают, сначала пишем тесты, а потом остальной код.
• BDD — что-то знакомое, вроде как, тоже тесты, но особенные.
• TDD — снова? Так, стоп, тут речь уже не о тестах совсем. Но почему называется так же?
• DDD — bound contexts, ubiquitous language, domain...
• FDD — да сколько можно?
• MDD — cерьезно, на основе диаграмм?
• PDD — ...

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

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

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

В этот раз я бы хотел немного поговорить о еще одном порождающем шаблоне проектирования из арсенала «Банды четырех» – «Строителе» («Builder»). Так вышло, что в ходе получения своего (пусть и не слишком обширного) опыта, я довольно часто видел, чтобы паттерн использовался в «Java»-коде вообще и в «Android»-приложениях в частности. В «iOS» же проектах, будь они написаны на «Swift» или «Objective-C», шаблон встречался мне довольно редко. Тем не менее, при всей своей простоте, в подходящих случаях он может оказаться довольно удобным и, как модно говорить, мощным.

Welcome! Я, как junior full stack разработчик, при попытке написать бота с использованием laravel и botman’а столкнулся с многими проблемами. Во-первых, я плохо знаю английский, а на русском статей очень мало на эту тему, а те, что есть не помогли мне решить мои проблемы. В статье будет рассказано и показано, как разработать чат-бота на laravel+botman для telegram. Сам я разрабатывал ботов(коммерческих) под viber и telegram. Как разработчику telegram мне нравится больше всего.

Я не буду показывать как установить laravel и настроить сервер для его работы. Если вы никогда этого не делали, то проще будет установить openserver, в него встроен composer(пакетный менеджер для php) и уже настроен локальный сервер для laravel’a. Вам останется лишь прописать немного кода в .htaccess. Дома я именно так и работаю. В статье покажу один из способов разработки чат-бота, настроим бота для работы в телеграм, а так же, в конце, оставлю ссылки на полезные статьи о laravel’e и botman’e.

Проектирование/подготовка

Разработку бота предлагаю, как и все нормальные разработчики, начать с проектирования, постановки задачи и объяснения как работает laravel. Перед этим скажу, что я пишу код в phpStrom. Можно писать в любом другом IDE, но я пользуюсь именно им.

В laravel реализован паттерн MVC(Model View Controller). Это не значит, что нужно писать только под mvc, можно и говнокодить, но лучше пользоваться теми преимуществами, которые предоставляет фреймворк. Если вы знакомы с mvc, но не применяли его, как я, то разработка с помощью laravel’a это лучший способ закрепить знания.

Привет, Хабр! Представляю вашему вниманию перевод статьи “Object-Oriented Programming in Python vs Java” автора Джона Финчера.

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

Подробнее – под катом.

Люди продолжают утверждать, что современные объектно-ориентированные языки, на самом деле "не совсем объектно-ориентированные", поскольку они не соответствуют определению ООП Алана Кэя. На мой взгляд, в этом есть смысл, хотя я и не согласен с выводом. В последнее время мне встречаются люди, которые говорят о том, что именно Кэй изобрёл объекты. Фактически это неверно.

Алан Кэй не изобретал объекты. Они были в Simula, которую приводит в качестве основного источника вдохновения руководство к Smalltalk-72 (с. 117). В выпуске известного журнала Byte за 1981 год, который популяризировал Smalltalk и ООП, говорится, что "основная идея объектов, сообщений и классов пришла из SIMULA". В нем сказано, что Simula позволяет пользователям создавать "объектно-ориентированные системы", что, возможно, слишком, но тем не менее. Команда Smalltalk хорошо знала систему объектов в Simula и черпала вдохновение из неё.

Одной из причин, почему такой миф всё ещё жив, послужило то, что сказал сам Кэй в 1998 году:

Просто напоминаю, что на последней OOPSLA я постарался донести до всех, что Smalltalk — это не только НЕ синтаксис или библиотека классов, но даже не классы. Мне очень жаль, что ранее я ввел термин "объекты" для этой темы, поскольку это заставляет многих людей сосредоточиться на меньшей идее.

• Типизированные свойства классов
• Предзагрузка для улучшения производительности
• Стрелочные функции для короткой записи анонимных функций
• Присваивающий оператор объединения с null (??=)
• Ковариантность/контравариантность в сигнатурах унаследованных методов
• Интерфейс внешних функций, открывающий новые возможности для разработки расширений на PHP
• Оператор распаковки в массивах

R — это объектно ориентированный язык. В нём абсолютно всё является объектом, начиная от функций и заканчивая таблицами.

В свою очередь, каждый объект в R относится к какому-либо классу. На самом деле, в окружающем нас мире ситуация примерно такая же. Мы окружены объектами, и каждый объект можно отнести к классу. От класса зависит набор свойств и действий, которые с этим объектом можно произвести.

В первой части я попытался показать, что черная кошка ООП в темной комнате графических языков существует, даже если это не кошка, а полудохлый кот живодера Шредингера, который то есть, то его нет. Был показан пример реализации методологии объектно-ориентированного программирования, когда программа – это не код на языке С++ или Java, а диаграмма Simulink, SimInTech, SimulationX или SCADE Esterel, — любая графическая нотация описания алгоритма.

В рекламных материалах Мatlab Simulink часто используют термин МОП — Модельно Ориентированное Проектирование (Model-based design). Во многих текстах они подчёркивают, что графическая схема алгоритма это модель, что, конечно, верно. Однако в первоначальном определении МОП, модель – это прежде всего модель объекта, к которому разрабатывают систему управления, включая управляющее программное обеспечение. Подробнее методолгия МОП описана здесь. Таким образом, разрабатывая систему управления по методологии МОП можно и нужно использовать методологию ООП для разработки управляющего ПО. И что бы окончательно закрыть вопрос с моделями, вот вам картинка с отличиями одного от другого. Если все понятно, то можно дальше не читать.

Single responsibility principle, он же принцип единой ответственности,
он же принцип единой изменчивости — крайне скользкий для понимания парень и столь нервозный вопрос на собеседовании программиста.

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

В лесу нас разделили на группы по 8-9 человек в каждой и устроили соревнование — какая группа быстрее выпьет бутылку водки при условии, что первый человек из группы наливает водку в стакан, второй выпивает, а третий закусывает. Выполнивший свою операцию юнит встает в конец очереди группы.

Случай, когда размер очереди был кратен трем, и являлся хорошей реализацией SRP.