ООП

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

Касс-помощник для работы с INI файлами. Класс расширяет возможности класса File. Класс реализует шаблон проектирования "Строитель". В представленном классе идет реализация функционала для работы с INI файлами. В качестве базового функционала представлено создание, добавление и чтение секций, добавление и удаление ключей и другой функционал.

Micro Property — библиотека для сериализации данных с минимальными накладными расходами. Она разработана для использования в микроконтроллерах и различных встраиваемых устройствах с ограничениями по размеру памяти, которым приходится работать по низкоскоростным линиям связи.

Конечно, я знаю про такие форматы как xml, json, bson, yaml, protobuf, Thrift, ASN.1. Даже нашел экзотический Tree, который сам является убийцей JSON, XML, YAML и иже с ними.

Так почему же они все не подошли? Зачем я был вынужден написать еще один сериализатор?

Уже после публикации статьи в комментариях дали несколько ссылок на пропущенные мной форматы CBOR, UBJSON и MessagePack. А они с большой долей вероятности решают мою задачу без написания велосипеда.
Жаль, что я не смог найти эти спецификации ранее, поэтому добавлю этот абзац для читателей и для собственного напоминания, что не следует торопиться писать код ;-).
Обзоры форматов на Хабре: CBOR, UBJSON

Привет, Хабр!

Продолжая исследование темы C#, мы перевели для вас следующую небольшую статью, касающуюся оригинального использования extension methods. Рекомендуем обратить особое внимание на последний раздел, касающийся интерфейсов, а также на профиль автора.

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

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

Инкапсуляция, полиморфизм, объектное мышление…?

Любите, когда вас грузят терминами? Я прочитал достаточно, но слова выше до сих пор не говорят мне ни о чем конкретном. Я привык объяснять вещи на понятном мне языке. Уровне абстракции, если хотите. И давно хотел знать ответ на простой вопрос: «Что даёт ООП?». Желательно с примерами кода. И сегодня я попробую ответить на него сам.

Мне показался близким подход Леона Старра к объяснению чётких моделей классов и описанию их преимуществ. Настолько, что мы в Retail Rocket решили сделать перевод его большой статьи "How To Build Articulated UML Class Models". Будем выкладывать по частям, под катом — первая из трёх.

Привет, Хабр! На этот раз я по пробовал сделать простенький чат через ВебСокеты. За подробностями добро пожаловать под кат.

Важно: для комфортного прочтения статьи нужно уметь читать исходный код на Rust и понимать, почему оборачивать всё в Rc<RefCell<...>> — плохо.

Введение

Rust не принято считать объектно-ориентированным языком: в нём нет наследования реализации; инкапсуляции на первый взгляд тоже нет; наконец, столь привычные ООП-адептам графы зависимостей мутабельных объектов здесь выглядят максимально уродливо (вы только посмотрите на все эти Rc<RefCell<...>> и Arc<Mutex<...>>!)

Правда, наследование реализации уже как несколько лет считают вредным, а гуру ООП говорят очень правильные вещи вроде "хороший объект — иммутабельный объект". Вот мне и стало интересно: насколько хорошо объектное мышление и Rust сочетаются друг с другом на самом деле?

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

Мою предыдущую статью «История IT. Когда компьютеры были большими…» мы завершили концом 80-х, когда произошло два знаменательных события. Во-первых, появился ООП и объектный язык C++. А во-вторых, появились персоналки, и это принципиально изменило задачи, стоящие перед IT-разработкой.

И дело тут не в том, что появилась возможность держать компьютеры дома, и выполнять на них рабочие задачи: редактировать тексты, вести расчеты, создавать рисунки. Софт для этого принципиально не отличается от аналогичного для больших компьютеров — его умели разрабатывать. Вопрос был лишь в оптимизации и адаптации под ограниченные ресурсы.

Главное изменение в том, что персоналки сделали компьютеры доступными небольшим компаниям. Потребовались системы автоматизации бизнес-процессов, которые сильно отличаются в разных компаниях. Типовую систему сделать сложно: сейчас такие системы уже есть, например, 1C, а в то время их не существовало. Как раз эту задачу помог решить ООП. Эту часть истории развития IT и концепций, которые тогда появились и до сих пор используются, я расскажу в этой статье.

Привет, Хабр! Мало написать хороший код. Нужно еще покрыть его хорошими Юнит Тестами. В прошлой статье я сделал простой веб сервер. Теперь попробую написать насколько тестов. Обычных, Property-based и с моками. За подробностями добро пожаловать под кат.

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

Дисклеймер

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


Материал основан на записях примерно 7-летней давности, когда мой путь в изучении ООП без IT-образования только начинался. В те времена основным языком был MATLAB, много позже я перешел на C#.

Изложение принципов ООП, которое я находил, с примерами в виде каких-то яблок, груш, унаследованных от класса «фрукты» и кучей терминологии (наследование, полиморфизм, инкапсуляция и т.п.), — воспринималось как китайская грамота.

Напротив, теперь же я почему-то воспринимаю подобный материал нормально, а изложение из своей же статьи временами кажется заморочным и длинным.

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

Насколько это соответствует действительности и вашим собственным предпочтениям, — решайте сами…

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

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

А наличие во фреймворке нужных паттернов никак не гарантирует их правильного и осознанного применения.

