Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Флейм > Есть ли недостатки у ООП ?


Автор: iipetrov 21.5.2013, 13:33
Есть ли какие-то недостатки у ООП ? 
Бывает ли, что задача плохо ложится на ООП ? Обязательно ли тем не менее решать ее в рамках парадигмы ООП ? 
Является ли признаком плохого программиста написание программ без использования ООП (или с частичным использованием ООП) ?

Автор: Фантом 21.5.2013, 13:47
Цитата(iipetrov @  21.5.2013,  14:33 Найти цитируемый пост)
Есть ли какие-то недостатки у ООП ? 

Да.

Цитата(iipetrov @  21.5.2013,  14:33 Найти цитируемый пост)
Бывает ли, что задача плохо ложится на ООП ?

Да. 

Цитата(iipetrov @  21.5.2013,  14:33 Найти цитируемый пост)
Обязательно ли тем не менее решать ее в рамках парадигмы ООП ? 

Нет.

Цитата(iipetrov @  21.5.2013,  14:33 Найти цитируемый пост)
Является ли признаком плохого программиста написание программ без использования ООП (или с частичным использованием ООП) ? 

Нет.

Автор: Arantir 21.5.2013, 15:26
А теперь расширенная версия:  smile 

Цитата(iipetrov @  21.5.2013,  12:33 Найти цитируемый пост)
Есть ли какие-то недостатки у ООП ? 

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

Цитата(iipetrov @  21.5.2013,  12:33 Найти цитируемый пост)
Бывает ли, что задача плохо ложится на ООП ?

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

Цитата(iipetrov @  21.5.2013,  12:33 Найти цитируемый пост)
Обязательно ли тем не менее решать ее в рамках парадигмы ООП ? 

Задачу из прошлой цитаты решать с помощью ООП не обязательно и не желательно.

Цитата(iipetrov @  21.5.2013,  12:33 Найти цитируемый пост)
Является ли признаком плохого программиста написание программ без использования ООП (или с частичным использованием ООП) ? 

Признаком хорошего программиста является написание программ самым верным путем — простым, быстрым, эффективным. А как именно — дело мастерства. 
Но в любом случае стоит заметить, что программирование — сфера широкая и важную роль играет прикладная область. Как было замечено, есть задачи, решаемые не с помощью ООП. Если прикладная область состоит почти полностью из таких задач, то знание ООП малозначимо.

Автор: Alexeis 21.5.2013, 17:11
  Параллельные задачи плохо ложатся на ООП. ООП требует, чтобы состояние объекта менялось скачкообразно при возникновении событий. Если более одного потока "терроризируют" объект, синхронизация доступа может сильно усложнить реализацию, замедлить доступ и приводить к различного рода гонкам и дедлокам. Объекты плохо описывают быстро (непрерывно меняющиеся процессы) , потому как код пишут исходя из предположения, что состояние объекта на определенном участке остается неизменным. Если это не так, то требуется блокировка состояния объекта. Блокировка же объекта может привести к тому, что он перестает отражать актуальное состояние того что он описывает, что в свою очередь может повлечь непредсказуемые последствия ( система занималась бесполезной работой, в то время как пропущено важное событие ). 
  Грубо говоря ООП хорошо работает с гладкими функциями, когда малое возмущение входов порождает малое возмущение на выходах.
  Пример инертности состояния. Пусть есть 3 зависимых объекта объекта A,B,C. состояние объекта в момент времени i обозначим малой буквой. Например ai, а предыдущее состояние ai-1 . xi - входной возмущающий параметр.
Определим зависимости таким образом. 
ai=A(xi,ai-1)
bi=B(ai,bi-1)
ci=C(ai,bi,ci-1)
---------------------------
итерация №1 - x1
Вычисляется состояние объекта А . a1=A(x1,a0) . Состояния B и С неизменные
От объекта А зависят 2 объекта В и С. Генерятся 2 события. 1е для B и 2е для C
---------------------------
итерация №2
Вычисляется состояние одного из объектов B или C
1)Пусть вычисляется сначала B
b2=B(a1,b0) - b1==b0, генерится событие для С (поскольку изменился B)
Объект С остался неизменным с0

2)Пусть вычисляется сначала С
с2=С(a1,b0,c0) с1==с0
Объект B остался неизменным b0
-----------------------------

итерация №3
1) вычисляется событие B->C
c3=C(a1,b2,c0)  или C(A(x1,a0), B(A(x1,a0), b0), c0) 
2) вычисляется событие A->B, затем B->C
b3=B(a1,b0) , b3==b2 - результат как в 1й ветке
с3=С(a1, b2, c2) или C(A(x1,a0), B(A(x1,a0), b0), С(A(x1,a0), b0, c0)) 
------------------------------------

Итого имеем в зависимости от порядка вычисления событий два разных состояния с3
C(A(x1,a0), B(A(x1,a0), b0), c0)  и C(A(x1,a0), B(A(x1,a0), b0), С(A(x1,a0), b0, c0))

На ровном месте получили состояние гонки.  Добиться однозначности можно лишь наложив блокировку на объект С. А теперь, если рассмотреть общий случай, что состояние входа x может меняться на каждой итерации, то для достижения правильного результата потребуется одновременно блокировка и B и С, что приводит в конечном итоге к тому параллельно это вообще не исполниться smile .

  Решение этой задачи через функции будет очевидно проще и быстрее.

Автор: krundetz 22.5.2013, 10:58
 smile 

серебряной пули не существует

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)