ООП *

В этой статье мы посмотрим на моем примере как создать игру в 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...»

В Dart 3.0.0 появилось много новых вещей. Об одной из таких – модификаторы классов – мы сегодня и поговорим.

Спойлер: 5 новых модификаторов + их комбинации: Base, Interface, Final, Sealed и Mixin.

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

Один из сценариев, в котором нам нужна проверка значений — это инициализация экземпляра класса. На первом этапе мы хотим убедиться в правильности вводимых атрибутов, например, адрес электронной почты должен иметь правильный формат xxx@xx.com, возраст не должен быть отрицательным, фамилия не должна превышать 20 символов и т.д.

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

И снова всем привет! Судя по реакциям и количеству закладок к переводу первой части книги Patterns.dev, этот материал оказался для вас полезен. Поэтому я решил поделиться переводом второй части.

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

Напомню, что авторы Patterns.dev:
Лидия Холли — штатный консультант и преподаватель по разработке программного обеспечения, которая в основном работает с JavaScript, React, Node, GraphQL. Она также занимается наставничеством и проводит личные тренинги.
Эдди Османи — технический менеджер, работающий над Google Chrome. Его команды работают над такими проектами, как Lighthouse, PageSpeed ​​Insights, Chrome User Experience Report и другими.

Материал книги будет полезен не только React‑разработчикам, но и всем, кто так или иначе интересуется или сталкивается с frontend‑разработкой. Это ознакомительная часть перевода учебника https://www.patterns.dev/. Перевод всей второй части учебника можно найти здесь.

P. S.: На данный момент выложено в виде pdf, в дальнейшем планируется полноценная публикация на github для удобства изучения.

P. P. S.: Вторая часть взята из книги: https://www.patterns.dev/, переведена на русский язык. Книга находится под лицензией CC BY-NC 4.0

Данный адаптированный материал распространяется на условиях лицензии Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)

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

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

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

Что получится, если попытаться описать составной объект? Как ни старайся, ничего другого, кроме древовидной структуры у вас не получится. Отсюда первый принцип:

Привет! Меня зовут Александр, я старший разработчик в команде, которая занимается оцифровкой документов. Когда мы разрабатываем пакеты библиотек компонентов, иногда возникает необходимость дополнить исполняемый код определенным контентом. Нередко этот контент нужен именно в виде отдельных файлов, а не встроенных ресурсов. Примерами таких задач могут быть различные пакеты .NET-оболочек, которым обычно необходимы исходные библиотеки. Нам же понадобились специальные шрифты во внутрикорпоративной библиотеке конвертации документов.

Мы видели два варианта решения проблемы:

Всем привет.

Данная статья будет полезна начинающим Java разработчиком понять зачем нужен шаблон проектирования «Цепочка ответственности» и как его можно использовать на примерах.

Итак начнем с самого начала. Основная суть данного шаблона: связывание объектов‑получателей в цепочку и передача запроса по ней.

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