Что-то нетак с ООП
От: Artifact  
Дата: 18.01.12 11:20
Оценка: 21 (3) +9 -1 :))) :))
Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием. С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности ООП. Складывается впечатление, что ООП это такой хорошо замаскированный современный GOTO. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться классы. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?
__________________________________
Не ври себе.
Re: Что-то нетак с ООП
От: HrorH  
Дата: 18.01.12 11:37
Оценка: 11 (3) +10 -6 :))) :))) :))) :))) :))
Здравствуйте, Artifact, Вы писали:

Что-то не так с ФП.

Почему так получается, что когда код представляет из себя набор функций, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке (ленивые вычисления). И это даже при отсутствии злоупотребления монадами. С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности ФП. Складывается впечатление, что ФП это такой хорошо замаскированный современный GOTO. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться функции. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?
Re: Что-то нетак с ООП
От: supacrazypusher  
Дата: 18.01.12 11:56
Оценка:
Здравствуйте, Artifact, Вы писали:

A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания.


Профит в том, что повышается переиспользование кода и снижается необходимость вникания в код для использования.
Re[2]: Что-то нетак с ООП
От: Artifact  
Дата: 18.01.12 12:03
Оценка: +2 :))) :))
Здравствуйте, supacrazypusher, Вы писали:

S>Профит в том, что повышается переиспользование кода и снижается необходимость вникания в код для использования.


К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.
__________________________________
Не ври себе.
Re: Что-то нетак с ООП
От: Son of Northern Darkness  
Дата: 18.01.12 12:13
Оценка:
Здравствуйте, Artifact, Вы писали:

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


Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально.
Вот за этим ООП и нужно.
Re[2]: Что-то нетак с ООП
От: HrorH  
Дата: 18.01.12 12:13
Оценка:
Здравствуйте, HrorH, Вы писали:

Что бы хотелось иметь в идеале?
1) Техническое задание
2) Фазу проектирования, в процессе которой появляется математическая модель, описывающая поведение программы.
3) Код в котором понятно, какую задачу он решает и в котором несущественные мелочи не мешают читать.
4) Доказательство соответствия кода математической модели.
5) Фаза оптимизации, в которой из неэффективной реализации математической модели получается эффективная.

В общем хочется чего-то в духе "Denotational design with type class morphisms" Conal Elliott.
Re: Что-то нетак с ООП
От: LaptevVV Россия  
Дата: 18.01.12 12:15
Оценка: 1 (1) +3 -4 :))) :)
Здравствуйте, Artifact, Вы писали:

A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием. С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности ООП. Складывается впечатление, что ООП это такой хорошо замаскированный современный GOTO. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться классы. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?

1. Вообще-то классы должны появляться не потому, что они классы. Этому должен предшествовать не хилый анализ предметной области.
2. Объем задачи, для которой нужно применять ООП, должен быть достаточно велик. Ну, ИМХО от 50000 строк примерно. Иначе просто нерентабельно применять мощнячий инструмент для относительно несложной задачи.
Однако некоторые языки (Додиез и Ява, например) программу сразу считают неким классом. И тут легко скатиться от ясных и понятных процессов в полную неразбериху объектов... Инструмент как бы провоцирует...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Что-то нетак с ООП
От: supacrazypusher  
Дата: 18.01.12 12:16
Оценка: +5 -1 :)
Здравствуйте, Artifact, Вы писали:

A>К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.


Для этого нужно нормально проектировать систему и управление зависимостями в ней. Если архитектура ужасная, модульности не и в помине и не делаются попытки улучшить ситуацию, то, боюсь, тут уже неважно ФП, ООП или брэйнфак.
Re: Что-то нетак с ООП
От: Sharov Россия  
Дата: 18.01.12 12:17
Оценка:
Здравствуйте, Artifact, Вы писали:

>И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться классы. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?


И при чем здесь ООП, когда проблема в людях.
Кодом людям нужно помогать!
Re: Что-то нетак с ООП
От: Vaako Украина  
Дата: 18.01.12 12:21
Оценка: +1 -3
Здравствуйте, Artifact, Вы писали:

A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием. С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности ООП. Складывается впечатление, что ООП это такой хорошо замаскированный современный GOTO. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться классы. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?


Ой осторожнее, щас защитники ООП на вас накинутся !!!!
Сразу начнется со всех сторон
— а как же вы без инкапсуляции ?
— а как же вы без наследования ?
— а как же паттерны без объектов применять ?