Пришло время уйти от OOP

OOP считается самым большим бриллиантом в короне компьютерной науки. Лучшим способом организации кода. Решением всех проблем. Единственно верным способом писать наши программы. Ниспосланным нам свыше самим богом программирования… Только вот OOP программист вынужден разгребать кучу всяких абстракций, следить за всеми совместно используемыми объектами, помнить тонны «паттернов программирования» — и на все это тратить свои время и силы вместо того, чтобы решать саму поставленную задачу.

1. Введение

Тот, кто научился летать, ползать уже не будет. Но не должно быть и высокомерия к тому, кто «летать не может» в принципе. И то и другое вполне норма. И то и другое уважаемо и почетно. Для человека — это, как выбор профессии: вы, условно, либо летчик, либо шофер. Для тех же животных аналогично — вы либо орел, либо волк, т.е. либо летаете, либо бегаете (убегаете). Но только человек в своих понятиях, категориях, отношении и мыслях наделил персонажи характеристиками и выработал свое отношение к ним. Правда, с нюансами. Так, нет, наверное, почетнее и романтичнее профессии летчика, но попробуйте в этом убедить дальнобойщика или авиаконструктора?! И тут сложно возразить: космонавтов много даже сейчас, а второго Королева все еще нет!

Мы — программисты. Может, в разной степени, но некоторые — уж точно. Это я к тому, что мы разные и мыслить можем тоже по-разному. Утверждение, что программист мыслит только последовательно, столь же однобоко, вредно и даже кощунственно, как и то, что человек только бегает. Он иногда — и летает. Кто-то, как летчики, делает это довольно регулярно, а некоторые, как космонавты, даже месяцами и непрерывно. Идея последовательного мышления принижает способности человека. В какой-то момент и на какое-то время в это можно даже поверить, но " все-таки она вертится" — это про то, что рано или поздно жизнь возьмет свое.

Когда я узнал об этих принципах, гибкость моего кода, по ощущениям, выросла х2, а скорость принятия решения по дизайну сущностей х5.

Если SOLID – это набор принципов написания качественного кода, то Law of Demeter (LoD) и Tell Don’t Ask (TDA) – это конкретные приемы как добиться SOLID.

Сегодня поговорим про Law of Demeter («Закон Деметры»).

Утрированно

Это принцип помогает определиться: «Как я буду получать / изменять вложенные объекты» – применим в языках, где можно определить «классы» со свойствами и методами.

Часто складывается ситуация, когда мы откуда-то (например, из HTTP запроса) получили id сущности `a`, пошли за ней в БД и из сущности `a` нам надо получить / изменить сущность `b` вызвав метод `Method`.

Так вот Википедия гласит:

Код `a.b.Method()` нарушает Закон Деметры, а код `a.Method()` является корректным.

Пример

У Пользователя есть Посты, в которых есть Комментарии. Вы хотите получить «Комментарии последнего Поста».

Можно запилить такое:

1. Введение

Чтобы максимально запутать проблему — поручите ее решение программистам ;). Но если серьезно, то на мой взгляд с корутинами происходит нечто подобное, т.к., вольно или нет, с их помощью происходит замыливание создавшейся ситуации. Последняя характеризуется тем, что по-прежнему остаются проблемы параллельного программирования, которые никуда не уходят, и, главное, корутины не способствуют кардинальному их решению.

Под динамическим определением объекта можно понимать определение во время исполнения. В отличие от статического определения, которое используется в привычном определении класса с помощью ключевого слова class, динамическое определение использует встроенный класс type.

Метакласс type

Класс type часто используется для получения типа объекта. Например так:

h = "hello"
type(h)
<class 'str'>

Но у него есть другое применение. Он может инициализировать новые типы.

Мы, PHP-разработчики, горды тем, что пишем на ООП-языке (можно легко здесь заменить PHP на C#, Java или другой ООП-язык). Каждая вакансия содержит требования про знание ООП. В каждом собеседовании спрашивают что-нибудь про SOLID или трех "китов" ООП. Но когда дело доходит до дела — мы получаем просто классы, наполненные процедурами. ООП проявляется редко, обычно в коде библиотек.

Обычное веб-приложение — это классы ORM-сущностей, которые содержат данные из строки в базе данных и контроллеры(или сервисы — неважно), содержащие процедуры работы с этими данными. Объектно-ориентированное программирование — оно про объекты, которые владеют собственными данными, а не предоставляют их для обработки другому коду. Отличная иллюстрация этого — вопрос, который был задан в одном чате: "Как я могу улучшить этот код?"

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

Это распространённая тема для холиваров. Например:

Не используйте ООП. Никогда. Это ошибка.

На эту тему есть много материалов, к примеру: www.youtube.com/watch?v=QM1iUe6IofM

Если ООП все еще кажется вам хорошей идеей, то решите простую задачку.

Есть три объекта: кошка, кормушка и человек. Вам необходимо написать метод, который бы позволял человеку покормить кошку, воспользовавшись кормушкой.

Вопрос: методом какого класса будет являться метод.покормить()?

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

Теперь сравните это с функциональной реализацией: у вас есть функция покормитьКошку() принимающая в качестве аргумента ссылку на кошку и кормушку.

Цитата из холивара

Как ответить на данный вопрос?