То что все современные системы используют ООП это не доказательство превосходства ? Вы просто пока не готовы понять, вы задаете простые вопросы и не можете воспринять сложный ответ.. и считаете что ответа нет.. Ну это не правильно..
То что мышление меняется это да, и по началу кажется а ради чего? А вот когда проект становится много тысяч строк кода, то начинаешь пожинать плоды )) и понимать зачем и ради чего все это было)
Если проект поддерживать и обновлять, расширять сложно и дорого, а другой быстро и просто, то первый умрет - это естественный отбор
В моей программе тоже много тысяч строк кода. Отсутствие лишних сущностей для меня спасение. Я бы не смог все развивать иначе. Это чистейшая практика.
1. То что все современные системы используют ООП это не доказательство превосходства ?
2. Вы просто пока не готовы понять, вы задаете простые вопросы и не можете воспринять сложный ответ.. и считаете что ответа нет.. Ну это не правильно..
То что мышление меняется это да, и по началу кажется а ради чего? А вот когда проект становится много тысяч строк кода, то начинаешь пожинать плоды )) и понимать зачем и ради чего все это было)
Если проект поддерживать и обновлять, расширять сложно и дорого, а другой быстро и просто, то первый умрет - это естественный отбор
1. Тут все такие крутые, что для них это не будет доказательством, а наоборот подтверждением, что они все такие крутые из себя, а все вокруг лохи печальные - повелись на ООП.
То что вы не доверяете другим и хотите понять сами - это даже хорошо, другие могут ошибаться, до некоторых вещей проще самому дойти
Dmitry Fedoseev:
1. Тут все такие крутые, что для них это не будет доказательством, а наоборот подтверждением, что они все такие крутые из себя, умеют, а все вокруг лохи печальные - повелись на ООП.
2. Очень анекдотично, но они этого не осознают.
))) анекдотично бывает когда люди которые много чего не понимают продают в маркете советники за 10к $ или сигналы с 2к подписчиками и гребут не по детски бабло )
Ну нету в процедурном программировании аналога полиморфизма.
Как это нет, если вы сами несколькими страницами ранее упоминали об указателях на функции? Это самый что ни на есть аналог полиморфизма, причём с гораздо более широкими возможностями, ибо его можно менять динамически.
Как это нет, если вы сами несколькими страницами ранее упоминали об указателях на функции? Это самый что ни на есть аналог полиморфизма, причём с гораздо более широкими возможностями, ибо его можно менять динамически.
Это было вчера, пока у меня было более хорошее мнение об оппозиции. Указатели на функции в MQL недавно появились, сегодня же выяснилось, что для всех спорщиков их все равно что нет вообще. Выяснилось что, они вообще не понимают о чем спорят. Наверняка слова "полиморфизм" и "указатели" они просто мимо глаз и ушей пропускали. У них один аргумент - "вы не привели доказательств", хоть им тут 1000 доказательств вывали.
Динамически и указатели на классы можно менять, с функциями проще только то, что их не надо предварительно создавать.
Под эффективностью решений я подразумеваю то качество решения, при котором механизм (а программа это несомненно механизм), будет работать наиболее стабильно. Механизм должен быть четким, слаженным и производительным. Функционал механизма должен реализовывать все возлагаемые на него задачи. Механизм не приемлет лишнего, и в развитии этого механизма, лишнее должно быть отсечено.
Только в вашем случае этим "лишним" является контроль типов и прочие фундаментальные вещи, призванные обезопасить код от случайных ошибок при программировании. Поэтому ваш код становится очень ненадёжным. Ни о какой стабильности говорить не приходится. Пусть сейчас вы его отладили и вылизали, но при последующих модификациях будут появляться трудноуловимые ошибки, которые очень тяжело разгребать.
То, что ООП содержит массу дополнительных инструментов которые может использовать разработчик - бесспорно. Однако, надо понимать какую цену нужно платить за использование этих инструментов. А именно - полное погружение в ООП парадигму и соответствующее ей структурирование кода. Использование полного инструментария ООП и создание множества обьектов. Главная цена - в резком усложнении кода. Однако, практика показывает, что с точки зрения эффективности создаваемых механизмов они должны быть просты и присутствие в них любых сущностей должно быть абсолютно обоснованно повышением КПД и ничем более.
Только в вашем случае этим "лишним" является контроль типов и прочие фундаментальные вещи, призванные обезопасить код от случайных ошибок при программировании. Поэтому ваш код становится очень ненадёжным. Ни о какой стабильности говорить не приходится. Пусть сейчас вы его отладили и вылизали, но при последующих модификациях будут появляться трудноуловимые ошибки, которые очень тяжело разгребать.
Возможно. Посмотрим. Пока таких трудностей еще не было.
То что все современные системы используют ООП это не доказательство превосходства ? Вы просто пока не готовы понять, вы задаете простые вопросы и не можете воспринять сложный ответ.. и считаете что ответа нет.. Ну это не правильно..
То что мышление меняется это да, и по началу кажется а ради чего? А вот когда проект становится много тысяч строк кода, то начинаешь пожинать плоды )) и понимать зачем и ради чего все это было)
Если проект поддерживать и обновлять, расширять сложно и дорого, а другой быстро и просто, то первый умрет - это естественный отбор
В моей программе тоже много тысяч строк кода. Отсутствие лишних сущностей для меня спасение. Я бы не смог все развивать иначе. Это чистейшая практика.
Но хватит об этом. Я ухожу из этой темы.
1. То что все современные системы используют ООП это не доказательство превосходства ?
2. Вы просто пока не готовы понять, вы задаете простые вопросы и не можете воспринять сложный ответ.. и считаете что ответа нет.. Ну это не правильно..
То что мышление меняется это да, и по началу кажется а ради чего? А вот когда проект становится много тысяч строк кода, то начинаешь пожинать плоды )) и понимать зачем и ради чего все это было)
Если проект поддерживать и обновлять, расширять сложно и дорого, а другой быстро и просто, то первый умрет - это естественный отбор
1. Тут все такие крутые, что для них это не будет доказательством, а наоборот подтверждением, что они все такие крутые из себя, а все вокруг лохи печальные - повелись на ООП.
2. Очень анекдотично, но они этого не осознают.
Аналогично к этой теме )) Очень давно выписывал журнал Популярная Механика, там была страничка юмора
Как-то Лев вышел на тропу войны. Ну идет такой весь блатуха. Встречает лису. Лиса, нука быстро, кто у нас царь зверей?
- Лева, ну конечно ты!
Довольный, пошел дальше
Встретил зайца, тот же резалт
Встретил слона. А слону было жарко, он просто махнул хоботом от мух и лев улетел в труляля.
И знаете, друганы, что он сказал уходящему слону, сидя в кустах?
- А и нефиг злится, если ответов не знаешь ))
Про ежика:
Стоит ежи на полянке, позирует, бицепсы напрягает: - я сильный, я смелый, я ловкий, я сильный, я смелый, я ловкий...
Мимо шел медведь - раз ему пинка, ежик улетел за елку, встает от отряхивается:
- Я сильный, я смелый, я ловкий... но лёёёёгкий...
Но хватит об этом. Я ухожу из этой темы.
То что вы не доверяете другим и хотите понять сами - это даже хорошо, другие могут ошибаться, до некоторых вещей проще самому дойти
1. Тут все такие крутые, что для них это не будет доказательством, а наоборот подтверждением, что они все такие крутые из себя, умеют, а все вокруг лохи печальные - повелись на ООП.
2. Очень анекдотично, но они этого не осознают.
))) анекдотично бывает когда люди которые много чего не понимают продают в маркете советники за 10к $ или сигналы с 2к подписчиками и гребут не по детски бабло )
Не этот аргумент главный.
Ну нету в процедурном программировании аналога полиморфизма.
Как это нет, если вы сами несколькими страницами ранее упоминали об указателях на функции? Это самый что ни на есть аналог полиморфизма, причём с гораздо более широкими возможностями, ибо его можно менять динамически.
во простыню растянули :-) видать соскучились по холивар`ам , модеры позажимали флеймовые темы...а тут вдруг ООП vs не-ООП
кстати 99% что @Реter Konow использует ООП, только он об этом незнает :-) ООП это не обязательно "class & template"
и наоборот кстати тоже..наличие в программе объектов и классов не свидетельствует об ООП
Как это нет, если вы сами несколькими страницами ранее упоминали об указателях на функции? Это самый что ни на есть аналог полиморфизма, причём с гораздо более широкими возможностями, ибо его можно менять динамически.
Это было вчера, пока у меня было более хорошее мнение об оппозиции. Указатели на функции в MQL недавно появились, сегодня же выяснилось, что для всех спорщиков их все равно что нет вообще. Выяснилось что, они вообще не понимают о чем спорят. Наверняка слова "полиморфизм" и "указатели" они просто мимо глаз и ушей пропускали. У них один аргумент - "вы не привели доказательств", хоть им тут 1000 доказательств вывали.
Динамически и указатели на классы можно менять, с функциями проще только то, что их не надо предварительно создавать.
Под эффективностью решений я подразумеваю то качество решения, при котором механизм (а программа это несомненно механизм), будет работать наиболее стабильно. Механизм должен быть четким, слаженным и производительным. Функционал механизма должен реализовывать все возлагаемые на него задачи. Механизм не приемлет лишнего, и в развитии этого механизма, лишнее должно быть отсечено.
Только в вашем случае этим "лишним" является контроль типов и прочие фундаментальные вещи, призванные обезопасить код от случайных ошибок при программировании. Поэтому ваш код становится очень ненадёжным. Ни о какой стабильности говорить не приходится. Пусть сейчас вы его отладили и вылизали, но при последующих модификациях будут появляться трудноуловимые ошибки, которые очень тяжело разгребать.
То, что ООП содержит массу дополнительных инструментов которые может использовать разработчик - бесспорно. Однако, надо понимать какую цену нужно платить за использование этих инструментов. А именно - полное погружение в ООП парадигму и соответствующее ей структурирование кода. Использование полного инструментария ООП и создание множества обьектов. Главная цена - в резком усложнении кода. Однако, практика показывает, что с точки зрения эффективности создаваемых механизмов они должны быть просты и присутствие в них любых сущностей должно быть абсолютно обоснованно повышением КПД и ничем более.
Только в вашем случае этим "лишним" является контроль типов и прочие фундаментальные вещи, призванные обезопасить код от случайных ошибок при программировании. Поэтому ваш код становится очень ненадёжным. Ни о какой стабильности говорить не приходится. Пусть сейчас вы его отладили и вылизали, но при последующих модификациях будут появляться трудноуловимые ошибки, которые очень тяжело разгребать.