Разговоры на завалинке о ООП - страница 11
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да не может быть количество телодвижений при ООП меньше в принципе, так как все эти интерфейсы - это добавочные накладные расходы, которые часто превышают расходы на написание самой логики. И это при том, что интерфейс уже и так имеется у любой функции, то есть предлагается городить еще один огород, который по сути бессмысленен.
При этом значительно усложняется любое изменение кода как в интерфейсе так и в функции, так как одно зацеплено на другое, то есть имеем как минимум квадратичное увеличение возможного количества багов и трудоемкости... Вроде ведь очевидно.
Да не может быть количество телодвижений при ООП меньше в принципе, так как все эти интерфейсы - это добавочные накладные расходы, которые часто превышают расходы на написание самой логики. И это при том, что интерфейс уже и так имеется у любой функции, то есть предлагается городить еще один огород, который по сути бессмысленен.
При этом значительно усложняется любое изменение кода как в интерфейсе так и в функции, так как одно зацеплено на другое, то есть имеем как минимум квадратичное увеличение возможного количества багов и трудоемкости... Вроде ведь очевидно.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Разговоры на завалинке о ООП
fxsaber, 2018.01.14 11:35
Само программирование - это частный случай производства. ООП-подход - это принципиальный подход к производству чего угодно. Поэтому говорить о программировании - очень узко. ООП был успешно применен ДО появления его в программировании.
История становления промышленности пришла к объектно-ориентированному ПРОИЗВОДСТВУ, как к следующей ступени конвейеризации. Поэтому говорить об ОО-программировании - это узкий взгляд. Как говорить об ОО-пошиве сапог. Речь идет об алгоритмических подходах к организации любого производства, включая, как очень частный случай, создание софта.
ООП-производства доказали в конкурентной борьбе свое превосходство над обычными конвейерами. Есть краткосрочное планирование производства, когда надо, чтобы заработало сейчас. А есть долгосрочное - когда закладывают много "лишнего" в данный момент, но этот фундамент способствует простому масштабированию производства. Снова повторюсь, речь не о программировании, а об общих подходах при создании производства.
ООП-подходы прослеживаются даже в современных институтах власти.
Терминал - класс по отношению к вашему коду. Как часто у вас возникает потребность менять что-либо в коде терминала?
Пример некорректный. Мы говорим об интерфейсах внутри своей программы...
История становления промышленности пришла к объектно-ориентированному ПРОИЗВОДСТВУ, как к следующей ступени конвейеризации.
В ОО-программировании тоже есть свои конвееры обработки данных, а ООП вносит еще один уровень абстракции который лишь увеличивает накладные расходы каждого отдельного конвеера и всего производства.
В ОО-программировании тоже есть свои конвееры обработки данных, а ООП вносит еще один уровень абстракции который лишь увеличивает накладные расходы каждого отдельного конвеера и всего производства.
Вы тупой, к сожалению. Вам говорят про историю промышленности и про ООП, как один из этапов в этой истории, сыгравший огромную роль во всем материальном (и не только), что вокруг вас. А вы продолжаете талдычить про частный случай программирования.
Невежество в Истории развития человечества. Не оставите и следа в памяти своих прямых потомков.
Вам говорят про историю промышленности и про ООП, как один из этапов в этой истории, сыгравший огромную роль во всем материальном (и не только), что вокруг вас.
Ваша наивная попытка притянуть за уши ООП к истории промышленности забавна, но к сожалению малограмотна.
Пример некорректный. Мы говорим об интерфейсах внутри своей программы...
Почему же "некорректный" ?
Чем программа отличается от ВСЕГО ПО, работающего на компьютере ?
Ведь это - такой же ряд инструкций и массивы данных, как и в любой программе пользователя. Почему же некорректно - что тут, что там одна часть программного обеспечения не имеет доступа к другой части программного обеспечения иначе, кроме как через установленные протоколы обмена ?
Ничего страшного, если ты будешь программировать серьезно - рано или поздно сам придешь к необходимости разграничения прав доступа.
Мне тоже, еще во времена перехода с реального на защищенный режим очень не нравилось, что мне не доступен любой физический адрес памяти. Я даже занимался извратами с контроллером прямого доступа к памяти, который копировал данные из защищенной системной области в мою (правда, разобрать, что там скопировано - было весьма сложно, я и не стал). Я по молодости возмущался - как это так, я не имею прямого доступа - это ж чуть ли не ущемление моих прав... А уж в программе допустить, чтобы мне что-то было недоступно ???
Ничего, по мере накопления опыта я не раз убеждался, что разграничение прав доступа - это благо для самого программиста, поскольку это не раз меня спасало от внесения ошибок в написанные модули. Берешь класс, хочешь его использовать, а к некоторым данным у него нет доступа... Ты возмущен, да как же так, должен быть, начинаешь разбираться... и упс... там, оказывается, есть моменты, которые необходимо учитывать, и к данным нельзя обратиться напрямую, для этого есть "окольные пути", архитектура системы такая, что обратившись напрямую - я вполне могу получить невалидные данные. Хотя, могу и валидные - все зависит от момента времени. И такую ошибку будет вычислить очень сложно.
Вот, простейший вопрос - обращение к данным в кеше. Если тебе потребовались закешированные данные, и ты к ним обратишься прямо - уверен ли ты, что получишь верные данные ? В процедурном подходе без разграничения прав - тебе придется разбираться, когда можно обращаться, когда нельзя, когда данные валидны, когда нет... В ООП-подходе - все очень просто, у тебя просто нет доступа к данным кеша, ты можешь только вызвать функцию, которая тебе вернет нужные данные, попутно проверив, чтобы они были валидны, а если они невалидны - то подгрузит валидные. Разве это "сложнее" ??? А теперь еще представь, что ты этот кэш используешь через год после написания. Когда уже совсем забыл принципы обновления кеша и определения валидности. В ООП-подходе - тебя это не волнует. Функция класса тебе все предоставит. А в функциональном подходе - тебе придется вспоминать в деталях, когда и как обновляется кеш, когда данные в нем валидны, а когда нет.
Пример некорректный. Мы говорим об интерфейсах внутри своей программы...
Терминал - класс по отношению к вашему коду. Как часто у вас возникает потребность менять что-либо в коде терминала?, который от вас скрыт, и лишь предоставлены публичные методы - функции для реализации ваших программ.
+++ )))
Терминал - класс по отношению к вашему коду. Как часто у вас возникает потребность менять что-либо в коде терминала?, который от вас скрыт, и лишь предоставлены публичные методы - функции для реализации ваших программ.
Такая потребность возникает регулярно. Только желательно, чтобы этим занимались разработчики.
Простой пример. Для графиков индикаторов разработчики почему-то не сочли нужным предусмотреть горизонтальную координатную сетку. И, естественно, не предоставили для этого соответствующий методы.)