Стоит ли использовать ООП?

Здравствуйте.
Возник такой вопрос: стоит ли использовать ооп. Даже не так, когда использовать ооп?
Иногда (даже чаще всего) легче написать простые функции, а не мутить с классами обектами и методами.
Раздражает инкапсуляция - какой вообще ее смысл? Чтобы получить переменную класса по правилам ооп нужно создавать метод для ее чтения? когда такой подход оправдан - ведь затрачивается куча лишнего времени.

5

Сообщение от CheshireCat Никакая "интуиция", "я чувствую" и прочее не дают правильного ответа. Только экспериментальные данные профилировщика объективны и неоспоримы.

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

0

Сообщение от @KOT@ Раздражает инкапсуляция - какой вообще ее смысл? Чтобы получить переменную класса по правилам ооп нужно создавать метод для ее чтения? когда такой подход оправдан - ведь затрачивается куча лишнего времени.

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

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

про ооп объяснить еще на подобном уровне?

1

novi4ok, твой пример вообще никак не объясняет отличие ООП от функционального программирования. Отличие должно быть в том, что "ресторан.поесть()" должно быть чем-то принципиально лучше, чем "поесть(&ресторан)". А этого отличия нет

0

Сообщение от Evg novi4ok, твой пример вообще никак не объясняет отличие ООП от функционального программирования. Отличие должно быть в том, что "ресторан.поесть()" должно быть чем-то принципиально лучше, чем "поесть(&ресторан)". А этого отличия нет

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

0

На мой взгляд, смысл ООП - не в форме записи "ресторан.поесть()" или "поесть(&ресторан)" или даже "execute(&ресторан, "поесть")". Смысл - в выделении отдельной сущности "ресторан" и группировке вокруг него всего, что к нему относится. А дальше уже пошли технические приемы: инкапсуляция кухни, наследование от "места, где жрут" и т.д.

1

Инкапсуляцию надо пояснять на примере, когда есть хотя бы ДВЕ сущности, которые надо отделить одно от другого и желательно много экземпляров разных сущностей. Во многих книгах делают аналогичную ошибку. Заводят класс "болт", поля класса "длина", "диаметр", методы "закрутить", "открутить" и говорят, вот вам, товарищи, инкапусляция. А потом новичок читает эту книгу и не может понять, зачем нужно писать в классах, вместо того, чтобы завести структуру "болт" и функцию "закрутить (const болт*)". Вот у возникает у людей ощущение, что инкапсуляция - это когда можно записать "болт.закрутить()" вместо "закрутить (&болт)". Т.е. пишут в какой-то степени правильные вещи, но на таких примерах, которые ну никак не дают ответов на вопросы "зачем" и "почему"

1

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

0

Сообщение от Evg Инкапсуляцию надо пояснять на примере, когда есть хотя бы ДВЕ сущности, которые надо отделить одно от другого и желательно много экземпляров разных сущностей.

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

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

0

которые хотят поесть, и сущности, которые этих первых кормят

.
Класс человека-посети ля. метод: жратъ.
Класс человека-официанта. метод: дать пожратъ.

0

кстати, появление вопроса "стоит ли использовать ооп" вполне закономерно: стоит только посмотреть, какими темами пестрит раздел с/с++. люди учатся всему кроме того чем им придется заниматься. конечно, нужно понимать "что там, внутри" и "из чего изготавливают болты", но зачем на изготовлении болтов зацикливать будущемго инженера-машиностроителя? он вряд ли будет проектировать когда-нибудь новые болты (существует достаточно разновидностей), а живую машину он впервые увидит уже когда работу найдет (если).

0

Сообщение от novi4ok но сущность и удобство инкапсуляции - определить интерфейс, и, проектируя посетителя, не думать о том, как происходит заказ продуктов в ресторане (и вообще заказывает ли их кто-то, и есть ли вообще продукты ).

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

1

Evg:
Ясень пень.

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

Добавлено через 53 секунды
Я такие приёмы использую при работе с MFC.

0

Сообщение от Genius Ignat Одна есть фишка ООП, и она мне нравиться

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

1

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

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

0

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

Добавлено через 10 минут
По поводу инкапсуляции novi4ok надо примерно так:
Официант даёт поесть, но что бы дать поесть, еду надо приготовить,
Как она(еда) готовиться посетителя не волнует, вот инкапсуляция.

Добавлено через 1 минуту
Пример простой инкапсуляции: функция~процедура, в любом языке программирования.

0

Официанта это, кстати, тоже не волнует. Инкапсуляция, блин :-)

1

Функции класса: интерфейсы надо предоставить, а что в них происходит при вызове
и какие данные класса могут в ней использовать программиста использующего класс не должно волновать, максимум что волнует передаваемые параметры и возвращаемое значение.

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

Добавлено через 1 минуту
Официанта это, кстати, тоже не волнует. Инкапсуляция, блин :-)
Точно за был добавить, наверно сюда ещё повара надо добавить, которому посетитель вообще по

0

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

1

А вообще надо просто определение инкапсуляции, как правило русского языка:
может тогда вопрос будет закрыт...

Добавлено через 2 минуты
А кто-нибудь знает определение инкапсуляции?

Добавлено через 4 минуты
В книгах которые я читал определение размазано, как хочешь так и понимай.

0

Сообщение от Genius Ignat А вообще надо просто определение инкапсуляции, как правило русского языка: может тогда вопрос будет закрыт... Добавлено через 2 минуты А кто-нибудь знает определение инкапсуляции? Добавлено через 4 минуты В книгах которые я читал определение размазано, как хочешь так и понимай.

Инкапсуля́ция — свойство языка программирования, позволяющее объединить и защитить данные и код в объект и скрыть реализацию объекта от пользователя (прикладного программиста). При этом пользователю предоставляется только спецификация (интерфейс) объекта.

Добавлено через 1 минуту

Сообщение от Genius Ignat По поводу инкапсуляции novi4ok надо примерно так: Официант даёт поесть, но что бы дать поесть, еду надо приготовить, Как она(еда) готовиться посетителя не волнует, вот инкапсуляция.

Но так же делеат и обычная функция. Когда мы вызываем функцию например принт, нам совершенно все равно как она печатает текст.

1