ООП *

В своей статье я бы хотел поделиться технической частью игры, которую сделали два человека. Будут рассмотрены основные архитектурные шаблоны (design patterns) и приёмы, дополнительные библиотеки, особенности портирования при работе с движком cocos2dx. Исходный код здесь.

На наш взгляд, объектный язык ограничений (Object Constraint Language, OCL) должен знать каждый, кто занимается моделированием или кому интересна модельно-ориентированная разработка. Однако, он незаслуженно обделен вниманием в сети вообще, а, уж, в русскоязычном сегменте информации просто мизер. Что это за язык и зачем он нужен, описано в этой статье. Статья не претендует на фундаментальность, полноту охвата, точность определений и т.п. Её задача: 1) на простых примерах познакомить с OCL тех, кто никогда не слышал об этом языке, 2) а для тех, кто о нём слышал, возможно, открыть новые способы его применения.

Введение

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

Одним из наиболее распространенных методов естественных вычислений являются генетические алгоритмы. Чтобы лучше разобраться, как эти алгоритмы устроены и как работают, было решно воспроизвести один из таких алгоритмов — генетический. Для того, чтобы применять какой-либо метод для решения конкретных задач этот метод необходимо освоить. Поэтому генетический алгоритм, рассмотренный в данной работе, не решает никакой конкретной задачи. Главными являются одновременно процесс и результат работы по созданию программы по моделированию и визуализации работы генетического алгоритма. Важен полученный программистский опыт.
Программа моделирует поведение популяции самых примитивных живых организмов. Эта программа вряд ли будет иметь какое-либо практическое применение, но она наглядно иллюстрирует принцип работы генетических алгоритмов.

Моделирование работы генетического алгоритма, в котором естественный отбор определяется условиями среды

Моделирование – метод научного познания объективного мира через построение и изучение моделей.

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

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

Для работы выбран язык программирования C++, так как этот язык является мощным, проверенным временем языком программирования. C++ получил широкое распространение среди программистов. Для визуализации использована открытая графическая библиотека OpenGL.

Привет хабраплюсплюсовцам!

Хочу разобрать проблему компилятора avr-g++, из-за которой в разных дискуссиях про AVR и Arduino звучит «С++ — это не для микроконтроллеров, C++ жрёт память, C++ генерирует раздутый код — пишите на голом C, а лучше на ASM».

Для начала давайте разберёмся, в чём же преимущество C++ перед C. Концепций, которые добавляет C++ много, но самая значимая и самая эксплуатируемая — это поддержка ООП. Что такое ООП?

• Инкапсуляция
• Наследование
• Полиморфизм

Использование первых двух пунктов в C++ «бесплатно». Никакого преимущества программа на чистом C перед программой на C++ с инкапсуляцией и наследованием не имеет. Картина меняется, когда мы подключаем к действу полиморфизм. Полиморфизм бывает разным: compile-time, link-time, run-time. Я говорю о классическом run-time, т.е. о виртуальных функциях. Как только в своих классах вы начинаете добавлять виртуальные методы, чудесным образом растёт потребление как Flash-памяти, так и SRAM.

Почему так происходит и, что с этим можно было бы сделать, расскажу под катом.

Предисловие

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

Поддерживаются следующие типы данных:
— Все фундаментальные типы С++
— std::string
— std::vector где T — все что угодно из этого же списка
— Любой перечислимый тип

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

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

Цель

Разделить взаимодействия пользовательского интерфейса между веб-клиентом и веб-приложением на три чётко определённые роли.

Предпосылки

Термин MVC испытывает некоторое семантическое размытие своего первоначального значения, особенно в контексте веба (см. видео Стефана Прибша для более подробного рассмотрения вопроса). В качестве средства устранения этого размытия предлагаю вашему вниманию описание паттерна Action-Domain-Responder, являющегося доработкой концепции MVC под нужды решения специфичных для веба задач.

Я считаю, что ADR значительно лучше соответствует тому, что мы на самом деле реализуем в процессе веб-разработки изо дня в день. К примеру, на создание этого паттерна меня частично вдохновило то, как мы решаем проблемы роутинга и диспетчеризации, ведь в общем случае при роутинге и диспетчеризации мы обращаемся не к классу контроллера per se, а к какому-то конкретному методу действия в этом классе контроллера.

Еще одной вскрывшейся проблемой является тот факт, что часто мы рассматриваем Представление (View) как шаблон (template), хотя в контексте веба, вероятно, более уместно было бы говорить о том, что Представлением является HTTP-ответ. Исходя из вышесказанного, я считаю, что ADR способен предоставить лучшее, чем MVC, разделение концепций для веб-приложений.

JavaScript – один из главных языков нашего стека в Хекслете. Мы используем ReactJS и NodeJS в интерактивных частях платформы, и сделали вводный курс (более продвинутые – на подходе). Любовь к JS помогла опубликовать этот перевод хорошего эссе «Prototypes are Objects (and why that matters)».

