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

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

5

А что говорит Б.Страуструп. по этому поводу?

Добавлено через 2 минуты
//--------------------------------------------
а не мутить с классами обектами и методами.
//--------------------------------------------

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

инкапсуляция - какой вообще ее смысл?

Тогда можно и не использовать функции.

0

Сообщение от Genius Ignat А что говорит Б.Страуструп. по этому поводу?

Не знаю что говорит Страуструп. Я хочу знать мнение других программистов. Может я чего-то не понимаю в программировании?

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

Сообщение от Genius Ignat Тогда можно и не использовать функции.

Функции можно и нужно использовать практически всегда. Даже всегда. В с++ и си-шарп без функций программировать вообще невозможно. Но программировать без ооп можно.
И меня интересует КОГДА удобнее использовать ооп, а когда обойтись обычными функциями.

0

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

Добавлено через 2 минуты
Наследование используется для реализации взаимосвязных понятий.
Взаимосвязь выстроена в виде иерархии.

0

Сообщение от Genius Ignat классы и объекты способствуют моделированию реальных понятий, в более наглядном виде не желе структуры и функции. Добавлено через 2 минуты Наследование используется для реализации взаимосвязных понятий. Взаимосвязь выстроена в виде иерархии.

Это я понимаю. НО: оправданы ли усилия на создание классов и обеспечение инкапсуляции и сокрытия данных и когда они оправданы

0

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

Добавлено через 3 минуты
Для больших проектов ООП это норм и оправдано.

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

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

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

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

так методы и данные классов могут наследоваться

Причём что наследовать надо , определяет программист.

0

И меня интересует КОГДА удобнее использовать ооп, а когда обойтись обычными функциями.[/ Я хочу знать мнение других программистов

Смотри, допустим ты создаёшь объект Цветочек. Ну ты описывашь какие-то данные (цвет, вид, количество лепестков и т.д.). Ты прописываешь ему функции (ну фотосинтез , размножение).

И если тебе нужен для работы всего один цветок , тебе хватит вполне несколько переменных для описания свойств и несколько функций. И тут тебе можно не заморачиваться на класс.
Но если, тебе нужно не 1 цветочек, а 10 , то представь, тебе нужно будет прописать уже не несколько переменных, а несколько умноженное на 10. А если нужно 100 цветков, ты представь сколько тебе переменных надо прописать? Прописать ладно, а какой хаус будет, у тебя только сотни строчек кода уйдёт на это.

А теперь прредставь, чтобы вызывать функции для каждого цветочка, тебе нужно прописывать передеваемые в функцию параметры вручную для каждого цветочка. А если их будет не 100 а 1000?

8

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

Кстати хороший пример ООП - string) Мы абстрагируемся от реальных данных (как я понимаю это называется инкапсулирование) скрывая их внутри. Мы знать не знаем про массив символов. И тут же можно удобно делать выделение памяти в конструкторе и удаление в деструкторе.

5

darkAngel:
Мысль не точна. Но всё равно тебе спасибо за рвение помочь.

Добавлено через 3 минуты
darkAngel:
Всё что ты сказал уложиться в малое количество строк, это следует логически из твоего высказывания.
Если хочешь я напишу на C++ всё что ты сказал. И ты удивишься.

0

Если хочешь я напишу на C++ всё что ты сказал. И ты удивишься.

Кстати помоему в этом и есть идеалогия (одна из) C++ что она не навязывает конкретной парадигмы программирования, она просто предлагает инстумент. А вопрос @KOT@ звучит по логике в виде "стоит ли использовать перфоратор или плоскогубцы? когда лучше использовать плоскогубцы. раздражает что перфоратор делает большие дыры". Прошу не анализировать пример, он для шутки

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

Все не так вы воспринимаете. Объект это реальная сущность класса. Т.е. класс это схема по которой компилятор скомпанует данные. Потеря производительности пустяковая. Наоборот кое где можно выиграть очень многое. А самое главно выиграть свое время и долголетие мозга

ps. В ООП просто надо войти. Вначале оно кажется бредом - по себе знал. А потом не оторвешь и даже где оно не нужно будешь делать...

1

Я в своем в стиле про рекламирую COM:
@KOT@:
Если хочешь создавать эффективные и легко модифицируем не монолитные приложения,
используй технологию COM.
В разделе COM & OLE я выложил очень хорошую книгу про технологию COM.

0

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

4

Evg:
Однозначно.

0

Всё что ты сказал уложиться в малое количество строк, это следует логически из твоего высказывания

ну да, если использовать массивы. но я немного другое имел в виду.

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

0

darkAngel, то, что ты описал - это НЕ есть ООП (а точнее так: ООП далеко не только это). Это всего лишь техническая реализация языка Си++. Формально - да, это инкапсуляция

Вариант на Си++

эквивалентен варианту на Си

Из постановки вопроса я так понял, что КОТ сие отличие понимает. Он не понимает ЗАЧЕМ это нужно, когда можно без этого. Или я не так понял его непонятки

1

@KOT@, Спасибо за вопрос.
Этот ООП - беда и боль моя!
Да не нужен он мне!
И малые задачи решали, и побольше - обходились.
Инкапсулирование - это нужно когда много ребят работает над проектом. И ты им не доверяешь.
Или считаешь дураками. Или когда проект так велик, что без дураков не обойтись (по статистике и теории вероятностей).
Полиморфизм - задумка интересная, но в реализации - убийственная.
Просто компилятор дает тебе ошибку (а без них когда-нибудь что-то было?) в обращении к
функции - и иди ищи чего ему не понравилось, функций-то этих у него десяток!
Не считая того, что ты пишешь HWND, а он (умница такая) говорит про int.
(Но это - отдельная тема - в судьи будем Окаму привлекать)
Однако есть очень важное место, где я не могу обойтись без классов, полиморфизмов,
наследований и прочих прелестей ООП. Это Виндовский интерфейс. Самому такую махину
не поднять. Приходится пользоваться ООПовскими наработками.
При первой же возможности сбегаю в чистый С и там себя чувствую вполне комфортно.
Все вышеизложенное - чистое ИМХО, хотя даже это не спасет меня от грядущего поклевывания.
Что я хочу сказать, @KOT@, - сомневаешься не ты один
PS: Если делать все с нуля - никакой ООП не нужен. Если хочешь облегчить себе житуху с помощью предшественников - приходится примкнуть к их стае.

2

Сообщение от Day Если хочешь облегчить себе житуху с помощью предшественников - приходится примкнуть к их стае.

Действительно. ЛУчше тупо игнорировать ООП и не облегчать себе житуху. Очень умно.

0

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

0

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

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

Скрытие полей (private, public) - тоже довольно удобная вещь. И полезно в том числе и для себя, когда проект уже реализуется несколько лет и ты с трудом вспоминаешь конкретику того, что было год назад. В этом месте наличие идиотов необязательно.

1

Сообщение от @KOT@ Раздражает инкапсуляция - какой вообще ее смысл?

Сообщение от Evg @KOT@, у меня есть дикое подозрение, что даже если тебе разжуют вопрос и разложат по полочкам, то ты всё равно не поймёшь. Как и большинство начинающих, которые задаются этим вопросом.

Evg, cовершенно прав, пока ваши знание о предмете на таком уровне вам не стоит использовать приемы ооп, поверьте будет только хуже.

Сообщение от taras atavin Для серьёзных проектов альтернативы по-моему нет

Вы всерьез уверены что крупный проект без приемов ооп не написать? (При том что он не будет уступать аналогу написанному на ооп ни по каким характеристикам) Ну чтож мне смешно на вас.

1