Вопросы по ООП в MQL5 - страница 50
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Дмитрий, наверное в данном случае немного путаете задачи паттернов Хранитель и Прототип, и всех возможных их комбинаций и проявлений. Первый- Снимок не обязательно должен копировать весь объект, в отличие от Прототипа.
И да, потребность в инкапсуляции проявляется в основном на крупных проектах с кучей народа. Для таких игрушек типа большинства здешних задачек, излишество конечно)
До чего всё докатилось - сидеть и на полном серьезе с умным видом обсуждать, что переменной может быть присвоено значение, а потом оно может быть использовано. О да - при программировании чего угодно на чем угодно множество раз разным переменным присваиваются разные значения, а потом они используются. Но теперь оно по-другому называется, и теперь, когда обсуждаешь это, надо хмурить брови и напускать на себя серьезный вид.
И важно не ошибиться, если все поля сохраняются, то это Прототип, а если не все, то Хранитель, а то пацаны смеяться будут.
Вы случайно не из секты "Интырнет они ставят, интырнет, он нам и на...й не нужОн, интырнет этот ваш..." ???
1. Хранитель, по дизайну похож на паттерн, который используют для хранения состояния при наборе с изменяемым содержимым для отката изменений, когда этих изменений не одно, а несколько сотен. Например редактор фото, текста...
Нашел после написания - https://refactoring.guru/ru/design-patterns/memento
2. По сути это плохая практика не зная и не разбираясь в теме, что-то там критиковать...
3. Как то, что и так вам непонятно может стать более запутанным и труднопонимаемым?
4. Дальше сами...
А ООП тут причем?
Вы случайно не из секты "Интырнет они ставят, интырнет, он нам и на...й не нужОн, интырнет этот ваш..." ???
1. Хранитель, по дизайну похож на паттерн, который используют для хранения состояния при наборе с изменяемым содержимым для отката изменений, когда этих изменений не одно, а несколько сотен. Например редактор фото, текста...
Нашел после написания - https://refactoring.guru/ru/design-patterns/memento
2. По сути это плохая практика не зная и не разбираясь в теме, что-то там критиковать...
3. Как то, что и так вам непонятно может стать более запутанным и труднопонимаемым?
4. Дальше сами...
Полностью поддерживаю! Спасибо что аргументировали мой подкол.. мне было лень))
в п.1 лишь добавил бы, что снимок не обязательно хранит все данные объекта, и "снимков с разных сторон" одного и того же объекта может быть несколько ветвей с сотнями снимков. В этом случае хранить сотни копий не используемых данных - воистину наихудшая практика.
До чего всё докатилось - сидеть и на полном серьезе с умным видом обсуждать, что переменной может быть присвоено значение, а потом оно может быть использовано. О да - при программировании чего угодно на чем угодно множество раз разным переменным присваиваются разные значения, а потом они используются. Но теперь оно по-другому называется, и теперь, когда обсуждаешь это, надо хмурить брови и напускать на себя серьезный вид.
И важно не ошибиться, если все поля сохраняются, то это Прототип, а если не все, то Хранитель, а то пацаны смеяться будут.
Дмитрий, уверяю, я бы и над вами с радостью посмеялся, ну люблю я это дело) но в данном случае вы преувеличили, даже особо ну улыбнуло.
Вы просто действительно перепутали - СНИМОК не равно КОПИРОВАНИЕ ОБЪЕКТА, я вам подсказал.
Если неясно отличие специально для вас поясню на примере - объект 1000 байт, для снимка нужно 200, зачем копировать 800, тем более если снимков нужно хранить много-много.
p/s/ Да и вообще. Неужели нет у людей понимания что паттерны - всего лишь элементарный пример решения элементарной ТИПОВОЙ задачи. А на деле задачи не элементарные, а посложнее. И для решения реальных задач паттерны и нужны, только зачастую не в чистом книжном виде, а в адаптированном под конкретную задачу, возможно скомбинированные между собой, возможно с добавлением какой-либо импровизации, выраженной иногда в упрощении, если задача позволяет, или наоборот "утяжелении" реализации.
Опять же для чего нужна инкапсуляция и интерфейсы - это наверное невозможно понять если у тебя айкью ниже Вассермана, ну или если ты не участвовал в реальных проектах, когда разные части проекта меняются разными людьми одновременно, и несоблюдение элементарных принципов ООПроектирования влечёт громадные затраты по отлову багов. Действительно зачем всё это для штамповки советников для маркета))
Sergey Dzyublik:
1. Хранитель, по дизайну похож на паттерн, который используют для хранения состояния при наборе с изменяемым содержимым для отката изменений, когда этих изменений не одно, а несколько сотен. Например редактор фото, текста...
2. По сути это плохая практика не зная и не разбираясь в теме, что-то там критиковать...
Выделил ключевой момент. Именно изменяемое содержимое - корень многих проблем неправильного использования ООП. Я тоже долгое время увлекался таким, но с опытом постепенно приходит понимание. Код, в котором куча взаимосвязей между объектами (указатели), и при этом объекты изменяемые - это аццкая лапша, в которой потом чёрт ногу сломит. Поэтому нужно стремится к тому, чтобы ссылочные объекты были неизменяемыми. Меняться должны только value-объекты, т.е. структуры и простые типы, ну и указатели.
Т.е. вот в данном случае исходный объект желательно объявить структурой, а не классом. Тогда можно менять его содержимое. При этом естественно никакой указатель на него уже не возьмёшь и не сохранишь как в обсуждаемом паттерне, и это правильно. Менять объекты нужно явно обращаясь к их методам, либо передавая их как аругумент в функцию. Т.е. так:
либо
А не так:
что выглядит, будто бы мы изменяем объект memento, а на самом деле меняется какой-то другой объект, который возможно расположен в другом месте программы. Создаётся побочный эффект. Это то же самое, как изменить глобальную переменную в одном месте, а в другом месте использовать её значение.
Т.е. мементо не должен хранить ссылку на исходный объект. А хранить только содержимое. Это всё моё мнение, но я думаю, что недалёк от истины )
не претендую на собственное мнение, возможно где то читал, но имхо, в программировании всего две задачи: правильная структура программы и быстро подобрать хорошее имя для переменной, а все остальное делается довольно просто
я тоже серьезно
спасибо, Ваши паттерны почитаю
подожду, вдруг кто еще появится, а то вот только на вопросы уровня бегинер енд трейнер акадевелоперы налетают )))
1) Код, в котором куча взаимосвязей между объектами (указатели), и при этом объекты изменяемые - это аццкая лапша, в которой потом чёрт ногу сломит. Поэтому нужно стремится к тому, чтобы ссылочные объекты были неизменяемыми.
2) Меняться должны только value-объекты, т.е. структуры и простые типы, ну и указатели.
3) Т.е. вот в данном случае исходный объект желательно объявить структурой, а не классом. Тогда можно менять его содержимое. При этом естественно никакой указатель на него уже не возьмёшь и не сохранишь как в обсуждаемом паттерне, и это правильно.
4) Менять объекты нужно явно обращаясь к их методам, либо передавая их как аругумент в функцию.
что выглядит, будто бы мы изменяем объект memento, а на самом деле меняется какой-то другой объект, который возможно расположен в другом месте программы. Создаётся побочный эффект.
1. Получается структура данных Дерево - это все от лукавого...
2. Бедный С++ в нем же class == private struct, что же делать, наверное стоит отказаться от структур и классов.
3. И это правильно: нет тебе ни паттернов, ни сортировки через указатели, ни экономии по памяти, особенно для больших объектов, ...
4. Нужно не забыть еще запретить использование интерфейсов и шаблонных функций, а то вообще не понятно с каким объектом происходит работа - ужас то какой...