#python — посты и обсуждения

Что такое облачные вычисления? 🏢

Представьте, что вместо того чтобы запускать скрипт на своем домашнем ноутбуке, вы арендуете крошечный, но очень мощный системный блок у IT-гиганта (Яндекса, VK или Amazon). Этот виртуальный сервер стоит в дата-центре:

У него идеальные условия (охлаждение, питание).

Он подключен к интернету оптикой.

Он работает 24/7 без праздников и обновлений Windows.

Облако — это просто аренда мощностей чужого компьютера через интернет.

​Объектно-ориентированное программирование (ООП) уже несколько десятилетий остаётся одной из главных парадигм в индустрии. Несмотря на рост популярности функционального подхода, большинство коммерческих систем, фреймворков и языков по-прежнему строятся вокруг объектов и классов. Однако вокруг ООП сложилось множество мифов, а его применение часто оказывается предметом жарких споров. Чтобы осознанно использовать эту парадигму, важно видеть не только её достоинства, но и ограничения, а также понимать, в каких контекстах ООП действительно приносит пользу, а когда становится обузой.

Что такое ООП: не только синтаксис, но и образ мышления

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

Важно разделять ООП как концепцию и конкретные языковые средства. Даже в языках, не имеющих ключевого слова `class` (например, JavaScript до ES6 или Lua), можно реализовать объектно-ориентированное проектирование через прототипы или таблицы. Ядро ООП составляет не синтаксис, а принципы организации кода. Как говорил Алан Кей, создатель термина «object-oriented»: «Я придумал термин „объектно-ориентированный“, и могу сказать, что не имел в виду C++». Для него важнее были сообщения и взаимодействие, а не иерархии классов.

Фундаментальные строительные блоки

1. Класс — абстрактное описание структуры и поведения будущих объектов. Это своего рода «чертёж», по которому создаются экземпляры.

2. Объект (экземпляр) — конкретная сущность, обладающая собственным состоянием и реагирующая на сообщения (вызовы методов).

3. Атрибуты (поля) — данные, хранящиеся внутри объекта и определяющие его состояние.

4. Методы — функции, принадлежащие классу и определяющие поведение объекта, а также способы изменения его состояния.

Например, в интернет-магазине класс `Product` описывает общую логику всех товаров: у каждого есть название, цена, остаток на складе. Конкретный объект `iPhone 15` будет экземпляром этого класса с заполненными атрибутами, а методы вроде `reserveStock()` или `applyDiscount()` определяют допустимые операции.

Четыре принципа, а не три

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

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

- Инкапсуляция — механизм, ограничивающий прямой доступ к внутренним данным и предоставляющий контролируемый интерфейс. Это не просто сокрытие, а гарантия целостности состояния объекта.

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

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

Эти принципы не самоцель, а инструменты для управления сложностью. Именно они лежат в основе как достоинств ООП, так и ряда его проблем.

#DST #DSTGlobal #ДСТ #ДСТГлобал #искусственныйинтеллект #парадигма #ооп #программирование #код #семантическиеинструменты #semanticdb #logosk #llm #kotlin #python #параллелизм #cicd #Smalltalk #Simula67 #FAIRCARE #Efos #AGI #GraphQL #SpotBugs #SonarQube #Roslyn #Akka #Orleans #Erlang

Источник: https://dstglobal.ru/club/1249-obektno-orientirovannoe-programmirovanie-istorija-analiz-i-buduschee.html

​Объектно-ориентированное программирование (ООП) уже более трёх десятилетий остаётся основой для построения сложных программных систем. Несмотря на рост функционального подхода и отказ от чистого ООП в ряде ниш, именно объекты и классы лежат в фундаменте большинства корпоративных платформ, фреймворков и коммерческих продуктов, от интернет-магазинов до банковских систем. При этом в профессиональной среде не утихают споры: одни считают ООП универсальным решением, другие — источником неоправданной сложности. Истина, как обычно, лежит между. В этой статье мы не просто перечислим плюсы и минусы, а погрузимся в архитектурные нюансы, разберём конкретные кейсы из e-commerce, сопоставим ООП с альтернативными дизайнами и предложим критерии, позволяющие определить, когда объектная парадигма уместна, а когда от неё разумнее отказаться.

1. Ядро ООП: от классов к контрактам

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

- Класс — шаблон, описывающий структуру и поведение будущих объектов. Он фиксирует, какие атрибуты будут у экземпляра и какие методы с ними работают.

- Объект — конкретный экземпляр класса, обладающий собственным состоянием и идентичностью.

- Атрибуты (поля) — данные внутри объекта, определяющие его состояние в конкретный момент времени.

- Методы — функции, ассоциированные с классом, через которые осуществляется доступ к состоянию и реализуется бизнес-логика.

- Интерфейс (протокол) — важнейший, часто недооценённый элемент. Это контракт, описывающий набор методов без их реализации. Именно интерфейсы, а не наследование классов, становятся краеугольным камнем современного ООП-дизайна, обеспечивая полиморфизм и слабую связанность.

На практике интерфейсы и протоколы позволяют разным классам предоставлять одно и то же поведение, не будучи связанными общей иерархией. В TypeScript и Go структурная типизация ещё усиливает этот акцент: класс соответствует интерфейсу просто потому, что имеет нужные методы, без явного объявления `implements`.

