В предыдущей части рассматривалась новая система счисления, в обосновании которой использовались некоторые соотношения алгебры кортежей.
Об алгебре кортежей (АК) и ее использовании для логико-семантического анализа было рассказано в моей статье в Хабре. В комментариях к статье предлагалось обратить внимание на функцию SELECT в языке SQL, которая соответствует операции Selection (Выборка) в реляционной алгебре. Эта операцию можно рассматривать как один из вариантов математической модели вопроса.
Преуведомление
Вся нотация, используемая в этой статье, не является общепринятой для представления математических выражений. Возможно, вы ранее изучали эту тему либо продолжаете изучать, поэтому заранее прошу прощения, если допустил какие-либо фактические ошибки или некорректно использовал термины.
Выпуск Java 21 состоялся 19 сентября 2023 года. В этой версии поддерживаются паттерны записи в switch-блоках и выражениях. Такой синтаксис выглядит монументально (как минимум, по меркам Java). Это водораздел, после которого мы вправе говорить, что в Java полноценно поддерживаются паттерны функционального программирования, подобно тому, как это сделано в Kotlin, Rust или C#. Вот и первый пункт, который пробуждает во мне зависть (я – Kotlin-разработчик).
Если просто добавить к определению бина аннотацию @Scope(SCOPE_PROTOTYPE), и использовать этот бин в синглтоне через аннотацию @Autowired – будет создан только один объект. Потому что синглтон создается только однажды, и обращение к прототипу случится тоже однажды при его создании (при внедрении зависимости).
На самом деле вариантов довольно много:
Привет, Habr!
Я конечно не Джеймс Гослинг, но за долгое время работы с Java у меня накопилась масса мыслей.
Мысли по написанию кода, о подводных камнях типа Null safety, советы для любителей усложнять, байки бывалого погромиста про 0-day в Spring, экзистенциальные переживания при работе с мегабайтами легаси, очевидные советы, которые так сложно даются сеньорам — и ещё масса полезных размышлений в связке с примерами кода.
Абстрактный тип данных.
Зачем нужны абстрактные типы данных? Чем они полезны для программиста? Когда необходимо создавать эти абстракции, а когда можно обойтись без них? Тип данных vs абстрактный тип данных vs структура данных.
Очень часто кто-то где-нибудь на каком-нибудь форуме жалуется на нехватку инкапсуляции и изоляции в языке программирования C. Это происходит с такой регулярностью, что я намерен раз и навсегда разрушить этот миф. Благодаря этому когда в следующий раз кто-то будет делать подобные заявления, я смогу просто дать ссылку на эту страницу, а не писать объяснение заново.
Нужно сказать, что C – это старый язык, в котором не хватает множества современных возможностей. Но чего в нём хватает, так это инкапсуляции и изоляции.
Здравствуйте, всем! Хотя это моя первая публикация на Хабре, тему я хочу затронуть важную и далеко не всегда понятную новичкам. Не обращайте внимание на странный заголовок. Считайте, что это – ружье на стене, которое по ходу пьесы обязательно выстрелит.
Материал по этой теме здесь уже имеется, но на мой взгляд, информация там подана не совсем удачно и полно. Рискну внести свою лепту в дело понимания и запоминания такого фундаментального принципа.
В данной статье я постараюсь по максимуму избежать кода. Сделано это в целях повышения универсальности материала, он должен быть интересен всем читателям независимо от их языка программирования. В тех местах, где код неизбежно понадобится, он будет оформлен в синтаксисе Java. Не пугайтесь, все объясню, сложно не будет (во всяком случае, по моим расчетам). Итак, поехали!
Мне давно хотелось узнать существуют ли программисты, которые понимают «делегирование» в рамках ООП так же, как я. А когда я случайно обнаружил что в Шаблонах проектирования (Design Patterns) в фундаментальных трудах признанных классиков концепций программирования пропущено описание для Делегирования, у меня появился повод написать эту статью.
Так получилось, что я сначала познакомился с этой техникой на практике разрабатывая DirectShow фильтры и COM-объекты, которые составляют эти фильтры и меня особо не интересовало как все это по-умному называется пока это все прекрасно работает. Проблемы возникают, когда ты пытаешься объяснить кому-то КАК это работает, или когда ты пытаешься предложить кому-то хотя бы попробовать использовать определенную технику программирования. Вот именно при таких попытках у меня получилось сопоставить что то, что я использую очень подходит под определение Design Pattern: Delegation.
Давайте посмотрим будет это поводом посмеяться или задуматься.
Должен предупредить что тем, кто воспринимает чужое мнение по техническим вопросам как оскорбление только потому, что он не согласен с этим мнением, не нужно читать эту статью.
Кто дочитает до конца найдет ответ на вопрос который задает название.
В этой статье мы посмотрим на моем примере как создать игру в 3D иллюзией с помощью технологии RayCasting на связке Python + PyGame. Только тригонометрия и вычисления, никак движков.
Все мы помним старые игры, в которых впервые появилось трехмерное измерение. Но сейчас эта графика кажется очень устаревшей. Потому что в современных играх графика настолько близка с реальностью что порой тяжело понять что это вообще графика. В наше существует куча приемов чтобы сделать графику такой реалистичной.
Сейчас нам все это позволяют сделать видеокарты, но раньше мощностей не хватало чтоб даже приблизиться к такой графике. Поэтому прибегали к более простым методам, не требующих большого количества вычислений.
Основоположником 3д игр стала игра Wolfenstein 3D, выпущенная в 1992 году а за ней и Doom 1993 года. На самом деле здесь используется технология RayCasting, третьего измерения тут просто не существует.
В программировании есть несколько основных парадигм — подходов, которые определяют, как программисты структурируют и организуют свой код
Одним из наиболее популярных подходов сейчас является объектно-ориентированное программирование, ООП, где код организуется вокруг объектов и классов. Объектно-ориентированный подход поддерживается многими языками программирования и начинающим разработчикам стоит детальнее разобраться с тем, что же на практике означают страшные слова «полиморфизм», «инкапсуляция» и другие термины, применяемые в этой парадигме.
В этой статье я расскажу о ключевых понятиях, связанных с ООП, и на примере Python-кода разберу, как одна и та же задача может быть успешно решена с использованием процедурного и объектного подхода. Но обо всём по порядку; начнём, традиционно, с основ, а поможет мне в этом выдуманный хоккеист Степан.
Разберу простую задачу, получение rss-ленты, и то, чем будет отличаться код, который просто получает ленту, от того, который собственно используется в производстве.
Надеюсь материал будет полезен начинающим программистам и покажет, как примерно должна осуществляться разработка с прицелом на получение результата применимого в проектах.
Привет, Хабр!
Меня зовут Дмитрий Мулло, я сотрудник Группы «Иннотех».
В этой статье на несложных примерах рассматриваются понятия объектно‑ориентированного программирования, такие как «класс» и «объект», помогающие структурировать код приложения.
Принципы проектирования SOLID были представлены Робертом Мартином в его книге “Design Principles and Design Patterns” в 2000 году. Эти принципы помогают нам создавать более гибкое программное обеспечение, которое легко понимать и обслуживать.
В этой статье мы обсудим “Принцип подстановки Барбары Лискофф”, который соответствует букве L в акрониме SOLID.
ООП используется уже давно, оно применяется в большинстве программ. Но всегда ли ООП является правильным путём? Далеко нет.
Что такое ООП?
ООП — это парадигма, при которой код разделён на множество классов, что приводит к настраиваемому доступу и разъединению компонентов. Основные преимущества использования ООП заключаются в следующем:
1. Сокрытие подробностей реализации
Благодаря использованию слоёв абстракций мы можем обеспечить приватность работы внутреннего устройства ПО. Абстрагирование помогает с безопасностью и удобством использования, так как другие разработчики не знают (и не должны знать) внутреннюю реализацию вашего ПО.
2. Разъединённые компоненты
Классы и интерфейсы — это удобный способ превращения конкретных частей кода в единый модуль. Другие части кода могут получать доступ только к тому, что им разрешено.
К написанию статьи меня подтолкнул вот такой вопрос:
Всем добрый день. Хотел бы получить краткие и понятные для новичка ответы на следующие вопросы:
Что такое COM объект?
Как происходит разработка COM объекта?
Какие особенности реализации COM Microsoft?
Прошу воздержаться от скидывания многостраничной литературы. Спасибо.
Ниже предлагаю свой развернутый ответ, который, почему-то, неизменно возбуждает вопрос из нового заголовка статьи. Интересно было получить оценку сообщества профессионалов. Надеюсь и новички смогут найти что то полезное.
Заявление звучит довольно громко и, я бы даже сказал, провокационно. Но в последние годы я всё больше и больше считаю, что это утверждение действительно верно, и хочу подробно объяснить, почему.
Этой весной в чатах и сообществах dotnet (не забываем #DropTheDot) обострились анти-медиаторные настроения. Поначалу меня это забавляло, потом удивляло: люди подхватывают лозунги, не пытаясь разобраться в вопросе. Квинтэссенцией обострения стал доклад Андрея Парамонова "MediatR не нужен”, шокирующий своей категоричностью аргументов. В докладе были зерна истины, но они к концу так и не проросли.
Желание прорастить эти зерна и мой крайне положительный опыт использования медиатора в проектах разного размера смотивировали меня написать данную статью. Статья основана на личном опыте и наполнена эмоциями, за это заранее извиняюсь 🤭 Она будет интересна скорее людям, которые уже знакомы с медиатором, встречались с ним в теории или на практике.
Всем привет! В данной статье рассмотрим паттерн проектирования Composite («Компоновщик»).
Начнем немного с теории.
Паттерн Composite, исходя уже с самого названия, позволяет скомпоновать объекты в структуры по типу «дерева», для предоставления иерархии от частного к целому, а также позволяя клиентам единообразно трактовать отдельные и составные объекты этого дерева. Данный паттерн используется для группировки мелких компонентов в более крупные, которые в свою очередь, могут стать основой для еще более крупных структур.
Я устроился в небольшую компанию, которая сделал круд‑приложуху на 20 таблиц типа «заметки» и активно ее продавала госорганам за невменяемый бабос.
У нас был 3(три) Т‑Р-И статуса юзера. Anonym → Logined → Phone_Confirmed. Молодой талант до меня увидел в этом граф, и написал класс на 200+ строк, реализующий алгоритм Флойда‑Уоршелла, прикрутил стейт‑машину и не найдя интересных задач, c блеском прошел собес в Яндекс и свалил.
Меня наняли сеньором, и я каюсь ничерта не понял, алгоритм прекрасно работал на первой ступени, на второй давал сбои, тоскливо погуглил этот алгоритм, стер все к черту и написал: if(status==Logined & phone!=null){status=Phone_Confirmed}.
Один коллега посмотрел на меня с немой благодарностью, а начальник офигел и сказал, что код нерасширяем и захардкожен, а тот алгоритм мог пройти за время логN через тысячу вершин и по истечению испытательного урока меня уволили нах, так как мой технический уровень не соответствовал их высоким требованиям, впрочем выдали три зарплаты и я благодарен этим людям. Мой код оставили, тот так и не смогли починить.
Это было вступление.
Уважаемый Яндекс, Сбер и прочая! Я умею быстро решать задачи и кратно увеличивать выхлоп простыми решениями. Я самый умный программист, среди всех ваших работников! Я — НадНадсеньор! Сейчас докажу.
Потому что, только я могу решить задачку, которую вы уже 10 лет решить не можете, когда прилетает пуш‑уведомление или смс и в твоем всплывающем окне написано:
«Ваш шестизначный пароль доступа в наше приложение: 123...»
