ООП *

Допустим, у нас есть набор объектов с некими данными, и нам нужно произвести манипуляции с этими объектами.

Положим, самый обычный пример - наполнить корзинку фруктами. Мы реализуем некий класс Сart, в который будем складывать фрукты. Далее нам понадобиться базовый класс Fruit, для того, чтоб определить параметр объема, которому мы будем присваивать значение в зависимости от фрукта.

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

И вот тут начинается проблема. Да, наш класс стал более универсальным, но увеличиваться может не только количество проблем с фруктами, но и сами ситуации сбора фруктов могут быть различными. Например, мы собираем фрукты там, где абсолютно каждый плод будет свежим. Зачем, в таком случае, нам поле, отвечающее за свежесть, если все фрукты заведомо свежие? Мы выносим ряд опциональных типов в массив(словарь), где каждый тип не является непосредственной частью класса.

Однако, я решил пойти дальше, и немного развить эту тему.

Опрос на telegram-канале Cross Join "Можно ли наследовать класс Пингвин от класса Птица?" удивил. Большая часть людей ответили вполне определённо "да" или "нет" (результаты опроса приложены в конце статьи). Не ожидал такого расклада, поэтому решил написать короткую заметку.

На самом деле, если вам зададут такой вопрос на собеседовании, знайте: тут есть подвох. Даже два.

Очень круто - запрограммировать механизм или программный модуль, заставив его выполнять твою волю. С похожими мыслями в конце 2018 я размышлял о том, что хочу свой WoW-сервер, который будет полностью мной управляем. Поизучав С++ исходники MANGOS, я пришел к выводу, что не смогу вот так взять и реализовать все свои идеи, не понимая, как же работает MMO RPG сервер от начала и до конца. И для этой цели я решил реализовать свой движок. С нуля.

Пришло время посмотреть на тип модели классов UML, который можно встретить во множестве проектов. А ещё, увы, который часто поощряется в книгах по UML.

Итак, собственно проблема: порой у нас в проекте есть много похожих компонентов, с одинаковой логикой, одинаковыми DI, свойствами итд и возникает мысль: а почему бы не вынести все это дело в базовый компонент (точнее директиву) абстрактным классом, а остальные компоненты уже наследовать? На самом деле мысль хорошая, принцип DRY соблюдается, имеем один источник истины, при изменении той самой общей логики не придется прыгать по всем компонентам итд.

Но есть один нюанс: эти злосчастные конструкторы. Нужно в каждом наследуемом компоненте передавать все DI в конструктор родителя.

Предпосылки / проблема

При работе над своим проектом вручную создавал стилизованную галерею проектов и понял, что бесконечно плодить громоздкие однотипные HTML-контейнеры – это очень сложный и долгий путь. Захотелось данную задачу автоматизировать и решить более элегантно через JS, описывая каждую картинку как объект на основе класса. Это вторая статья на эту тему, здесь я постарался исправить некоторые ошибки и поработал над логикой и структурой кода. Для удобства добавил возможность просмотра галереи и полного кода в песочнице.

Плюсы такого подхода:

* Более читабельно, чем гора HTML-контейнеров и их содержимого

* Написание одного шаблона впоследствии сэкономит кучу строчек кода и времени

* Короче и удобнее

В этой статье мы говорим о переменных и связанных с ними темами!

Научимся создавать переменные и константы.
Узнаем что такое инициализация переменных.
Поговорим о литералах.
Выполним преобразование и приведение типов данных

Предпосылки / проблема

При работе над своим проектом вручную создавал стилизованную галерею проектов и понял, что бесконечно плодить громоздкие однотипные HTML-контейнеры – это очень сложный и долгий путь. Захотелось данную задачу автоматизировать и решить более элегантно через JS, описывая каждую картинку как объект на основе класса.

Плюсы такого подхода:

* Более читабельно, чем гора HTML-контейнеров и их содержимого

* Написание одного шаблона впоследствии сэкономит кучу строчек кода и времени

* Короче и удобнее

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

Обо всем этом вы узнаете в этой статье про типы данных в Java!

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

Запускаю серию обучающих статей по Java Core c картинками, без смс и регистрации!

В этой статье мы быстро пройдемся по истории языка Java и его особенностях.
Установим JDK и подготовим ваш камплюктер для работы с ним.
Конечно же поговорим об IDE и установим IntelliJ IDEA.
Создадим, запустим и разберем первую Java-программу.

Уверен, понятно будет даже самым маленьким!

Осторожно-оптимистические размышления о месте современной производственной культуры в сопровождении унаследованного из древних времён программного обеспечения. И немного о взаимопроникновении принципов SOLID.

Как то мы уже обращались к теме превосходства объектного/типизированного представления в реализации моделей предметной области в сравнении с SQL. И верность тех доводов и фактов на на йоту не уменьшилась. Казалось бы, зачем отступать и обсуждать технологии, которые глобально низвергают абстракции обратно в дообъектную и дотипизированную эпоху? Зачем провоцировать рост спагетти-кода, непроверяемых ошибок и упование на виртуозное мастерство разработчика?

Есть несколько соображений о том, почему стоит поговорить про обмен данными через API на основе SQL/REST/GraphQL, в противовес представлению их в виде типов/объектов:

NullPointerException - одна из самых раздражающих вещей в Java мире, которую был призван решить Optional. Нельзя сказать, что проблема полностью ушла, но мы сделали большие шаги. Множество популярных библиотек и фреймворков внедрили Optional в свою экосистему. Например, JPA Specification возвращает Optional вместо null.

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

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

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

Введение

Предположим, у нас есть набор инструментов(сущностей) для обработки какого-то потока данных, или построения других комплексных сущностей.

На примере транспортных средств.

Есть у нас набор атомарных компонентов:

class EngineA;

class EngineB;

class wheelsA;

class wheelsB;

class FrameA;

class FrameB;

и т.д.

Если нам нужна машина - мы просто объявляем класс Car, в котором есть нужный корпус, колеса, двигатель и т.д. Аналогично с какой-нибудь лодкой лодкой, мы бы объявили класс Boat, и быстренько набросали агрегацию нужных частей лодки. Если же нам нужна и лодка, и машина, и даже самолет - мы можем без проблем воспользоваться паттерном фабрика, но что делать, если нам нужны машины, лодки, самолеты, и мы заранее не знаем сколько, когда, и в каком порядке.

В данной статье мы коротко пройдемся по теории и на практике разберемся как перевести любое Legacy приложение на гексагональную архитектуру. Повествование будет в контексте фреймворка Symfony и PHP 7.4, но синтаксис приведенных примеров настолько прост что вы без труда поймете как сделать так же на вашем языке программирования (если он поддерживает ООП).

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

Как составить список востребованных профессий в IT, ориентируясь не только на виденье отдельных людей, но и на цифры? Конечно провести свое собственное исследование! Это мы и попытались сделать, скачав более 77 тысяч айти вакансий за последний месяц и обработав их.

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

В следующий раз я расскажу о зарплатах: медианных, вилках и примерному распределению по России.

Я уже довольно давно хотел написать пост о работе с виртуальной памятью. И когда @jimsagevid в ответ на мой твит написал о ней, я понял, что время пришло.

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

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