Вопросы по ООП в MQL5 - страница 49
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А смысл этих диких игра разума? "Назначение" (в кавычка, потому что... гладиолус) паттерна - "не нарушая инкапсуляцию, зафиксировать и сохранить внутреннее состояние объекта" (в кавычках, потому что цитирование). Но без метода setState() не обойтись. Ну и где здесь сохранение инкапсуляции? Для каждого приватного поля писать еще по два метода... да... круто инкапсуляция сохраняется.
И признайтесь честно, на практике будете применять такой подход? Сомневаюсь. На практике сделаете явно и прозрачно - например, структуру с таким же набором полей и пару методов для сохранения и восстановления. И вот тогда действительно сохранится инкапсуляция, появится только два новых метода: для сохранения состояния и для восстановления.
ОК, сохраню, мне принцип работы нужно было потестить, возможно это то, что искал - один код для тестера и для рабочего ЕА который может сохранять свое состояние, а в тестере наоборот не тратить ресурсы на "лишние телодвижения" - часть такого паттерна можно же #ifdef -ами прикрыть ;)
Я вот пытаюсь понять смысл этого гемора с хранителем, но чё-то не вижу особой пользы. По сути это плохая практика программирования через создание сайд-эффектов. Когда меняя один объект, ты меняешь другой. В итоге код становится запутанным и труднопонимаемым. Лучше всё-таки стремится к чистоте кода, имхо.
Что мешает просто перекопировать объект в другой объект, а потом перекопировать обратно? По сути то же самое, только правильней и понятней.
Аналогично и с синглтоном. Если этот синглтон имеет одновременно и сеттеры, и геттеры (т.е. позволяет менять своё состояние и читать его), то это равносильно работе с глобальными переменными. При этом каждый программист знает, что работа через изменение глобального состояния - это зло. Но синглтон почему-то не в счёт )
Я вот пытаюсь понять смысл этого гемора с хранителем, но чё-то не вижу особой пользы. По сути это плохая практика программирования через создание сайд-эффектов. Когда меняя один объект, ты меняешь другой. В итоге код становится запутанным и труднопонимаемым. Лучше всё-таки стремится к чистоте кода, имхо.
все проще, я изучаю технические возможности
ну и наверное склад мышления накладывает отпечаток, мне привычнее состояние автоматизированной системы оценивать с позиции конечного автомата, и это всегда вызывает желание иметь возможность сохранить "слепок" состояния системы про запас )))
мне привычнее состояние автоматизированной системы оценивать с позиции конечного автомата, и это всегда вызывает желание иметь возможность сохранить "слепок" состояния системы про запас )))
Да цель то понятна. Просто такая реализация излишне усложнена и запутана, на мой взгляд.
Да цель то понятна. Просто такая реализация излишне усложнена и запутана, на мой взгляд.
увы, так устроенны люди - пока сам палок не наломаю и шишек не насобираю, вряд ли дойдет )))
увы, так устроенны люди - пока сам палок не наломаю и шишек не насобираю, вряд ли дойдет )))
В том, что кто-то изучает эти паттерны, ничего плохого, это замечательно - гимнастика для мозгов и т.д. и т.п. И вот, в итоге, при ближайшем их рассмотрении, оказывается, что это какой-то адский фэйк, какой-то мэм для оттяжки лохов от реальности, так же, как изучение визуал бэйсика через написание консольных приложений.
Изучен этих паттернов интересно, хотя бы с точки зрения изучения чьих-то тараканов - какие они бывают в природе.
А если по-настоящему подходить к задаче сохранения состояния объекта, то здесь путь через обеспечение возможности копирования одного объекта в другой, кому что нравится, просто ли через метод, или через перегрузку =. А дальше, может и отпадет желание инкапсулировать эту возможность.
А если по-настоящему подходить к задаче сохранения состояния объекта, то здесь путь через обеспечение возможности копирования одного объекта в другой, кому что нравится, просто ли через метод, или через перегрузку =. А дальше, может и отпадет желание инкапсулировать эту возможность.
если по настоящему, то любую техническую систему можно спроектировать исходя из 3-х основных принципов:
- соответствует последнему стандарту
- наши деды так строили, незачем изобретать велосипед
- а не собрать ли нам по быстрому из гомна и палок, потом переделаем
)))
шучу, есть время почитать и покрутить в голове варианты, пользуюсь этим, как и возможностью получить быстро разъяснения на непонятные моменты на форуме ;)
Я вот пытаюсь понять смысл этого гемора с хранителем, но чё-то не вижу особой пользы. По сути это плохая практика программирования через создание сайд-эффектов. Когда меняя один объект, ты меняешь другой. В итоге код становится запутанным и труднопонимаемым. Лучше всё-таки стремится к чистоте кода, имхо.
Что мешает просто перекопировать объект в другой объект, а потом перекопировать обратно? По сути то же самое, только правильней и понятней.
Аналогично и с синглтоном. Если этот синглтон имеет одновременно и сеттеры, и геттеры (т.е. позволяет менять своё состояние и читать его), то это равносильно работе с глобальными переменными. При этом каждый программист знает, что работа через изменение глобального состояния - это зло. Но синглтон почему-то не в счёт )
Я так полагаю, это типичная точка зрения программиста, никогда не имевшего ничего общего с серьезными масштабными проектами? уж простите за прямоту, но другого объяснения называть плохой практикой основы основ не вижу )
В том, что кто-то изучает эти паттерны, ничего плохого, это замечательно - гимнастика для мозгов и т.д. и т.п. И вот, в итоге, при ближайшем их рассмотрении, оказывается, что это какой-то адский фэйк, какой-то мэм для оттяжки лохов от реальности, так же, как изучение визуал бэйсика через написание консольных приложений.
Изучен этих паттернов интересно, хотя бы с точки зрения изучения чьих-то тараканов - какие они бывают в природе.
А если по-настоящему подходить к задаче сохранения состояния объекта, то здесь путь через обеспечение возможности копирования одного объекта в другой, кому что нравится, просто ли через метод, или через перегрузку =. А дальше, может и отпадет желание инкапсулировать эту возможность.
Дмитрий, наверное в данном случае немного путаете задачи паттернов Хранитель и Прототип, и всех возможных их комбинаций и проявлений. Первый- Снимок не обязательно должен копировать весь объект, в отличие от Прототипа.
И да, потребность в инкапсуляции проявляется в основном на крупных проектах с кучей народа. Для таких игрушек типа большинства здешних задачек, излишество конечно)
1) Я вот пытаюсь понять смысл этого гемора с хранителем, но чё-то не вижу особой пользы.
2) По сути это плохая практика программирования через создание сайд-эффектов.
3) Когда меняя один объект, ты меняешь другой. В итоге код становится запутанным и труднопонимаемым. Лучше всё-таки стремится к чистоте кода, имхо.
4) Что мешает просто перекопировать объект в другой объект, а потом перекопировать обратно? По сути то же самое, только правильней и понятней.
Аналогично и с синглтоном. Если этот синглтон имеет одновременно и сеттеры, и геттеры (т.е. позволяет менять своё состояние и читать его), то это равносильно работе с глобальными переменными. При этом каждый программист знает, что работа через изменение глобального состояния - это зло. Но синглтон почему-то не в счёт )
Вы случайно не из секты "Интырнет они ставят, интырнет, он нам и на...й не нужОн, интырнет этот ваш..." ???
1. Хранитель, по дизайну похож на паттерн, который используют для хранения состояния при наборе с изменяемым содержимым для отката изменений, когда этих изменений не одно, а несколько сотен. Например редактор фото, текста...
Нашел после написания - https://refactoring.guru/ru/design-patterns/memento
2. По сути это плохая практика не зная и не разбираясь в теме, что-то там критиковать...
3. Как то, что и так вам непонятно может стать более запутанным и труднопонимаемым?
4. Дальше сами...