Уже ни раз начиналась подобная тема и защитники ООП воспринимают затруднения как полный отказ от ООП, не понимая, что вопрос сводится не в оценке полезности ООП. Никто никуда никакие объекты выкидывать не собирается. Разве таким объяснишь что если интерфейс изменился хотя бы раз за время жизненного цикла приложения значит инкапсуляция не сработала! Ну и что что мы можем перевыбрать интерфейс? Задача ведь состояла не в использовании примочек, а в гарантированном разделении внутренних и внешних проектных решений по отношению к этому самому объекту. Не сработало разделение. В случае наследования — не сработало обобщение. В случае паттернов вообще молчу.
Re[2]: Что-то нетак с ООП
От: HrorH  
Дата: 18.01.12 12:25
Оценка: +2
Здравствуйте, Vaako, Вы писали:

V>Здравствуйте, Artifact, Вы писали:


V>Ой осторожнее, щас защитники ООП на вас накинутся !!!!

V>Сразу начнется со всех сторон
V>- а как же вы без инкапсуляции ?
V>- а как же вы без наследования ?
V>- а как же паттерны без объектов применять ?

Инкапсуляция и паттерны не являются привилегией ООП.
Re: Что-то нетак с ООП
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 18.01.12 12:48
Оценка: +3
Здравствуйте, Artifact, Вы писали:

A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке.


Что-то такого не замечал на своих проектах. Сложность определяется сложностью поставленной задачи.

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


?

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


Наверно, иначе не умеют. Но чья это беда?
Re[4]: Что-то нетак с ООП
От: WolfHound  
Дата: 18.01.12 13:07
Оценка: 63 (7) +8
Здравствуйте, supacrazypusher, Вы писали:

S>Для этого нужно нормально проектировать систему и управление зависимостями в ней. Если архитектура ужасная, модульности не и в помине и не делаются попытки улучшить ситуацию, то, боюсь, тут уже неважно ФП, ООП или брэйнфак.

Практика показывает, что повторно использовать можно только тот код, который специально для этого проектировался.
А это по факту исключительно библиотеки общего назначения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Что-то нетак с ООП
От: Abyx Россия  
Дата: 18.01.12 13:08
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>2. Объем задачи, для которой нужно применять ООП, должен быть достаточно велик. Ну, ИМХО от 50000 строк примерно. Иначе просто нерентабельно применять мощнячий инструмент для относительно несложной задачи.


если бы вы использовали TDD, то знали бы, что объем задачи может заканчиваться сотней строк кода — один класс, интерфейсы зависимостей, mock-классы зависимостей, тесты
In Zen We Trust
Re: Что-то нетак с ООП
От: Abyx Россия  
Дата: 18.01.12 13:17
Оценка:
Здравствуйте, Artifact, Вы писали:

A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке.


обычно на вопрос "что делает код?" отвечают имена классов\методов и краткие строки документации,

а вопрос "в каком порядке" либо вообще применим — реюзабельный код можно комбинировать в любом порядке,
либо на него отвечают методы задающие этот порядок —

void beginDoFoo()
{
    doStepOne();
    doStepTwo();
    async_doStepThree([this](){ completeDoFoo(); });
}
In Zen We Trust
Re[3]: Что-то нетак с ООП
От: LaptevVV Россия  
Дата: 18.01.12 13:19
Оценка:
Здравствуйте, Abyx, Вы писали:

A>Здравствуйте, LaptevVV, Вы писали:


LVV>>2. Объем задачи, для которой нужно применять ООП, должен быть достаточно велик. Ну, ИМХО от 50000 строк примерно. Иначе просто нерентабельно применять мощнячий инструмент для относительно несложной задачи.


A>если бы вы использовали TDD, то знали бы, что объем задачи может заканчиваться сотней строк кода — один класс, интерфейсы зависимостей, mock-классы зависимостей, тесты

Можно пример конкретной реальной ЗАДАЧИ, объем которой заканчивается сотней строк.
Мне таких ЗАДАЧ не попадалось...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Что-то нетак с ООП
От: Abyx Россия  
Дата: 18.01.12 13:44
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, Abyx, Вы писали:


A>>Здравствуйте, LaptevVV, Вы писали:


LVV>>>2. Объем задачи, для которой нужно применять ООП, должен быть достаточно велик. Ну, ИМХО от 50000 строк примерно. Иначе просто нерентабельно применять мощнячий инструмент для относительно несложной задачи.