Пример объявления контракта для платёжной операции на C#:

```csharp

public interface IPaymentGateway

{

PaymentResult Process(PaymentRequest request);

}

```

Любой класс, реализующий `IPaymentGateway`, может быть подставлен в клиентский код без его изменения. Это основа для построения гибких, тестируемых систем.

2. Четыре принципа: абстракция как фундамент

Парадигму ООП определяют инкапсуляция, наследование, полиморфизм и абстракция. Именно последняя часто остаётся в тени, хотя является первичной.

- Абстракция — выделение существенных характеристик объекта и игнорирование несущественных. Класс `PaymentProcessor` скрывает за методом `Process(amount)` детали HTTP-запросов, форматирования, обработки ошибок и повторных попыток. Потребителю не нужно знать, как устроен обмен с банком, ему важен результат.

- Инкапсуляция — механизм, защищающий внутреннее состояние объекта от неконтролируемого изменения и предоставляющий к нему доступ только через заданные методы. Это не просто `private` поля, а гарантия целостности данных. Например, метод `ApplyDiscount` может валидировать допустимость скидки, прежде чем изменить атрибут `price`.

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

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

#DST #DSTGlobal #ДСТ #ДСТГлобал #программирование #парадигма #ООП #код #AIассистенты #Семантическиеинструменты #SemanticDB #LOGOSk #LLM #Kotlin #Python #Параллелизм #CICD #IntelliJIDEA #VisualStudio #VSCode #DTO #JVM #DataTransferObject

Источник: https://dstglobal.ru/club/1248-obektno-orientirovannoe-programmirovanie-razbor-paradigmy-eyo-sily-i-ogranichenii

Большинство трейдеров смотрят на рынок через индикаторы. Скользящие средние показывают тренд, RSI пытается найти перекупленность, MACD оценивает импульс. Однако все эти инструменты имеют одну общую особенность — они анализируют уже сформировавшееся движение цены.

Но что если исследовать не производные от цены, а саму структуру рынка?

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

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

Алгоритмическое определение фракталов позволяет формализовать этот процесс.

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

Такой подход открывает несколько важных преимуществ:

• выявление ключевых экстремумов без визуального анализа;
• уменьшение влияния рыночного шума;
• адаптация к различным таймфреймам;
• обнаружение зон возможного разворота;
• построение объективных моделей рыночной структуры.

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

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

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

Именно там могут скрываться закономерности, которые невозможно увидеть через традиционные инструменты технического анализа.

#Фракталы #АлгоритмическаяТорговля #Python #ТехническийАнализ #DataScience #Quant #ФинансовыеРынки #Трейдинг #Инвестиции #Математика

Привет, коллеги! 👋

Хочу поделиться опытом создания автономного ИИ-агента на блокчейне Base (L2 Ethereum).

**Что это такое:**

Агент AlexDOC работает на платформе moltlaunch — это смарт-контракт, который автоматически принимает задачи от клиентов, обрабатывает их через ИИ (Mistral-7B) и отправляет результат. Оплата происходит в ETH напрямую на кошелёк.

**Техническая часть:**

- Python-скрипт опрашивает API moltlaunch каждые 60-90 секунд

- При новой задаче — автоматическая отправка в Hugging Face Inference API

- Полученный ответ отправляется обратно через CLI

- Обработка ошибок: рейт-лимиты (429), SSL-ошибки, таймауты

**Что умеет агент:**

✅ Копирайтинг и тексты для сайтов

✅ Переводы английский ↔ русский

✅ Технический анализ и аудит

✅ Базовый код (HTML/CSS/JS)

✅ Исследования и обработка данных

**Экономика:**

- Цена за задачу: 0.0025 ETH (~$5.30)

- Оплата в ETH на кошелёк: 0x46eb0a4E43F7c9d4c05bb91C96d5825c64d81B4d

- Агент зарегистрирован: #53488

- TX регистрации: https://basescan.org/tx/0xdc5ceecd760b587671874ae5fe7fee28983c5a7ffa62c52b1c5da7c21b08c023

**Как это работает:**

1. Клиент создаёт задачу: `mltl hire --agent 53488 --task "Ваша задача"`

2. Скрипт видит задачу в блокчейне

3. Отправляет текст в ИИ для обработки

4. Получает готовый ответ

5. Автоматически отправляет результат

6. Клиент подтверждает → ETH приходит на кошелёк

**С какими проблемами столкнулся:**

1. Cloudflare иногда обрывает SSL-соединение → добавил повторные запросы

2. Hugging Face free tier имеет лимиты → модель может загружаться 20-40 сек

3. Windows Console плохо отображает эмодзи → заменил на текстовые метки

4. Индексация агента в каталоге занимает время (пока жду)

**Открытые вопросы сообществу:**

- Как вы обрабатываете рейт-лимиты при опросе API?

- Стоит ли выносить SSL-обработку в отдельный модуль?

- Как лучше логировать работу фонового скрипта?

**Планы:**

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

**Код и детали** — готов поделиться в комментариях или ЛС.

🔗 **Проверить агента** — https://basescan.org/tx/0xdc5ceecd760b587671874ae5fe7fee28983c5a7ffa62c52b1c5da7c21b08c023

Буду рад фидбеку от сообщества! 🙏

#Base #moltlaunch #ИИ #крипта #блокчейн #Python #автоматизация #фриланс #ETH