ООП *

⚡ Tl;dr

• Модуляризация — это метод разделения сложных систем на более мелкие удобоваримые части для лучшего управления и восприятия.
• Она повышает эффективность, надежность и ремонтопригодность программных проектов за счет организации кода в модули.
• Она снижает когнитивную нагрузку на разработчиков за счет уменьшения объема информации, которую им приходится обрабатывать за один раз, что облегчает понимание сложных систем и предотвращает их «выгорание».
• Модули при разработке программного обеспечения можно рассматривать как строительные кубики, наподобие деталей «Лего».
• Каждый модуль имеет уникальный набор общедоступных интерфейсов, структур данных или сообщений, которые служат контрактами для других разработчиков.
• При работе с модулями важно относиться к ним как к «черным ящикам» и взаимодействовать с ними только через определенные общедоступные интерфейсы, чтобы избежать сильного связывания и повысить модульность системы.
• Сборки используются для группировки кода в .NET, поскольку они обеспечивают более высокий уровень инкапсуляции (использование внутреннего доступа). Это позволяет разработчикам контролировать уровень доступа другого кода к членам типа и помогает защитить детали реализации типа или элемента.
• Чтобы сделать реализацию прозрачной для тестирования, можно использовать атрибут в файле csproj и указать имя сборки тестового проекта.

Постараемся рассмотреть шаблоны проектирования на примере языка Go

В первой статье цикла рассмотрим один из самых простых паттернов - Adapter.

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

Конечно, мне придется продемонстрировать применение на практике принципов ООП: инкапсуляция, наследование, полиморфизм и то, как они работают.

Конечно, разберем как все это влияет на производительность. Я надеюсь, что получится сформулировать некое подобие ответа на критику постулатов «чистого» кода от достаточно успешного (видимо) иностранного программиста в переводе на Хабре: «Чистый» код, ужасная производительность.

Правила «чистого» кода, изложенные в той статье помогут нам подойти к реализации принципов ООП в нашей задаче.

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

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

Как-то в общении с моим другом-разработчиком из одной крупной софтверной компании у нас зашёл разговор о взаимодействии распределённых команд. В его компании было множество достаточно изолированных команд, каждая из которых разрабатывала свой сервис. В ответ на мой вопрос, как команды расшаривают API, я получил ожидаемый ответ: Open API. Open API, безусловно, прекрасный инструмент, но у него есть ряд недостатков. 

Меня зовут Андрей Зяблин, я главный разработчик в «Магните». Расскажу о том, как распространять API нативным для Java способом и пользоваться им в объектно-ориентированном стиле без использования генераторов кода. 

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

Об алгебре кортежей (АК) и ее использовании для логико-семантического анализа было рассказано в моей статье в Хабре. В комментариях к статье предлагалось обратить внимание на функцию SELECT в языке SQL, которая соответствует операции Selection (Выборка) в реляционной алгебре. Эта операцию можно рассматривать как один из вариантов математической модели вопроса.

Предлагаемый здесь вариант смысла вопроса заключается в том, что в вопросе заданы некоторые ограничения (область знания, ситуация, значения некоторых атрибутов и т.д.), которые требуется использовать для того, чтобы найти или вычислить значение определенного атрибута или проверить правильность заданных в вопросе соотношений. Эта семантика применима к восполняющим вопросам типа «Что?», «Где?», «Когда?», к уточняющим вопросам типа «Верно ли, что А?» и к ИЛИ-вопросам типа «Что правильно: А или Б?». Назовем такие вопросы ограничительными. Их можно считать вариантами известной в искусственном интеллекте задачи удовлетворения ограничений.

Преуведомление

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

Выпуск Java 21 состоялся 19 сентября 2023 года. В этой версии поддерживаются паттерны записи в switch-блоках и выражениях. Такой синтаксис выглядит монументально (как минимум, по меркам Java). Это водораздел, после которого мы вправе говорить, что в Java полноценно поддерживаются паттерны функционального программирования, подобно тому, как это сделано в Kotlin, Rust или C#. Вот и первый пункт, который пробуждает во мне зависть (я Kotlin-разработчик).

Если просто добавить к определению бина аннотацию @Scope(SCOPE_PROTOTYPE), и использовать этот бин в синглтоне через аннотацию @Autowired – будет создан только один объект. Потому что синглтон создается только однажды, и обращение к прототипу случится тоже однажды при его создании (при внедрении зависимости).

На самом деле вариантов довольно много:

Абстрактный тип данных. 

Зачем нужны абстрактные типы данных? Чем они полезны для программиста? Когда необходимо создавать эти абстракции, а когда можно обойтись без них? Тип данных 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.