A>>если бы вы использовали TDD, то знали бы, что объем задачи может заканчиваться сотней строк кода — один класс, интерфейсы зависимостей, mock-классы зависимостей, тесты

LVV>Можно пример конкретной реальной ЗАДАЧИ, объем которой заканчивается сотней строк.
LVV>Мне таких ЗАДАЧ не попадалось...

Вы наверное не прочитали слово "TDD".

Пример задачи — написать класс Foo c интерфейсом IFoo, который делает то-то, используя переданные ему объекты с интерфейсами IBar и IBaz.
Это реальная задача которая решается программистом при написании программы в 100'000 строк.
"скопировать данные из IInputStream в IOutputStream"
"запросить данные у IFooDevice и обновить IFooStateWindow"
"добавить AUserCommand в IMacroRecorder"
In Zen We Trust
Re[5]: Что-то нетак с ООП
От: LaptevVV Россия  
Дата: 18.01.12 14:06
Оценка:
Здравствуйте, Abyx, Вы писали:

A>>>если бы вы использовали TDD, то знали бы, что объем задачи может заканчиваться сотней строк кода — один класс, интерфейсы зависимостей, mock-классы зависимостей, тесты

LVV>>Можно пример конкретной реальной ЗАДАЧИ, объем которой заканчивается сотней строк.
LVV>>Мне таких ЗАДАЧ не попадалось...
A>Вы наверное не прочитали слово "TDD".
Читал.
A>Пример задачи — написать класс Foo c интерфейсом IFoo, который делает то-то, используя переданные ему объекты с интерфейсами IBar и IBaz.
A>Это реальная задача которая решается программистом при написании программы в 100'000 строк.
A>"скопировать данные из IInputStream в IOutputStream"
A>"запросить данные у IFooDevice и обновить IFooStateWindow"
A>"добавить AUserCommand в IMacroRecorder"
Понятно. Мы просто по-разному понимаем слово "задача".
Я бы назвал это — программирование ООП "в малом"
В описанном вами контексте — это задача. Но ТС сокрушался, что не возможно понять совместную работу классов:

трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием.

А здесь ИМХО имеется ввиду программирование ООП "в большом"...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Что-то нетак с ООП
От: Vaako Украина  
Дата: 18.01.12 14:32
Оценка:
V>>Здравствуйте, Artifact, Вы писали:

V>>Ой осторожнее, щас защитники ООП на вас накинутся !!!!

V>>Сразу начнется со всех сторон
V>>- а как же вы без инкапсуляции ?
V>>- а как же вы без наследования ?
V>>- а как же паттерны без объектов применять ?

HH>Инкапсуляция и паттерны не являются привилегией ООП.


Так интерфейсы функций тоже инкапсуляцию создают. От того что ООП победило структурное программирование функции и структуры же не исчезли ведь? Нужна серебреная пуля, которая убивает все недостатки и оставляет только полезности. Например — ану сделайся программа хорошая и нужная! И раз программа уже создана представителем Индии без всякого вашего участия и использования инкапсуляции вами лично

Если серьезно, то пока мы не сможем количественно измерять насколько принципы ООП плохи любая точка зрения это переливание из пустого в порожнее. И вообще, из того что инкапсуляция принадлежит не только ООП не означает её полезность и работоспособность во всем без исключения случаях. И тем более не значит что инкапсуляцию лучше не применять нигде и никогда. Либо надо прощупать более крутую технологию типа DSL и в сравнении познать истинное лицо ООП. Хотя я не совсем уверен что DSL лучше на самом деле.
Re[2]: Что-то нетак с ООП
От: Enomay  
Дата: 18.01.12 14:38
Оценка: +1
V>Уже ни раз начиналась подобная тема и защитники ООП воспринимают затруднения как полный отказ от ООП, не понимая, что вопрос сводится не в оценке полезности ООП. Никто никуда никакие объекты выкидывать не собирается. Разве таким объяснишь что если интерфейс изменился хотя бы раз за время жизненного цикла приложения значит инкапсуляция не сработала! Ну и что что мы можем перевыбрать интерфейс? Задача ведь состояла не в использовании примочек, а в гарантированном разделении внутренних и внешних проектных решений по отношению к этому самому объекту. Не сработало разделение. В случае наследования — не сработало обобщение. В случае паттернов вообще молчу.

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