Чему лучше учиться? Процедурному или объектно-ориентированному программированию?

Question

[xverizex]

Знаю си. И мне нравиться писать на нём. Вообще не вижу смысла в объектно-ориентированном программировании. Но может вы меня сможете переубедить. Вообще что написать программу, хватит и процедурного кода. Но я восхищаюсь вроде тому, что кто-то знает все паттерны и не только и может грамотно составить сверх совершенный код. Я так отношусь к c++, что на нём можно писать сверхразумный код. Я знаю немного c++, ну основы и немного паттернов. Но книга по паттернам оказалась не очень хорошей. Например в ней есть паттерн builder, и он плохо описан в книге. В java намного лучше сделан, ну типа такого.

Figure span = Builder.get_app("frozen").add_picture("...").commit();

Да и вакансий много на c++ обычно или на java, для android. Я также знаю java но не очень хорошо. То есть в принципе я могу и для android писать. Но в android разработке применяется ооп и паттерны. Их может быть и не очень сложно заучить и пользоваться ими удобно и они логично построены. Блин класс ооп. Но очень много софта написано на си. Большие программы написаны на си. И они написаны без паттернов. Ну в некоторых есть паттерны, например gobject вроде. Я хотел бы чтобы вы написали плюсы и минусы процедурного и объектно-ориентированного программирования. Пожалуйста! Заранее спасибо.

Comments

[Дмитрий]

Внутри классов и методов те же функции и процедурный код, просто обёртка, плюс структура. Не знаю чего вы там не понимаете, если уже пробовали ява

Answer 1

[skrimafonolog]

Сначала процедурному, потом объекто-ориентированному.
Вы напрасно считаете эти вещи какими-то сверхсложными.
Легко выучить их все.

Answer 2

[mr-troll]

Как писал Джоел Спольски 10 лет назад

В начале девяностых многие из нас полагали, что главная битва произойдет между процедурным и объектно-ориентированным стилем программирования, и воспринимали объектно-ориентированное программирование как средство резкого повышения продуктивности программистов. Я тоже так думал. Некоторые до сих пор так думают. Получается, мы ошибались. Объектно-ориентированное программирование прикольная штука, но не повышает продуктивность, как это обещалось. Реальное и значительное повышение производительности мы получили от программирования на языках, автоматически управляющих памятью вместо вас. Это может быть подсчет ссылок или «сборка мусора», это может быть Java, Lisp, Visual Basic (даже 1.0), Smalltalk или любой язык написания скриптов. Если ваш язык программирования позволяет выделять кусок памяти без раздумий о его последующем освобождении, то вы используете язык с управляемой памятью, и вы будете значительно эффективней программиста, использующего язык, где управление памятью производится в явном виде. Всякий раз, когда вы слышите чье-то хвастовство о том, насколько продуктивен их язык, вероятно, большую часть продуктивности они достигают за счет автоматического управления памятью, даже если не признаются в этом.

Сейчас процедурный стиль преподносят как модное "функциональное программирование". Я работал во многих конторах, и, ооп используется в меньшинстве проектов (если даже отмести языки без нормального ооп, типа перл и питона).
Объект - стоит использовать если у вас есть набор данных и методов для работы с ними. Если у вас просто объект представляет массив функции для работы с внешними данными, например объект математических функций (пример Math в Js) или объект/класс функций для работы с бд - это не ооп. Если ваша единственная цель например отделить логику от представления, или сгуппировать всё в объект как в модуль или в неймспейс, то это тоже не ооп. Есть ряд вещей в которых ооп полезно, но нет ничего того что вы не сможете сделать в функциональном стиле.

Answer 3

[xmoonlight]

ООП: хранение состояния объектов, контроль и управление структурой кода приложения.
Функции/процедуры: удобны только тогда, когда нужен лишь результат вычисления.
И то, и то - нужно применять грамотно: вместе или что-то одно в зависимости от решаемой задачи!

Answer 4

[Александр Скуснов]

Смысл в ООП есть, потому что надо идти дальше:
1) функциональный стиль. Советую посмотреть курсы на Степике по Haskell
2) графический стиль для автоматики:
контроллеры - CFC, SFC;
управляющая логика (аналог SFC) - StateFlow

Answer 5

[Даниил Демидко]

Лучше учитесь мультипарадигменному, зачем ограничивать себя?