Мой подход. Ядро - Движок. - страница 18
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
нет, пока про казуальное программирование идет обсуждение, это я все к ООП одеяло перетягиваю, топикстартер пока держится! пишет, что все можно в голове держать - ну казуально программировать )))
Ядро-движок
казуально программировать )))
Kэжуал программирование :)
Kэжуал программирование :)
возможно Вы правы, вспомнил такой термин - пару месяцев назад на другом форуме чел так себя назвал: казуальный программист, я даже пытался уточнить что это может значить, из моих познаний слово казуальный ассоциируется только с игрой для Андроида - "Зума", оказалось, что это видите ли программист который программирует как попало - от случая к случаю )))
ООП очень гибкая методология, поэтому в нем нет каких-либо априорных идей вроде понятия "ядра". Однако с помощью ООП очень хорошо можно построить модель ядра, о которой здесь ведется речь. Поэтому утверждение не совсем корректное.
Нет, тут ООП вообще ни о чем. Ядро - это Unix, все собираем вокруг ядра; оболочка - все, что похоже на Windows,- что лишнее, то убираем, с остатком работаем. Вообще, это - об операционке.
Kэжуал программирование :)
Кажуал, не переживай.
Меня в ООП отталкивает жесткий формат написания кода. Как Вы видели, я склонен составлять большие таблицы данных и считаю это очень практичным. В ООП мне придется придерживаться кучи правил, которые лично меня очень сковывают.
Короче, я программирую с другим ООП. Своим. Там мало правил и много свободы. Функционал сам складывается в большие блоки, а данные организуются в ядрах. Я даже специально не продумываю их структуру. Все само развивается. На интуитивном уровне.Петер, эти правила - тебе же самому и требуются. Именно для того, чтобы они тебя "сковывали". Чтобы ты ничего случайно не испортил, и не влез куда-нибудь так, как не предполагалось. Фактически, ООП-стиль - это "правила движения" - конечно, они ограничивают водителя. И в деревне с тремя дворами - на них никто не смотрит, так получается проще и быстрее (эффективнее). Однако, в крупном городе все наоборот - именно ПДД дают возможность наиболее эффективного транспортного сообщения. Так и с ООП. Это правила, которые позволяют строить большие комплексные системы наиболее эффективно.
В твоей системе - просто пока еще не происходило изменений, она используется очень ограниченно, и не требует модификаций. Именно потому ты и можешь держать ее в голове. Ничего, если у системы появятся пользователи, и потребуются доработки - отсутствие контроля и инкапсуляции - будет весьма напряжно.
Все остальное - разницы нет, ООП и твой стиль (как уже говорилось, у тебя и процедурный стиль - также страдает теми же недостатками - глобальными переменными, отсутствием контроля типов, и прочим) в остальном близки.
В защиту своего стиля тебе требуется доказать единственное - что содержать всю систему в огромном глобальном массиве с произвольным доступом - лучше, чем разбивать программу на кучу мелких частей, вложенных в цепочки наследования с полиморфным доступом, и скрываемых с помощью инкапсуляции.
Кстати, на форуме есть народ, которому наследование не нравится - они, думаю, тебя могут и поддержать.
Еще одно преимущество использования ООП в отличии от метода Петра. В ООП программисту не нужен исходный код базового класса и не надо разбираться как он работает. Для того что бы расширить или изменить функционал базового класса достаточно создать наследник этого класса.
Если использовать метод Петра то программисту понадобится разбираться во всей длинной портянке кода, а если исходника этого кода нет, то его нужно будет писать заново.
Все остальное - разницы нет, ООП и твой стиль (как уже говорилось, у тебя и процедурный стиль - также страдает теми же недостатками - глобальными переменными, отсутствием контроля типов, и прочим) в остальном близки.
я конечно могу и ошибаться, да и гуглить лень, но процедурный стиль подразумевают логическую законченность процедуры (функции)- "выдернул" из исходника и используй в другом коде, т.е. как встроенные ф-ции MQL принимают в качестве параметров данные и возвращают результат.... и тут у Петра все хромает на обе лапы ))) - обмен через глобально описанные переменные снижает портируемость кода и допускает появление трудно отслеживаемых багов ;)
Хорошо. Допустим меня убедили.
В принципе, я все это понимаю уже давно. И я согласен с этим. Однако, при этом, я предпочитаю свой подход. Почему?
Есть одна конкретная причина:
РАЗВИТИЕ ПРОГРАММЫ.
//---------------------------------------
Насколько стремительно будет развиваться программа с ООП и с моим подходом? Какой подход более благоприятный для роста и усложнения механизмов?
Я сделал вывод, что мой подход + родной язык в коде(60% русский и 40% английский), дают максимально стремительный рост программы.
Именно этот стремительный рост мне и нужен. Не копание в деталях. Не зависание над каждой строчкой кода. Не профессиональный подход.
Мне было нужно, чтобы программа быстро развивалась, усложнялась. Чтобы создавались механизмы, реализующие возложенные на них функции. Быстро и легко.
Чтобы несколькими строчками кода можно было добавлять новые возможности.
Мой подход превосходит ООП в решении этой конкретной задачи.