Когда нужно использовать ООП?

[s-andriano]

Честно говоря, вообще не понимаю смысла вопроса.
Тогда - когда это удобнее.

С моей точки зрения к показаниям относится:

1. Можно инкапсулировать данные. Когда данные нельзя инкапсулирова, ООП мне представляется не очень логичным. Кстати, в одной из соседних тем обсуждает перемножение матриц на ООП. Честно говоря, не совсем понимаю, ка это грамотно сделать.

2. Код планируется повторно использовать.

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

Кстати, мне кажется, действительно интересный вопрос - с задачей о перемножении матриц. Как ее организовать с учетом инкапсуляции?

[BDA]

Ну нафлудили, так нафлудили
s-andriano, тот человек любит кросспостить - http://programmersforum.ru/showthread.php?t=202837, может быть вам решение приглянется.

[Utkin]

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

Вовсе нет. Эта система называется монитор (тупо перебор элементов в цикле, цикл считается атомарной операцией, прерывания запрещены) и использовалась ранее. Да и счас перебор объектов в играх не редкость. Да и без потоков игры делали и ничего, получалось . Никто в данном случае ничего не обязан.

Можно инкапсулировать данные

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

Код планируется повторно использовать.

О-о-о, откуда такой аргумент? Чем подтвержденный?

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

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

[s-andriano]

Сообщение от BDA

Ну нафлудили, так нафлудили
s-andriano, тот человек любит кросспостить - http://programmersforum.ru/showthread.php?t=202837, может быть вам решение приглянется.

Собственно, именно этот пост и спровоцировал вопрос.
Увы, не приглянулось, т.к. напрочь отсутствует инкапсуляция.
Может, есть какие мысли, как ее достичь?
Или, может, этой задаче ООП принципиально противопоказан?

Инкапсуляция:

Сообщение от Utkin

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

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

[Пепел Феникса]

1. Можно инкапсулировать данные. Когда данные нельзя инкапсулирова, ООП мне представляется не очень логичным. Кстати, в одной из соседних тем обсуждает перемножение матриц на ООП. Честно говоря, не совсем понимаю, ка это грамотно сделать.

а что матрица не имеет доступа к своим же данным?
и данным такого же класса как она?
инкапсулировать нужно грамотно.

[Utkin]

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

Конкретно в Дельфи через юнит можно попробовать. Не выносите объявления в interface. Вообще люди сильно накручены ООП, реально даже если будут видны массивы структур это не обязательно приведет к ошибкам.

[DiemonStar]

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

[Пепел Феникса]

По своей сути, все тормоза новых ОС из него и произрастают)

это миф.
а реальность в кривом проектировании.

[DiemonStar]

а реальность в кривом проектировании.

А их вообще проектируют?

это миф.

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

[3D Hunter]

Интересный вопрос, философский даже Зачем ООП? Чтобы абстрагировать разнородные логики в свои самодостаточные мини-системы. Когда есть сложные проект, в котором выполняется много чего и это все должно взаимодействовать, как-то трудно представляется решать такие проблемы с помощью процедурного программирования и глобальных переменных. Например, нужно написать многопоточный логгер событий, по сути метод с параметром строки. Как вы поступите? будете в приложение или юнит пихать переменную критической секции и инициализировать/финализировать ее в модуле? Еще несколько глобальных переменных имени файла, директории, чего-то еще... придумайте сами Да можно в общем-то... но зачем так некрасиво? Ведь класс-то сделать изящней и гибче.
Ладно, многие скажут, что здесь можно и без ООП. Согласен. А как вы будете организовывать взаимодействие того же логгера, несколько сотен потоков разного назначения, GUI и т.п.? Код будет похож на сишный