Как помочь студентке по инфо-тематике? - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Та можно, почему нет?)
Я написал вопросы, на которые сам не могу пока что найти ответ, так как я еше не очень далеко продвинулся в C#. За исключением третьего вопроса, который легко гуглится, он просто для количества. Если кто из знатоков напишет свою точку зрения - буду благодарен.
Вот примитивный пример (на MQL4 - первое, что под руку попалось). Класс принимает в конструкторе координаты точек линии и с помощью метода valueOn() можно получить ее цену на любом баре.
Прикол в том, что все поля константны....
А как быть, если потребуется изменить эту линию?
Как мне кажется, в данном случае константные члены класса неразумны. Я вобще чаще всего константные члены класса делаю ещё и статическими. В данном случае - статичные члены не подходят, в случае двух линий возникнет ошибка с их инициализацией.
Спецификатор константы, на мой взгляд, предназначен для того, чтобы ограничить пользователя там, где алгоритмом не предусмотрено изменение. Однако, в данном классе, по-моему, изменение должно быть доступно. Как минимум, для того, чтобы при изменениях - использовать уже существующую линию, а не создавать новую.
Ну и в качестве своего видения прямой и использования спецификатора const - прикрепляю свой класс CPlaneStraight - Прямая на плоскости.
На шарпе процедурно писать нельзя, это вполне известный факт.)) Там все только через ООП.)) В принципе, поэтому я не стал продолжать его изучать.. Не понравилось принуждение майкрософта.))
Ну почему же нельзя? Делаем один класс и все свои процедуры и функции делаем методами этого класса, а глобальные переменные - полями этого класса. Так что от ООП там можно использовать не сильно больше, чем заклинание функции main() в C/C++.
Редко встреваю в такие ветки, но меня порадовало такое известие, что есть еще посты от ветеранов этого форума. Не буду перечислять. Они себя знают.) Печально, что все реже и реже они появляются.
Все заняты бизнесом.?
Всегда считал, что надо деверсифицировать способы дохода. Фора штука выгодная, но переменчивая, как погода у нас в Питере. Например, я предложил подруге в НГ подработать Дед Морозом и Снегурочкой. По возрастам мы как раз годимся для ролей. Ну, а детишек веселить я умею ))
Ну почему же нельзя? Делаем один класс и все свои процедуры и функции делаем методами этого класса, а глобальные переменные - полями этого класса. Так что от ООП там можно использовать не сильно больше, чем заклинание функции main() в C/C++.
Если пишем исключительно для себя на срок использования 5 минут, такой подход допустим. Если для заказчика, то всегда найдется кадр, который начнет менять эти публичные глобальные переменные с непредсказуемыми эффектами. Лучше не лениться и делать геттеры/сеттеры с проверками на вшивость.
Если пишем исключительно для себя на срок использования 5 минут, такой подход допустим. Если для заказчика, то всегда найдется кадр, который начнет менять эти публичные глобальные переменные с непредсказуемыми эффектами. Лучше не лениться и делать геттеры/сеттеры с проверками на вшивость.
Да ты сам же их и начнёшь через некоторое время менять! Со всеми этими непредсказуемыми эффектами!
Это я ещё на заре своего занятия С++ хорошо усвоил. Скажем, написал неплохой класс, который понадобился через полгода. Берёшь его, а уже не помнишь некоторые неявные условия, в которых этот класс работал. И они не всегда описаны в комментариях (я обычно стараюсь все подобные вещи обязательно комментировать, но как правило, через полгода выясняется, что некоторые-таки, описал недостаточно чётко, а то и вовсе не описал). Ну, меняешь их по своему теперешнему усмотрению... а оно - бац! - и начинает тебе портить работу в других местах, и ты только потом ВНЕЗАПНО вспоминаешь эти неявные моменты. Всё это весьма неприятно.
В тоже время, если все переменные protected (private не люблю, потом в наследниках до них тяжело добираться) - то на входе, при установках - я считаю за хороший тон проверять диапазоны переменных, как минимум, на ASSERT(), а то и с возвращением кода ошибки, когда уж совсем неверный параметр. И это снимает большинство ошибок.
Когда к такому коду возвращаешься через полгода, и пытаешься менять нужные тебе переменные - то они "не меняются", все эти ASSERT'ы или коды ошибок возвращаются, и ты сперва даже не понимаешь - что за фигня! Почему здесь нельзя изменить, когда надо?!! Но, это тебя уже предупреждает о том, что где-то есть некие неучтённые тобой факторы, начинаешь разбираться, и довольно быстро обнаруживаешь... ага... если здесь изменить переменную так, как тебе хочется - вот, в другом месте это будет неожиданно, здесь надо дополнительная обработка.
В общем, глобальные переменные - это весьма опасные объекты, которые, конечно, иногда необходимы, но, от которых всеми силами надо уходить.
Скажем, в моих экспертах глобальный объект один (кроме входных переменных-настроек, которые по-другому не сделаешь, и то, если настройки запрашиваются из БД, то и их тоже не надо делать глобальными) - CExpert, который в шаблонном файле обрабатывает все стандартные функции событий, и уже внутри себя вызывает все рабочие классы ТС.
По-моему, это хорошо и правильно.
Если пишем исключительно для себя на срок использования 5 минут, такой подход допустим.