ООП *

Первое мое знакомство с Mobx началось с удивления. Я не понимал всю магию библиотеки и задавал себе вопрос: “А как это возможно?”. Кажется, в ней используются какие-то подкапотные возможности JS или Mobx вообще написан на другом языке. 

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

В этой статье мы создадим свой Mobx с нуля, а так же свяжем его с React, через собственно написанный HOC observer. В конце у вас будет общее понимание реактивности, которое поможет в самостоятельном осмыслении не только Mobx, но и других реактивных библиотек и фреймворков.

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

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

На мой взгляд, неплохим выходом из ситуации служит использование объектно-ориентированного подхода, а именно написание некого класса "обвязки" с более простыми методами, инкапсулирующими в себе сложную логику обращения к оригинальной библиотеке.

Вы задумывались, что такое объект? Что-то из реального мира: человек, машина, здание? Почему?

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

Хочу поделиться своим ООзарением с вами.

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

В статье присутствуют материалы, о которых обучающимся программированию рассказывают в самом начале. Когда я преподавал в GeekBrains, первый месяц курса по PHP был посвящен синтаксису, а вот второй как раз тем темам, о которых я буду говорить здесь. К сожалению, не помню, когда мне их преподавали в институте во время моего обучения на программиста, но, наверное, тоже где-то на первых курсах. 

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

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

Программировать нужно осознанно.

MediatR - это очень популярная библиотека, которая используется для уменьшения зависимостей между объектами. Она популяризует архитектуру, основанную на крайне значимых принципах проектирования:

• препятствование прямому общению между объектами для уменьшения связности;

• нацеливание на Message-Oriented архитектуру;

• поддержка асинхронного внутреннего обмена сообщениями;

• ориентирование на переиспользование объектов.

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

Существует множество статей о MediatR, но лишь их малая часть фокусируется на недостатках и помогает определить случаи, когда использование инструмента не имеет смысла. Этот пост один из таких.

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

Также стоит отметить, что эта статья не покрывает положительные аспекты библиотеки, а фокусируется только на недостатках.

Это история о том, как потерпеть фиаско, имея хорошо написанный и протестированный в боевых условиях работающий код и даже написанную документацию. Изначально я собирался делать анонс своей библиотеки, но что-то пошло не так. Поэтому начнём за здравие -- постановка и формализация задачи, описание возможностей и батареек. А закончим за упокой -- вопросами, как всё это теперь тестировать?

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

Количество классов в реализации даже небольшой программы на один человеко-месяц исчисляется десятками. В средних программах на несколько человеко-лет счёт идёт уже на тысячи. А человек может одновременно оперировать 7-ю +/- 2 объектами. Поэтому все нетривиальные программы требуют декомпозиции своей реализации на более крупные блоки, чем классы - я буду называть такие блоки пакетами.

Сейчас наиболее распространены два основных подхода к декомпозиции систем: пакетирование по слоям и техническим аспектам (далее просто "по слоям" для краткости) и пакетирование на основе предметной области (представленное группой вариантов: пакетирование по фичам, пакетирование по компонентам, ограниченные контексты и пакетирование по агрегатам из предметно-ориентированного дизайна (DDD))

Однако ни один из этих подходов мне не подошёл в полной мере и я изобрёл…​ объектно-ориентированный подход к декомпозиции систем. Точнее, я изобрёл простую методику выполнения декомпозиции, а потом понял, что на выходе она даёт штуки обладающие свойствами объекта.

Но обо всём по порядку - сначала я рассмотрю критерии оценки подходов, распространённые подходы и почему они мне не подошли. А закончу пост представлением методики выполнения объектно-ориентированной декомпозиции.

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

Разберём, что такое приватные конструкторы, зачем они нужны и попробуем создать полифил.

Здесь можно найти ответы (в виде описания терминов) на вопросы в этой статье, к вакансии Unity мидл программист. Или попросту узнать что-нибудь новенькое. Статья будет постепенно дополнятся (возможно простейшими примерами).

Во многих источниках тип double и float, числа с плавающей запятой/точкой зачем-то называют вещественными. Такое чувство что кто-то когда-то совершил ошибку или не внимательно написал эту глупость и все как один начали её повторять, совершенно не задумываясь о чём они говорят.

Ладно это были бы просто троечники студенты и любители, так эту ошибку говорят и те, кто обучают специалистов. И эта проблема терминологии не одного ЯП, их правда много (Java, C++, C#, Python, JS и т.д.) везде, где бы я не искал, всегда находятся статьи, ответы, лекции, где дробные числа называют вещественными!

Sanic - современный мощный фреймворк, незаслуженно обделённый вниманием российского IT-сообщества.

Здесь изложен необходимый минимум информацию, которую нужно изучить, если хочешь приступить к использованию проекта Lombok. Рассмотрим, как интегрировать его в вашу IDE и использовать, чтобы сократить объем шаблонного кода.  

Java – отличный язык, только многословный. Возможно, вам придется писать много кода, чтобы достичь даже самых простых целей. Кроме того, в Java определенно присутствует повторяющийся код, например, геттеры и сеттеры. Поэтому у вас получаются огромные объемы повторяющегося и необязательного кода. Мало того, что такой код не добавляет ничего нового в бизнес-логику вашего приложения, так и писать его долго и скучно. Именно поэтому следует переходить к использованию библиотек и инструментов – они помогают повысить продуктивность и избежать этой рутины. Именно здесь в игру вступает Lombok!

Это библиотека Java, в которой предоставляется ряд аннотаций, направленных на исключение именно того кода Java, о котором известно, что он часто становится повторяющимся и/или шаблонным. Проект Lombok включается прямо в процесс сборки. Затем Lombok автоматически сгенерирует для Java байт-код, который вставляет в файлы .class, необходимые для реализации желаемого поведения, в зависимости от используемых вами аннотаций. Следовательно, каждая аннотация, предлагаемая в проекте Lombok, позволяет частично обойтись без написания методов и логики, без которых вы хотели бы обойтись. Речь о конструкторах, равенствах и функциях хеш-кода. Так вы сможете сэкономить массу времени и сосредоточиться на бизнес-логике вашего проекта. Кроме того, вы сможете держать базу кода сравнительно компактной, чистой, удобной для чтения и поддержки.

Добрый день, уважаемый читатель Хабра! Меня зовут Вартанян Артур и я работаю в компании Reksoft Java-разработчиком. В данной статье мы напишем свой собственный вариант реализации валидации для объектов и его полей, используя Java Reflection Api и Spring AOP.