Одна из проблем отечественной школы - абсолютно кондовый язык. Как будто через дебри пробираешься. Причем в переводах «классиков» поточное не встречается, т.е. можно на русском нормально писать технические тексты.
О написании графического редактора без библиотек и вообще о написании графического редактора речи не идёт. Речь о классическом примере реализации приложения на на ООП. Можно было бы последовать примеру товарища Буча и взять его вариант с Гидропонной схемой. Но тут у народ в 5 примитивах разбираться не может и ТЗ из трех строчек до конца прочитать. Вы кстати на Коболе писать собираетесь? Причём тут что на нем тонны кода написаны? На bash написано больше чем не COBOL, и продолжают писать и что?
Вообще-то договор как объект должен быть не изменяемым. Изменяться должны состояния договора - которые вроде как отдельные сущности. Далее по идее должен быть Актер, который выполняет действия над Договором, следуют каким-то Полиси. В приципе это все объекты:).
Тут в соседней ветке с представлением простого графического редактора не можем разобраться -взять несколько фигур и нарисовать на канвасе, а вы тут про высокие материи: договор, бизнес процесс …
Все гораздо проще. Есть план «развития» продукта. Что вполне вписывается в «тестовую» архитектуру. Задача посмотреть как разные подходы будут себя вести. Опять-таки, задача сохранить „time to market“. Ниже привели пример, который вроде как позволит все безгранично расширять. Но как MVP это в любом случае оверинжиниринг.
На мой неискушенный взгляд вы тут слегка огород нагородили. Вместо понятного синтаксиса: тип: переменная вы все закинули в массив с неясной структурой. Далее, у вас все элементы массива оказались одного и того же типа. Что может быть нежелательным ограничением.
std::println("Drawing {} at {} {} {} {}",name(),p[0],p[1],p[2],p[3]); }
Я бы не хотел такой код поддерживать, когда автор давно работу поменял, а мне понять надо что там и где используется.
Согласен. Идея в том что дальше идут «требования на изменения» и «дополнительные фичи» идея посмотреть как будут развиваться процедурный/функциональный/ООП подходы
Замените слово shape на Message, а Canvas на messageQueue. Получите задачу обработки входящих сообщений. Не ожидал что абстрактное мышление это отдельная фича :)
Тогда возьмете на себя задачу реализовать на чистом процедурном подходе? std:vectorstd:variant это хак по меньшей мере. Стандартные процедурные языки не используют понятие темплейтов. Поправьте если я не прав. Соответственно в рамках чисто процедурного подхода эта задача просто не решается. Вам надо либо с void указателями работать, либо «изобретать» свой rtti. Что имеет место быть, но как бы добавляет аргументов в сторону сторонников ООП подхода. Со своей стороны могу на AWK реализовать :)
Я бы был менее категоричен: во-первых: «не очень хорошо знаете современный С++»,
Во-вторых: в предыдущей статье я ссылался на книгу Гради Буча, которая вышла некоторое время назад. Примеры там написаны на C++/Java без использования новейших фич языков и даже без темплейтов. Так что я старался держаться одного стиля с оригиналом.
Это пока не надо нормально транзакциями управлять и любая БД как файловое хранилище на стероидах используется.
Вы почитайте про уровни изоляции транзакций на досуге, достаточно чтобы перестать восхищаться обертками над БД.
Сборщик мусора вещ обязательная, только это внешний интерфейс котороый реализован в объекте хозяин :)
Давайте, я думал на erlang сам написать, но если в на elixir напишите -будет классно. Ссылка на репо внизу статьи. Ждём реализации
Одна из проблем отечественной школы - абсолютно кондовый язык. Как будто через дебри пробираешься. Причем в переводах «классиков» поточное не встречается, т.е. можно на русском нормально писать технические тексты.
О написании графического редактора без библиотек и вообще о написании графического редактора речи не идёт. Речь о классическом примере реализации приложения на на ООП. Можно было бы последовать примеру товарища Буча и взять его вариант с Гидропонной схемой. Но тут у народ в 5 примитивах разбираться не может и ТЗ из трех строчек до конца прочитать. Вы кстати на Коболе писать собираетесь? Причём тут что на нем тонны кода написаны? На bash написано больше чем не COBOL, и продолжают писать и что?
Проблема мутирует его get-тера, должна решаться нормальным конструктором: object creation= resource acquisition
Если генерацию токена вынести в конструктор то все в принципе работа не как ожидалось… пока программисты конвенциям следуют. :)
Я не такой быстрый. Мне все ваши наброски ещё множить в репо чтобы потом разбираться можно было :) наконец-то функциональщики подключились :)
Вообще-то договор как объект должен быть не изменяемым. Изменяться должны состояния договора - которые вроде как отдельные сущности. Далее по идее должен быть Актер, который выполняет действия над Договором, следуют каким-то Полиси. В приципе это все объекты:).
Тут в соседней ветке с представлением простого графического редактора не можем разобраться -взять несколько фигур и нарисовать на канвасе, а вы тут про высокие материи: договор, бизнес процесс …
Дак в статье все написано раздел: Code-Battle: MVP графического редактора
Товарищи, пожалуйста, читайте ТЗ до конца:
Задача: реализовать базовый графический редактор
Фигуры: точка, линия, круг, квадрат, прямоугольник, треугольник, ромб, овал
Функциональность: добавление фигур на канвас, отрисовка
С таким подходом мы собеседование в FAAG ( или как его там, FB, Amazon,Apple,Google..) не пройдем :)
Все в детали углубились а базовый функционал никто не реализовал.
В этом и приколка :)
Как в анекдоте: «я знал что дискуссия будет только по последнему вопросы ..»
Все гораздо проще. Есть план «развития» продукта. Что вполне вписывается в «тестовую» архитектуру. Задача посмотреть как разные подходы будут себя вести. Опять-таки, задача сохранить „time to market“. Ниже привели пример, который вроде как позволит все безгранично расширять. Но как MVP это в любом случае оверинжиниринг.
На мой неискушенный взгляд вы тут слегка огород нагородили. Вместо понятного синтаксиса: тип: переменная вы все закинули в массив с неясной структурой. Далее, у вас все элементы массива оказались одного и того же типа. Что может быть нежелательным ограничением.
std::println("Drawing {} at {} {} {} {}",name(),p[0],p[1],p[2],p[3]);
}
Я бы не хотел такой код поддерживать, когда автор давно работу поменял, а мне понять надо что там и где используется.
Согласен. Идея в том что дальше идут «требования на изменения» и «дополнительные фичи» идея посмотреть как будут развиваться процедурный/функциональный/ООП подходы
Замените слово shape на Message, а Canvas на messageQueue. Получите задачу обработки входящих сообщений. Не ожидал что абстрактное мышление это отдельная фича :)
Тогда возьмете на себя задачу реализовать на чистом процедурном подходе? std:vectorstd:variant это хак по меньшей мере. Стандартные процедурные языки не используют понятие темплейтов. Поправьте если я не прав. Соответственно в рамках чисто процедурного подхода эта задача просто не решается. Вам надо либо с void указателями работать, либо «изобретать» свой rtti. Что имеет место быть, но как бы добавляет аргументов в сторону сторонников ООП подхода. Со своей стороны могу на AWK реализовать :)
Класс. Спасибо. Вечером смержу :)
Я бы был менее категоричен: во-первых: «не очень хорошо знаете современный С++»,
Во-вторых: в предыдущей статье я ссылался на книгу Гради Буча, которая вышла некоторое время назад. Примеры там написаны на C++/Java без использования новейших фич языков и даже без темплейтов. Так что я старался держаться одного стиля с оригиналом.
И не плохо бы было их в коллекцию запихнуть чтобы в main все не прописывать.