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