ООП vs процедурное программирование - страница 13
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А что подразумевается под эффективностью решений?
Под эффективностью решений я подразумеваю то качество решения, при котором механизм (а программа это несомненно механизм), будет работать наиболее стабильно. Механизм должен быть четким, слаженным и производительным. Функционал механизма должен реализовывать все возлагаемые на него задачи. Механизм не приемлет лишнего, и в развитии этого механизма, лишнее должно быть отсечено.
Иначе, либо не будет развития, либо не будет эффективности.
ЗЫ. это только мое мнение, и я его никому не навязываю.
Я не фанат ООП.
Но в плане сопровождения, масштабируемости и простоты использования третьими лицами то что задвигает ТС (Петер, не Карпутов) это просто каменный век.
Имею стойкое мнение, что каждый программист должен поработать в команде, в идеале больше 4 человек, просто чтобы понять что эффективность и универсальность кода еще не означает что этот код хороший.
Не хочу создавать здесь холивар, но интересно, могут ли сторонники ООП предоставить сюда код решающий какую либо задачу, где наглядно видно, что это решение более эффективно, чем решение без ООП?
Я мастер решать задачи без ООП и хотелось бы сразиться с мастером решения задач с ООП.
Попробую вам объяснить, допустим вы исполнитель и у вас есть заказчик, который постоянно подкидывает работенку.. И тут через 5-6 заказов вы замечаете, что все его задачи в некотором смысле однотипные.. И что можно их объединить в шаблон.. А еще заказчик любит совмещать эти шаблоны друг с другом в большом количестве.. С точки зрения ООП нужно создать шаблон, в котором будет находится результат(который рассчитается внутри класса), и потом когда заказчик вновь подкинет сложную работенку, вам нужно будет всего лишь создать нужное число экземпляров(допустим 10) этого шаблона(класса) и каждому из них задать те свойства(в конструкторе) которые взбрели в голову заказчику... В итоге решение по открытию ордера будет просто на основании цикла, который посмотрит результат в каждом из 10 экземпляров и все.. Вы сможете клепать такие заказы за 5 минут..
А без ООП экземпляр сделать не получится и нужно будет почти все переделывать, при этом надеясь что изменения не поломают то что есть.. в итоге будет затрачено куда больше времени,..
Вывод: программист который владеет ООП сможет решать задачи(которые подходят для ООП) гораздо быстрее и с куда меньшими ошибками..
Попробую вам объяснить, допустим вы исполнитель и у вас есть заказчик, который постоянно подкидывает работенку.. И тут через 5-6 заказов вы замечаете что все его задачи в некотором смысле однотипные.. И что можно их объединить в шаблон.. А еще заказчик любит совмещать эти шаблоны друг с другом в большом количестве.. С точки зрения ООП нужно создать шаблон в котором будет находится результат(который рассчитается внутри класса), и потом когда заказчик вновь подкинет сложную работенку вам нужно будет всего лишь создать нужное число экземпляров(допустим 10) этого шаблона(класса) и каждому из них задать те свойства(в конструкторе) которые взбрели в голову заказчику... В итоге решение по открытию ордера будет просто на основании цикла который посмотрит результат в каждом из 10 экземпляров и все.. Вы сможете клепать такие заказы за 5 минут..
А без ООП экземпляр сделать не получится и нужно будет почти все переделывать, при этом надеясь что изменения не поломают то что есть.. в итоге будет затрачено куда больше времени,..
Вывод: программист который владеет ООП сможет решать задачи(которые подходят для ООП) гораздо быстрее и с куда меньшими ошибками..
Возможно, Вы правы. Я никогда не выполнял заказы и не знаю, чего хотят заказчики. То, что Вы описываете, больше похоже на рутинную работу, а я здесь рассуждаю именно о разработке. Вероятно, для рутинной работы (которая к тому же ведется коммандой), ООП просто незаменим. У меня нет такого опыта и я просто не знаю.
А Вы можете привести конкретный пример этих однотипных задач, которые без ООП лучше не делать?
Я не фанат ООП.
Но в плане сопровождения, масштабируемости и простоты использования третьими лицами то что задвигает ТС (Петер, не Карпутов) это просто каменный век.
Имею стойкое мнение, что каждый программист должен поработать в команде, в идеале больше 4 человек, просто чтобы понять что эффективность и универсальность кода еще не означает что этот код хороший.
О-о, работа в команде это вообще отдельная песня! А руководить командой программистов - это песня в степени, равной числу участников.
Расскажу байку под субботний вечер. Про времена, когда наша фирма окучивала железку. Если повтор, извиняюсь, мог уже когда-то травануть историю.
Вызывает меня шеф, спрашивает, - ты по работе сильно занят? Говорю, - не очень.
-А чем ты вообще занимаешься сейчас? Шеф никогда не знал, чем я занимаюсь, так как я выбил себе личный график, в который входили постоянные прогулы ))
Говорю, да вот, нашим наладчикам пишу пакет тестов для нашего оборудования. Шеф такой обрадовался, - здорово, как раз и испытаешь это в условиях Сибири. Алексей, ну надо слетать, что-то там ребята застряли, не могут разобраться. Ну надо так надо, я вообще любил командировки, полная свобода.
Прилетаю в Красноярск, меня ребята встречают, смотрю, как-то ведут себя виновато, явно мнутся. Идем в кафе, выпили, разговорились. Спрашиваю, что у вас не получается? Шеф там уже в недоумениях, вы третий месяц в командировке и застряли на одной точке. Он только вам деньги успевает отсылать переводами.
Ну они и вскрылись. Доехали до сибирской деревушки, остановились на постой, а там две сестры молоденькие. Ну и закрутилась любовь, подруг еще привлекли, чтобы никто не был обиженным.
Говорю, я вас не сдам, сам такой же. Но надо двигаться дальше в темпе. Давайте так, настраиваем всю венку, всего-то фигня осталась, километров 500, потом я вас премирую, выцыганиваю у шефа баблосы и вы с этими подругами справляете НГ, идет?
Сейчас женщины будут негодовать, но первым согласился Леха, говорит, у меня жена должна родить, я лучше тут перекантуюсь! Все были женатые и ни один почему-то не стал рваться на родину )))
Зато я тогда нутром понял, как могут пахать парни, когда впереди их ждут молодые, красивые сибирячки ))
Спор вообще не о чём.
Любую задачу можно решить как с ООП так и без него. Без ООП также можно спокойно создавать унифицированные функции которые и использоваться будут многократно и вся программа не будет ломаться из-за вносимых в неё изменений. С ООП немного больше кода. Улучшается ли читабельность из-за использования ООП ? хз.
У меня что каждый класс храниться в отдельном файле, что каждая функция также в отдельном файле. Просто вопрос привычки и удобства.
Еще самый простой пример, который на самой поверхности лежит.. Генератор советников в метаэдиторе... Любой кто даже не умеет программировать может за 10 секунд склепать советник состоящий из огромного числа индикаторов и условий ))) А все это ООП ))
Спор вообще не о чём.
Любую задачу можно решить как с ООП так и без него. Без ООП также можно спокойно создавать унифицированные функции которые и использоваться будут многократно и вся программа не будет ломаться из-за вносимых в неё изменений. С ООП немного больше кода. Улучшается ли читабельность из-за использования ООП ? хз.
У меня что каждый класс храниться в отдельном файле, что каждая функция также в отдельном файле. Просто вопрос привычки и удобства.
Здесь в этой теме был пример задачи, которая без ООП решается, но очень не рационально.
Спор вообще не о чём.
Любую задачу можно решить как с ООП так и без него. Без ООП также можно спокойно создавать унифицированные функции которые и использоваться будут многократно и вся программа не будет ломаться из-за вносимых в неё изменений. С ООП немного больше кода. Улучшается ли читабельность из-за использования ООП ? хз.
У меня что каждый класс храниться в отдельном файле, что каждая функция также в отдельном файле. Просто вопрос привычки и удобства.
Я могу сказать абсолютно уверенно, что в личной разработке ООП мне не нужен, но у меня нет полной уверенности в отношении работы комманды над большим проектом. Развитие и связь кода созданного различными программистами мною никогда не продумывалась и я не знаю, как бы реализовал это по своему. Это единственный аргумент в пользу ООП в разработке, который я сейчас принимаю.
Не этот аргумент главный.
Ну нету в процедурном программировании аналога полиморфизма.