LINUX.ORG.RU

ООП - большой пузырь?

 


1

2

Доброго времени! По Вашему мнению, имеет ли смысл возня вокруг ООП? Все чаще ловлю себя на мысли, просматривая сорцы какого нибудь фреймворка, что всё слишком усложнено и виной этому ООП, скорее даже виной этому являются авторы кода, которые слишком глубоко упёрлись в программирование ради программирования. Код сложен, много слоёв абстракций, сложные иерархии наследования, примеси... Кажется все это существует чтобы просто усложнить процесс разработки и получать больше денег, больше занятости, имитировать деятельность. Не кажется ли вам, что просто Си или какой нибудь Го, проще для разработки реального кода в краткие сроки, вместо просиживания штанов за построением архитекторы ООП кода? Говорю с колокольни давнего ООПшника, который от этого дерьма подустал. Хоть в админство иди...


Не кажется ли вам, что просто Си или какой нибудь Го, проще для разработки реального кода в краткие сроки

Проще подключиться к чему-то уже почти готовому, это да. А с нуля на Си что-то разрабатывать... Ну попробуй, удачи тебе в хождении по граблям.

anonymous
()

Опять эта простыня г*вна, как вы уже надоели. Каждый день? подобный трэд, давайте что-нибудь новое.

FIL ★★★★
()
Ответ на: комментарий от anonymous

Никто не говорит про «с нуля», библиотек хватает вроде.

n0044h
() автор топика
Ответ на: комментарий от FIL

Эм.. Я не в курсе, что часто вопрос поднимают?

n0044h
() автор топика

Ответ в ФП стиле: Мая. Твая. Понимать. Соглашаться.

Ответ в ООП стиле: Я Вас прекрасно понимаю. И польностью согласен с Вашим мнением. Но, хочу заметить, очень часто без ООП никуда. Т.е. все же необходим симбиоз ФП и ООП. Но на деле чаще проявляется «ООП головного мозга».

deep-purple ★★★★★
()

Не кажется. Напиши парочку систем по ляму строк кода, которые после этого миниум пяток лет работали и чтоб тебя никто не хотел убить за неподдерживаемый говнокод - тогда я тебя внимательно выслушаю.

Deleted
()
Ответ на: комментарий от beastie

не сократится, я копался в коде который пишут чудаки не осилившие ООП, нужна лопата, противогаз и дохрена терпения.

зы. и диавол кроется «в 5 лет проработала», большая система за это время будет дописывать по требованиям заказчика и вот тогда то кривая архитектура и даст о себе знать

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от beastie

выражаю мои искренние соболезнования - мне всегда хватало нормальной навигации по исходному коду

Deleted
()
Ответ на: комментарий от Deleted

Все чаще я вижу большие системы, красивые архитектурно, но они полурабочие, т.к. слишком сложны для понимания происходящих в них процессов. Код красив, архитектура элегантная... А работает криво, а как починить знает только ниндзя-разраб, который уже потерял интерес к этому коду и ушел. Денег на разработку вбухали кучу и чтобы просто это работало вбухивают еще кучи.

n0044h
() автор топика
Ответ на: комментарий от bookman900

Дата регистрации + стиль повествования + история сообщений. Это не анонiмус, незачем иметь мозги адекватным регистрантам.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Deleted

Будь душкой — повикси мне баг в Thunderbird. Можешь поискать в моих постах тут. Прошло лет 5, баг всё ещё не пофикшен. И в частности всё от того, что в ООП чёрт ногу сломит.

beastie ★★★★★
()

Код сложен, много слоёв абстракций, сложные иерархии наследования, примеси...

Не, ну я бы согласился, если бы ты ниже не привел язычки, где средств для построения абстракций с гулькин хер. То есть ты хочешь вылечить перхоть отрубанием головы. Удачи, чо.

anonymous
()
Ответ на: комментарий от Deleted

выражаю мои искренние соболезнования - мне всегда хватало нормальной навигации по исходному коду

Ты же в курсе, что сейчас беседуешь с чуваком, который кодит в виме без подсветки синтаксиса? Юзает ли он хотя бы ctags - это вопрос.

anonymous
()
Ответ на: комментарий от anonymous

А вот да, не кажется ли тебе что все эти вспомогалочки в IDE это костыли ради быстрой навигации в ООП помойке? (только не придирайся к слову помойка, это образно, литературно)

deep-purple ★★★★★
()
Ответ на: комментарий от anonymous

Нужны ли такие абстракции? Я не знаю, может я тупой конечно, но мне напряжно загружать в мозг архитектуру ООП кода, которую автор навелосипедил (паттерны не панацея, т.к. в основном про них ребята знают из сказок). Мне кажется, что круче когда в системе каждая программа а делает свою работу и точка, клеит это все шелл, а сами составляющие системы по большей части очень простые и пишутся без ООП, но опираясь на другие составляющие системы и на библиотеки, по необходимости. Возможно я придумал юникс-вей какой то, но что то в этом есть к.м.к

n0044h
() автор топика
Ответ на: комментарий от beastie

Подозреваю, что если избавиться от кандалов ООП, лям строк кода сократится так на порядок или два или три.

Вот ни разу такого не видел ещё. Зато мульёны спагетти и копипасты от неосиляторов ООП сколько угодно.

anonymous
()
Ответ на: комментарий от anonymous

А я вот видел — рутины лопатили структуры и прочие массивы, и никаких тебе паттернов, интерфейсов, объектов и методов, геттеров, сеттеров, никакой инкапсуляции кроме скоупа. Вот выкинь перечисленное, код и похудеет.

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

Интересно! Где такое видел? Хочу взглянуть.

n0044h
() автор топика

Не кажется ли вам, что просто Си или какой нибудь Го, проще для разработки реального кода в краткие сроки, вместо просиживания штанов за построением архитекторы ООП кода?

Не кажется.

Deleted
()
Ответ на: комментарий от n0044h

Может быть, не стоит сравнивать устройство одной программы и устройство системы целиком? Или ты хочешь, чтобы у тебя подпрограммы друг друга через шелл вызывали? За такими абстрактными псевдорассуждениями теряется куча деталей, и на словах всё начинает выглядеть красиво и прекрасно. А по факту — чем будут обмениваться твои эти утилиты, вызываемые через шелл? Как они будут организованы? Начиная с какого-то момента ты заметишь, что у тебя есть N форматов данных, для работы с каждым из которых есть M утилит. Привет, ООП.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от n0044h

Нужны ли такие абстракции?

Конечно нужны. Модули, дженерики (для статики), замыкания - это необходимый минимум. А потом ты очень быстро упрешься в то, что объекты таки нужны. Так лучше иметь сразу их из коробки, чем долбаться потом с несовместимыми уродскими неполноценными поделиями типа GObject. Короче, проблема не в языках, а в переусложненных системах. Связать себе руки и заставить писать в блокноте на сишке - это так себе выход.

anonymous
()
Ответ на: комментарий от deep-purple

не кажется ли тебе что все эти вспомогалочки в IDE это костыли ради быстрой навигации в ООП помойке?

Да! Настоящие программисты изучают распечатанный листинг, только так.

anonymous
()

Хоть в админство иди...

Точно. Пошел вон из профессии, неосилятор

anonymous
()
Ответ на: комментарий от deep-purple

Вот выкинь перечисленное, код и похудеет.

На порядок? Это что же за такой адский бойлерплейт должен быть в языке? И потом, это справедливо возможно для каких-то простейших задач, но при малейшем усложнении (элементарно прикрутить GUI, например), этот ваш процедурный код взбухает как на дрожжах.

anonymous
()

Как-то так получается, что в больших проектах на том же C возникает ООП. В том числе в свободных проектах, где имитировать деятельность немного некстати.

Почему, как думаешь?

anonymous
()
Ответ на: комментарий от anonymous

Как-то так получается, что в больших проектах на том же C возникает ООП. В том числе в свободных проектах, где имитировать деятельность немного некстати.

++

kravich ★★★★
()
Ответ на: комментарий от anonymous

Как-то так получается, что в больших проектах на том же C возникает ООП.

Потому что нет модульности и замыканий. Хотя если считать ООП


struct {
  int x,y;
} A;

struct {
  struct A parent;
  int z;
} B;

на основании того, что указатель на B можно передавать вместо указателя на А, тогда, конечно ООП необходимо для единообразной работы с разными объектами.
monk ★★★★★
()

Хоть в админство иди...

Лучше сразу в дворники, там мозг просто ложишь на получку и отдыхаешь душой. Подчищать дерьмо из физической реальности проще, чем дерьмо из субъективной реальности.

просматривая сорцы какого нибудь фреймворка что всё слишком усложнено и виной этому ООП

ООП тут не причем, причем рукожопые индусы усложняющие там, где можно было сделать проще. Сам был таким, только лет через 10 понял, как нужно правильно, да и то не уверен еще.

Не кажется ли вам, что просто Си или какой нибудь Го, проще для разработки реального кода

Го тот же ООП with blackjack and hookers. А на Си ты так или иначе выродишь ООП, при разработке сложного проекта.

foror ★★★★★
()

что всё слишком усложнено

А может ты просто недостаточно умный?

no-such-file ★★★★★
()

Долгое время, примерно 4 года, занимаюсь тем, что пописываю на PHP, JS в кач-ве фрилансера. В основном в роли удалённого сотрудника в различных компаниях, интернет-магазинах.

Слезай с этого дерьмеца, изучай С++/Java/Python/Ruby, пробуй устроиться в контору по приличней и возможно будешь спасен. Хотя с Java лучше не надо, 95% попадешь на ынтырпрайзно-индуское-говнецо и будешь потерян для профессии.

foror ★★★★★
()

еще один всё понял

anonymous
()
Ответ на: комментарий от intelfx

Ты сам туп, анонимусы истинные хозяева LORa

anonymous
()
Ответ на: комментарий от anonymous

Не, ну я бы согласился, если бы ты ниже не привел язычки, где средств для построения абстракций с гулькин хер

В Go нормально: интерфейсы для того, что обычно делают классами с наследованием, подходят лучше. Классы с наследованием были плохо подобранными словами для предметной области.

Joe_Bishop
()
Последнее исправление: Joe_Bishop (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.