ООП vs процедурное программирование - страница 36
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
1. Ни насколько. Прибыльность не зависит от ООП.
2. На мой взгляд, на порядок (в десять раз). Но главный выигрыш от ООП - в поддержке кода. Сейчас я очень быстро разбираюсь в коде, который писал год и более назад. Хорошо помню, как я разбирался в своих ранних программах на ANSI С - в чисто процедурном стиле. Это было куда труднее.
1. Это главный ответ на необходимость ООП.
2. Это вопрос опыта работы в командах. Я написал все что нужно 2008-2009 году. Пару лет назад решил написать еще - все читается , никаких проблем.
Из Ваших ответов я понял одно: ООП - это некий стандарт, который внедряет дисциплину программирования, внедряет однообразие и на этом основании меньше ошибок изначально, а главное, и самое важное, принципиально уменьшаются проблемы при модификации. Но этот же результат получали при тщательном соблюдении ГОСТов, стадийности разработки, документированности.
Никак не могу понять, почему я в своей работе НИКОГДА ничего подобного не встречал. Откуда проблемы разграничения доступа к переменным у ОДНОГО разработчика в одной не очень большой программе? Было бы 100 разработчиков, каждый из которых писал бы по 100 функций. Теоретически можно было бы придумать. Но практически программирование почти 40 лет развивалось до ООП, написано горы кода и ни разу ничего подобного не слышал.
Дык вначале программы вобще писались в кодах.
ООП - это просто технология, позволяющая быстрее писать более сложные программы, и потом более эффективно их поддерживать.
Но, это не значит, что ООП - это прямо панацея от всех бед. Я ж говорю - если у тебя память, как у Петера - то тебе и даром ООП не надо - объявляй все глобально, и дело с концом, раз ты все это помнишь, и с легкостью не допустишь коллизий или спутывания переменных. Но, у меня память куда хуже. И разграничение - я использую очень даже широко. В последние годы - очень заценил модификатор const - раньше его редко использовал. Сейчас - часто. Как раз для того, чтобы мало того, чтобы у меня был доступ только к тому, что надо, и не больше. Так чтобы еще и этот доступ был read-only там, где он не предназначен для изменения.
George Merts:
Да, действительно, бывает такие ситуации, когда ВНЕЗАПНО выясняется, что получить необходимые данные - практически невозможно. Они скрыты за несколькими виртуальными интерфейсами. Однако, такая ситуация ясно показывает, что система изначально была неправильно спроектирована, в ней не предусматривалась передача этих данных. Такая ситуация - действительно, очень неприятна. Приходится либо на скорую руку лепить "костыли" в виде дополнительных интерфейсов, либо вобще реструктурировать всю систему. Ну... это мотивирует программиста к более тщательному продумыванию архитектуры системы.
Если программист - пророк и ясновидящий, видящий наперед и во всех деталях необходимую структуру данных для всех возможных вариантов реализации основной идеи, то тогда наверно ему имеет смысл действовать по вашему пути. Либо делать это на заключительном этапе когда все уже работает и код отлажен без применения этих надстроек, но опять же при условии что ничего потом менять и перекраивать никогда не потребуется...
1. Это главный ответ на необходимость ООП.
2. Это вопрос опыта работы в командах. Я написал все что нужно 2008-2009 году. Пару лет назад решил написать еще - все читается , никаких проблем.
Из Ваших ответов я понял одно: ООП - это некий стандарт, который внедряет дисциплину программирования, внедряет однообразие и на этом основании меньше ошибок изначально, а главное, и самое важное, принципиально уменьшаются проблемы при модификации. Но этот же результат получали при тщательном соблюдении ГОСТов, стадийности разработки, документированности.
1. Ну нет. ООП - это не инструмент, обеспечивающий прибыльность. И говорить о необходимости ООП, глядя на прибыльность - нельзя. ООП - это инструмент упрощения разработки и поддержки кода.
2. Это круто, когда ТС десятилетней давности - по-прежнему работают. Мне так не жить, у меня они регулярно перестают работать, мне постоянно приходится их модифицировать. И ООП - в этом мне очень помогает.
И насчет ООП-некий стандарт, да, все верно. И верно то, что такой же результат можно получить при соблюдении стадийности и документированности. Но, как мне кажется, усилий при этом затрачивается больше, чем в случае ООП.
Дык вначале программы вобще писались в кодах.
ООП - это просто технология, позволяющая быстрее писать более сложные программы, и потом более эффективно их поддерживать.
Но, это не значит, что ООП - это прямо панацея от всех бед. Я ж говорю - если у тебя память, как у Петера - то тебе и даром ООП не надо - объявляй все глобально, и дело с концом, раз ты все это помнишь, и с легкостью не допустишь коллизий или спутывания переменных. Но, у меня память куда хуже. И разграничение - я использую очень даже широко. В последние годы - очень заценил модификатор const - раньше его редко использовал. Сейчас - часто. Как раз для того, чтобы мало того, чтобы у меня был доступ только к тому, что надо, и не больше. Так чтобы еще и этот доступ был read-only там, где он не предназначен для изменения.
Дык вначале программы вобще писались в кодах.
Не будем передергивать, хорошо?
ООП - это просто технология, позволяющая быстрее писать более сложные программы, и потом более эффективно их поддерживать.
Вот это сомнительно и очень.
Быстрее пишутся и эффективно поддерживаются программы, имеющие хорошую проектную документацию. Отголоски этой проблемы можно найти в маркете, где очень много внимания уделяется ТЕХНИЧЕСКОМУ ЗАДАНИЮ. Если ТЗ паршивое, то никакой ООП не поможет.
Быстрее пишутся и эффективно поддерживаются программы, имеющие хорошую проектную документацию. Отголоски этой проблемы можно найти в маркете, где очень много внимания уделяется ТЕХНИЧЕСКОМУ ЗАДАНИЮ. Если ТЗ паршивое, то никакой ООП не поможет.
Если программист - пророк и ясновидящий, видящий наперед и во всех деталях необходимую структуру данных для всех возможных вариантов реализации основной идеи, то тогда наверно ему имеет смысл действовать по вашему пути. Либо делать это на заключительном этапе когда все уже работает и код отлажен без применения этих надстроек, но опять же при условии что ничего потом менять и перекраивать никогда не потребуется...
ООП - это просто технология, позволяющая быстрее писать более сложные программы, и потом более эффективно их поддерживать.
Как было объяснено выше, ООП изначально не предназначено для быстрого написания и отладки кода из-за множества добавочных оберток, промежуточных надстроек и переходников... Оно имеет смысл только на заключительном этапе когда все уже работает и отлажено и структура данных приобрела законченный вид... То есть это сугубо косметическая процедура по упаковке готового кода для последующего хранения...
Но мне важнее другое - выше правильно сказал Игорь - каждый класс отвечает только за свои переменные, из него невозможно "влезть" в чужие. В результате чего, большая часть проблем отсекается на стадии компиляции.
У класса есть только внутренние переменные и нет входных и выходных... Где вы видели применение в программировании такого объекта, который никак не контактирует с внешним миром и варится в собственном соку?
.... Современным программам документация практически не нужна - все как на ладони представлено в интерфейсах класса.
Метаквотам объясните это: зачем это они написали огромные руководства по терминалу, по языку и вообще откуда это горы документации на программные продукты например на Срр.. И вообще, бывают ли программные продукты без документации? Очень странно, что этого Вы не замечаете.