ООП *

Изучите ключевые концепции программирования, лежащие в основе популярной JavaScript-библиотеки MobX. Понимание этих концепций поможет вам применить лучшие практики программирования в работе.

Привет, Хабр! Это первая часть обзора по изучению существенных тем Java стека и туториала по их применению. В этой статье вы найдете важные аспекты многопоточности в Java, а также полезные шпаргалки с практическими примерами.

Меня зовут Влад, я Java-разработчик в компании SimbirSoft. Надеюсь, что моя статья будет полезна как начинающим, так и продвинутым Java-специалистам, которые заинтересованы в прокачке своих знаний для успешной подготовки к собеседованиям на боевые проекты.

Изучите ключевые концепции программирования, лежащие в основе популярной JavaScript-библиотеки React. Понимание этих концепций поможет вам применить лучшие практики программирования в работе.

В первой части, через боль и страдания, мы написала ядро – основную логику макроса.
Сегодня поработаем над пользовательским интерфейсом.

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

В общем вас ждет теория, ещё теория, словесные примеры и даже примеры кода (он на С++, но написан понятно).

А еще это полезно знать на собесах :-)

Наверное, пару лет назад, я бы отдал многое за подобную статью. Тогда, я рыл интернет в поисках информации о структурировании VBA проекта, но толком ничего не находил.

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

Чтиво про рефакторинг VBA кода.

Unit of work или "единица работы" - Поведенческий паттерн, который позволяет определить логическую транзакцию. Эта транзакция нужна, для объединения нескольких "маленьких" операций в одну "большую"(Acid).

В данной статье, я рассказываю о том, как написал свой первый эзотерический язык программирования C42.

В рамках наших Java курсов "Из Middle в Senior" (предыдущие посты Миграция Java Spring Boot на Kotlin и «Работа с документами в Java») недавно вышел новый курс Startup: Spring Boot веб-приложение с хостингом и инфраструктурой на основе эволюции нашей платформы онлайн-обучения с 2016г.

В рамках курса есть много подходов, сокращающих количество кода/усилий разработчиков. Один из них: сквозная параметризация от сервисов до репозиториев, позволяющая сокращать количество кода ~3х. Код приведен на Java, но общий подход может быть использован в любом языке с параметризацией. Кому интересно:

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

SupperMapping - это класс Python, который предоставляет удобный интерфейс для работы со словарями с возможностью обратного отображения.

Сопоставление шаблонов (pattern matching) и исчерпывающие переключатели (exhaustive switches) объединяются для создания функциональных моделей данных, которые легко сочетаются с объектно-ориентированным ядром Dart. 💪

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

Руслан Гнатовский aka @Number55 в свой статье Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя описал известную проблему протекания бизнес-логики из агрегата, в случае если эта логика зависит от данных которые находятся вне агрегата, и предложил несколько решений этой проблемы, каждое из которых не лишено недостатков. Многие из этих недостатков были описаны в статье а также в комментариях поэтому я не буду здесь дублировать эту информацию а попытаюсь предложить решение которое этих недостатков лишено.

Не секрет, что при формировании новой команды руководители (Team Leader, Tech Leader) сталкиваются с проблемой формирования единого стиля написания программ, так как все члены команды новые, и у каждого из них свой подход к организации кода и выбору используемой практики. Как правило, в большинстве случаев это приводит к длинным диспутам на ревью, которые в итоге перетекают в различные толкования известных практик, таких как SOLID, KISS, DRY, и т.д. Принципы использования этих практик довольно размыты и, при должном упорстве, легко найти парадокс, когда одна из них противоречит другой. Например, рассмотрим Single Responsibility и DRY.

Одна из вариаций определения принципа единой ответственности (Single Responsibility - буква S из аббревиатуры SOLID) гласит, что каждый объект должен иметь одну ответственность, и эта ответственность должна быть полностью инкапсулирована в класс. Принцип DRY (Don’t repeat yourself) предлагает избегать дублирования в коде. Однако, если у нас в коде есть один набор данных (DTO), который может использоваться в разных слоях/сервисах/модулях, какому из этих принципов нам следовать? Безусловно, во многих книгах по программированию разбираются похожие ситуации, как правило, в них говорится, что если речь идет о разных объектах/функциях с одинаковым набором свойств и логики, но принадлежащим разным доменным областям, то дублированием это не является. Но как доказать что эти объекты ДОЛЖНЫ принадлежать разным доменным областям, и, главное, готов (и уверен ли в своих силах) руководитель доказывать это утверждение?

Собственно говоря, зачем эта статья и для кого? Для тех, кто только начинают свой путь в изучении Java. В этой статье я не буду сильно углубляться в детали каждой коллекции в отдельности, ведь чтобы начать ими пользоваться достаточно хотя бы на базовом уровне понять, что это такое и с чем это «едят».

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