ООП vs процедурное программирование - страница 9
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я то понятно почему не понимаю, это не мой код, к тому же это только часть. Но, похоже Вы тоже не понимаете, - или я не прав?
Я не использую указатели...
Ранее я так же работал как и Вы только функциями, но со временем их нужно было как то хранить потом искать перепроверять, каждая функция делала свои лишние действия.
Сейчас я все пересобрал в классы и при вызове класса Order получаю все что мне нужно и список доступных функций методов...
Поэтому я люблю делать большие универсальные блоки кода.
Даже не вериться автор неплохого GUI без ООП
Экономия строк кода?!
Нет Ваш пример очень хорош.
Дело не в процедурном программировании.
Есть гораздо более важный критерий качества программы: наглядность кода.
Приведенное Вами решение ужасно: совершенно не понятно КАКАЯ содержательно функция вызывается. Я бы написал обычный свитч и против каждого вызова комментарий. Это правильный код.
Из Вашего примера я делаю вывод, что ООП штука вредная.
А зачем switch на 100 вариантов, если заранее известно, что использоваться будет только 1?
В чем наглядность портянки из 100 вариантного switch, по сравнению с тремя строками кода?
Делать сложно, объемно и тормознуто то, что можно сделать рационально, оптимально (даже идеально) - это не правильный подход.
ООП вреден только при неправильном его использовании.
Среагируйте вот на этот коммент.
Поэтому я люблю делать большие универсальные блоки кода.
От чего они становятся универсальными?
А зачем switch на 100 вариантов, если заранее известно, что использоваться будет только 1?
В чем наглядность портянки из 100 вариантного switch, по сравнению с тремя строками кода?
Делать сложно, объемно и тормознуто то, что можно сделать рационально, оптимально (даже идеально) - это не правильный подход.
Среагируйте вот на этот коммент
Это не портянка - это документация на функционал программы совмещенный с текстом программы. Это самое важное, а не то что будет работать один
Я не использую указатели...
Ранее я так же работал как и Вы только функциями, но со временем их нужно было как то хранить потом искать перепроверять, каждая функция делала свои лишние действия.
Сейчас я все пересобрал в классы и при вызове класса Order получаю все что мне нужно и список доступных функций методов...
Это не портянка - это документация на функционал программы совмещенный с текстом программы. Это самое важное, а не то что будет работать один
И портянка и балласт. Мухи должны быть отдельно, котлеты отдельно. Документация важна, но она не должна мешать работать программе.
От чего они становятся универсальными?
Ну например - нужен блок, который позиционирует графические объекты относительно друг друга создавая элементы управления. Вместе с этим, этот же блок управляет явлением объектов, - то есть прячет одни и являет другие. Также он подсчитывает размеры полотна прокрутки и общие размеры окна. Также расчитывает движение ползунка в полосе прокрутки. Вот это и есть универсальный блок взаимосвязей объектов.
Или блок который управляет размерами окна при ухвате за ручку окна. Или блок который управляет состояниями элементов управления. Или блок который расчитывает на каком элементе находится курсор и одновременно ставит в фокус множество глобальных параметров...
Ну например - нужен блок, который позиционирует графические объекты относительно друг друга создавая элементы управления. Вместе с этим, этот же блок управляет явлением объектов, - то есть прячет одни и являет другие. Также он подсчитывает размеры полотна прокрутки и общие размеры окна. Также расчитывает движение ползунка в полосе прокрутки. Вот это и есть универсальный блок взаимосвязей объектов.
Но это же реализуется через if и switch?
Но это же реализуется через if и switch?