Вопросы по ООП в MQL5 - страница 55
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вы застряли в мелочах. Неинтересно. Основной смысл обсуждения здесь паттерна "хранитель" был в том, что он типа обещает сохранения инкапсуляции, но реализуется путем создания для каждого поля по паре публичных методов. Забавно, что самый главный мессадж вы не уловили.
Я не застрял, я пытаюсь из уважения к вам как к собеседнику найти смысл в ваших словах и распутать ваши самопротиворечия. Видимо зря.
Ваша пена про "святые паттерны" думаю тоже здесь никому неинтересна.
Здесь все четко, конкретно и по канону. Существует КНИГА! В этой КНИГЕ изложены эти паттерны, вот собственно о них и разговор. Называется книга "Паттерны проектирования" или типа того. Но не только книга, в интернете много сайтов про них и даже в википедии есть, главное, что тема канонизирована)) ...и тот кто не шарит в паттернах - плебей, а кто овладел ими - тот овладел самой жизнью! Аминь!
Вы уподобляетесь клоуну, увы. Просто уйдите из ветки про ООП, если вам так противно это)
Здесь все четко, конкретно и по канону. Существует КНИГА! В этой КНИГЕ изложены эти паттерны, вот собственно о них и разговор. Называется книга "Паттерны проектирования" или типа того. Но не только книга, в интернете много сайтов про них и даже в википедии есть, главное, что тема канонизирована))
Все конечно хорошо, если глобальных переменных до 100 то можно обойтись без функций, если советников больше 50 то классы уместны, и правильно понимаю, если разрабов более 20, методов более 20 и количество переменных неизвестно, то тогда паттерн нужен. Если разраб один, то если и нужен, то не сильно?
Я не застрял, я пытаюсь из уважения к вам как к собеседнику найти смысл в ваших словах и распутать ваши самопротиворечия. Видимо зря.
Ваша пена про "святые паттерны" думаю тоже здесь никому неинтересна.
У меня нет противоречий, противоречие есть в ваших паттернах, уже два раза писал про них, напоминаю: паттерн "хранитель" обещает сохранение инкапсуляции, а реализуется через создание по два публичных метода на каждое приватное поле.
И расскажите, где у меня вы увидели противоречия?
Все конечно хорошо, если глобальных переменных до 100 то можно обойтись без функций, если советников больше 50 то классы уместны, и правильно понимаю, если разрабов более 20, методов более 20 и количество переменных неизвестно, то тогда паттерн нужен. Если разраб один, то если и нужен, то не сильно?
В первую очередь разработчикам мозги нужны.
Вы уподобляетесь клоуну, увы. Просто уйдите из ветки про ООП, если вам так противно это)
Что "это"? ООП мне нравится. Но эти пресловутые паттерны довольно отдаленное отношение имеют к реальному ООП.
У меня нет противоречий, противоречие есть в ваших паттернах, уже два раза писал про них, напоминают: паттерн "хранитель" обещает сохранение инкапсуляции, а реализуется через создание по два публичных метода на каждое приватное поле.
Теперь я понял. Вы просто полили эмоциями против всех паттернов, что смысл ваших слов потерялся.
Но в Снимке эта проблема решается использованием вложенных классов для снимка.
Если это не поддерживается языком, то согласен, недостаток этот есть, но его кстати можно обойти некоторыми костыле-ухищрениями помнится.
Теперь я понял. Вы просто полили эмоциями против всех паттернов, что смысл ваших слов потерялся.
Но в Снимке эта проблема решается использованием вложенных классов для снимка.
Если это не поддерживается языком, то согласен, недостаток этот есть, но его кстати можно обойти некоторыми костыле-ухищрениями помнится.
Да ничего вы не поняли.
Наличие или отсутствие возможности писать вложенный класс не имеет значения, не велика разница. В этой теме как раз есть пример кода с вложенным классом и двумя публичными методами на приватное поле.
Что "это"? ООП мне нравится. Но эти пресловутые паттерны довольно отдаленное отношение имеют к реальному ООП.
Вот ещё раз повторю - никто же не молиться на паттерны. Это просто шаблоны от которых можно отталкиваться.
Но утверждать что они не имеют отношение к ООП - ну это неправда.
По моему скромному опыту - в чистом книжном виде, они мало применяются за редким исключением. Обычно если стоит задача подходящая под паттерн, то она идёт вкупе минимум с парой других задач под другие паттерны, и вот как 2-3-10+ паттернов скрестить, это уже и есть работа для мозга программиста/архитектора.
Да ничего вы не поняли.
Наличие или отсутствие возможности писать вложенный класс не имеет значения, не велика разница. В этой теме как раз есть пример кода с вложенным классом и двумя публичными методами на приватное поле.
Вы уже столько раз мне сказали, что я дурак и ничего не понимаю, что я горжусь своей выдержкой, что давно не послал вас заслуженно нахер)
По сути - вложенный класс делает необязательным публичные методы для приватных полей, именно про это нарушение инкапсуляции вы пишете. Какие то ещё аргументы?