Этот пост рассчитан на тех, кто знаком с объектами в JavaScript и знает, как прототип определяет поведение объекта, что такое функция-конструктор и как свойство .property конструктора относится к объекту, который он конструирует. Общее понимание синтаксиса ECMAScript 2015 тоже не помешает.

Мы всегда могли создать класс в JavaScript таким образом:

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

Первая часть здесь. Продолжение:

Семь долбаных лет я ждал язык, который хоть как то ответит части моих желаний. За это время, и в фоновом режиме я препробывал всё. Всё — означает, всю херню общего назначения, и всю херню не совсем общего назначения. Нельзя прочувствовать язык только что-то прочитав про него и написав Hello World. Чтобы понять — надо хоть немного попрограммировать — написать какую нить вещь. И вот все это время, я в минуты отчаянья качал какой-нить “замечательный язык”, и пытался что-то написать. Какие-то вещи даже до сих пор крутятся в конторе (или крутились).

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

Прочитали? Дальше будет про лучший в мире язык программирования, который я назову ближе к концу. Да, да, еще три дня назад я и не думал что единороги существуют — ведь каждый язык так или иначе сосет, и каждый сосет по-своему (хотя нет, есть и такие которые сосут всегда и везде, но о них не будем). Как инженер, я прекрасно понимал что в вопросе языка не возможно без разнообразных trade offs, начиная с garbage collected vs manual memory management, хотя Rust пытается съесть рыбку не присев на палку в этом вопросе, и так далее. Хоть мы и говорим о языках общего назначения, все они так или иначе позиционируют себя, фокусируясь на каких-то идеях, принципах, и целях, в которых они хороши, оставляя все не согласованное с такими принципами в лучшем случае возможными, но не эффективными и/или не удобными. Одним словом нецелесообразными. Однако язык, сочетающий в себе несочетаемое, есть.

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



Попробуем разобрать «по косточкам» один из таких вопросов — что значит слово «static» в PHP и зачем оно применяется?

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

Как-то я всерьез занялся покорением ООП в lua. И все, что я находил в интернете по этой теме, было вырвиглазными нагромождениями кода с обилием нижних подчеркиваний, которые никак не вписывались в элегантность этого языка. Поэтому я решил искать простое решение.

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

Введение

Слишком много раз я встречал приложения, о которых говорили, что у них есть модель предметной области и приложение было спроектировано на основе это предметной области. Однако в действительности всё, что я видел, было коллекцией сущностей (я бы даже сказал DTO), имеющих кучу свойств без какой бы то ни было реальной логики, связанной с сущностью. Кроме того, я могу найти много сервисов всех видов, которые содержат красочную смесь бизнес-логики и/или инфраструктуры. Если приложение вдобавок использует шину сообщений (как NServiceBus, Mass Transit Bus или Azure Bus), то конечно же заметно, что некие сообщения передаются от одного модуля к другому или нескольким модулям. К сожалению, сообщения часто имеют очень обобщённые названия, содержащие слова “обновить”, “изменить”, “добавить” или “удалить”, и несут большое количество полезной нагрузки — десятки разнообразных свойств. Часто из названия сообщения совершенно не очевидно, является ли оно командой или событием, и чтобы определить это, приходится глубоко зарыться в реализацию.

Я искренне хотел бы, чтобы все написанное выше было бы преувеличением или же имело смысл только для «старых» приложений, которые разрослись и вышли из-под контроля. Но печальная истина в том, что это относится ко многим новым проектам, даже тем, которым всего несколько месяцев от роду. Почему так происходит? Конечно, есть много разных причин: отсутствие знаний является одной из наиболее важных.

Начало

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

На следующее утро в зале для совещаний собрались ключевые сотрудники направления. Технический директор (для тех, кто с ним еще не знаком, — его зовут Иван) сразу перешел к сути вопроса: «Приветствую всех! Как вы знаете, некоторое время назад мы поставили перед собой цель расширить присутствие на рынке и для этого открыли новый офис продаж. Так вот, эта стратегия сработала. Через месяц мы подписываем договор на разработку и внедрение платформы дистанционного образования. Проект очень интересный, но пока не об этом. Чтобы его потянуть, нам нужно срочно формировать новую команду в направлении образовательных систем.»

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

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

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

Добрый день!

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

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

Пусть нам надо смоделировать тезис, о том, что на каждом автомобиле стоит по 4 колеса. Не группа из четырех колес, а именно, — 4 колеса.

В терминах ER модели принято говорить, что есть автомобиль, есть колесо и есть связь между автомобилем и колесом. Связь эта называется «колесо-автомобиль» и имеет отношение один ко четырем. Связь, читаемая от колес, называется: «стоит на», связь, читаемая от автомобиля, называется: «имеет».



В терминах ООП говорят так: есть класс ООП автомобилей и есть класс ООП колес. Между этими классами ООП есть связь один к четырем. Связь называется: «автомобиль-колесо». Связь, читаемая от колес, называется: «стоит на», связь, читаемая от автомобиля, называется: «имеет».



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

MVC в наше время не использует только ленивый. Да и ленивый тоже, использует CMS которая реализует этот подход.
Но MVC ли это?