@xverizex

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

Знаю си. И мне нравиться писать на нём. Вообще не вижу смысла в объектно-ориентированном программировании. Но может вы меня сможете переубедить. Вообще что написать программу, хватит и процедурного кода. Но я восхищаюсь вроде тому, что кто-то знает все паттерны и не только и может грамотно составить сверх совершенный код. Я так отношусь к c++, что на нём можно писать сверхразумный код. Я знаю немного c++, ну основы и немного паттернов. Но книга по паттернам оказалась не очень хорошей. Например в ней есть паттерн builder, и он плохо описан в книге. В java намного лучше сделан, ну типа такого.
Figure span = Builder.get_app("frozen").add_picture("...").commit();

Да и вакансий много на c++ обычно или на java, для android. Я также знаю java но не очень хорошо. То есть в принципе я могу и для android писать. Но в android разработке применяется ооп и паттерны. Их может быть и не очень сложно заучить и пользоваться ими удобно и они логично построены. Блин класс ооп. Но очень много софта написано на си. Большие программы написаны на си. И они написаны без паттернов. Ну в некоторых есть паттерны, например gobject вроде. Я хотел бы чтобы вы написали плюсы и минусы процедурного и объектно-ориентированного программирования. Пожалуйста! Заранее спасибо.
  • Вопрос задан
  • 1586 просмотров
Решения вопроса 2
@skrimafonolog
Сначала процедурному, потом объекто-ориентированному.
Вы напрасно считаете эти вещи какими-то сверхсложными.
Легко выучить их все.
Ответ написан
Комментировать
@mr-troll
Как писал Джоел Спольски 10 лет назад
В начале девяностых многие из нас полагали, что главная битва произойдет между процедурным и объектно-ориентированным стилем программирования, и воспринимали объектно-ориентированное программирование как средство резкого повышения продуктивности программистов. Я тоже так думал. Некоторые до сих пор так думают. Получается, мы ошибались. Объектно-ориентированное программирование прикольная штука, но не повышает продуктивность, как это обещалось. Реальное и значительное повышение производительности мы получили от программирования на языках, автоматически управляющих памятью вместо вас. Это может быть подсчет ссылок или «сборка мусора», это может быть Java, Lisp, Visual Basic (даже 1.0), Smalltalk или любой язык написания скриптов. Если ваш язык программирования позволяет выделять кусок памяти без раздумий о его последующем освобождении, то вы используете язык с управляемой памятью, и вы будете значительно эффективней программиста, использующего язык, где управление памятью производится в явном виде. Всякий раз, когда вы слышите чье-то хвастовство о том, насколько продуктивен их язык, вероятно, большую часть продуктивности они достигают за счет автоматического управления памятью, даже если не признаются в этом.


Сейчас процедурный стиль преподносят как модное "функциональное программирование". Я работал во многих конторах, и, ооп используется в меньшинстве проектов (если даже отмести языки без нормального ооп, типа перл и питона).
Объект - стоит использовать если у вас есть набор данных и методов для работы с ними. Если у вас просто объект представляет массив функции для работы с внешними данными, например объект математических функций (пример Math в Js) или объект/класс функций для работы с бд - это не ооп. Если ваша единственная цель например отделить логику от представления, или сгуппировать всё в объект как в модуль или в неймспейс, то это тоже не ооп. Есть ряд вещей в которых ооп полезно, но нет ничего того что вы не сможете сделать в функциональном стиле.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 3
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
ООП: хранение состояния объектов, контроль и управление структурой кода приложения.
Функции/процедуры: удобны только тогда, когда нужен лишь результат вычисления.
И то, и то - нужно применять грамотно: вместе или что-то одно в зависимости от решаемой задачи!
Ответ написан
Комментировать
@AlexSku
не буду отвечать из-за модератора
Смысл в ООП есть, потому что надо идти дальше:
1) функциональный стиль. Советую посмотреть курсы на Степике по Haskell
2) графический стиль для автоматики:
контроллеры - CFC, SFC;
управляющая логика (аналог SFC) - StateFlow
Ответ написан
Комментировать
DanielDemidko
@DanielDemidko
Программист
Лучше учитесь мультипарадигменному, зачем ограничивать себя?
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы