Разговоры на завалинке о ООП - страница 19

[---]

Волчанский, а запилите себе еще холиварную тему "Нужен ли goto?"

[Alexey Volchanskiy]

Andrei:
Verilog

Ну-у-у это вы хватанули )) Он же для разработки электронных схем.

[Alexey Volchanskiy]

o_o:

Волчанский, а запилите себе еще холиварную тему "Нужен ли goto?"

Я правильно понимаю, что у вас негативные эмоции? Почему?

[fxsaber]

Комбинатор:

Какая разница?

Вам надо аргументировать свое утверждение (ООП ацтой) -- заходите в гугл, вбиваете "ООП" и пару негативных качеств, берете статью потоповей и не читая закидываете на форум.

Правда или не правда - неважно. Относится или не относится - неважно. Если найдутся внимательные типа вас, которые потрудятся ее прочитать и проверить, можно так же другую статью кинуть.

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

Как результат, наверное, нужно проводить социологическое (или психологическое) исследование, по какой причине развиваются устойчивые почти агрессивные и упорные неприятия каких-либо вещей у части общества (у индивида).

[Alexey Volchanskiy]

George Merts:

Дык и меня бабы не любят... И еще многих...  Обычное дело, Алексей, животные они все, не каждому удается их дрессировать, так что завистников у тебя будет много.

Но ты лучше расскажи - это ж где твой такой курс ? Я тоже погляжу...

Да тебе он не нужен, в личку скинул

[TheXpert]

fxsaber:

Серьезный минус ООП заключается в том, что что-то сложное сложно проектировать, т.е. сделать архитектуру которая отлично эффективно работает и стыкуется между собой без костылей очень сложно, поэтому собственно практика рефакторинга очень и очень распространена. Чем меньше опыта в проектировании, тем больший ад можно наворотить. Дело в том, что зачастую структура нормально спроектированной объектной модели в ООП имеет мало общего с реальными объектами (как мы их представляем)

Далее уже зависит от поддержки определенных парадигм определенными языками, чтобы можно было говорить о "хороший\плохой", "применим\неприменим"

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

[Koldun Zloy]

fxsaber:

Статья врет!

Когда прочел это высказывание, очень сильно засомневался. Накатал быстро, чтобы проверить, что у меня в голове не каша:

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

Статья не врёт. Там виртуальные функции, поэтому всё работает так, как пишет автор.

Но, надеюсь, Вы не считаете это серьёзным аргументом против ООП.

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

[fxsaber]

Koldun Zloy:

Статья не врёт. Там виртуальные функции, поэтому всё работает так, как пишет автор.

Но, надеюсь, Вы не считаете это серьёзным аргументом против ООП.

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

Если виртуальная, то все логично и автор просто некомпетентен в вопросах и задачах виртуальных функций.

Более того, если бы ему нужно было получить независимость, то надо было сделать так

virtual void Array::addAll( const int &elements[] )
{
  for (int i = 0; i < ArraySize(elements); i++)
//      this.a.add(elements[i]);
    Array::add(elements[i]);
}

Но для новичков сам пример нахожу хорошим. Нужно понимать, что делаешь.

[fxsaber]

Комбинатор:

Серьезный минус ООП заключается в том, что что-то сложное сложно проектировать, т.е. сделать архитектуру которая отлично эффективно работает и стыкуется между собой без костылей очень сложно, поэтому собственно практика рефакторинга очень и очень распространена. Чем меньше опыта в проектировании, тем больший ад можно наворотить. Дело в том, что зачастую структура нормально спроектированной объектной модели в ООП имеет мало общего с реальными объектами (как мы их представляем)

Далее уже зависит от поддержки определенных парадигм определенными языками, чтобы можно было говорить о "хороший\плохой", "применим\неприменим"

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

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

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

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

[Andrei01]

Alexey Volchanskiy:

Ну-у-у это вы хватанули )) Он же для разработки электронных схем.

Не только.