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

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

5

Сообщение от Нитонисе Довольно долго пытался осознать принципы ООП. Читал много литературы, пробовал использовать. И все равно не смог понять тех преимуществ, которые ООП дает

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

Добавлено через 2 минуты
Кстати, из моих слов вовсе не следует, что не надо читать литературу. Человеческий мозг устроен весьма интересно. Ты можешь много чего прочесть, не особенно понимая прочитанного, но что-то из этого всё равно в мозгу осядет и в будущем, по мере получения опыта, ты невольно начнёшь эти знания из мозга извлекать

0

Сообщение от snake32 Set и Get не обязательны для каждого свойства. Одни свойства могут быть только для чтения, другие - для чтения/записи.

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

Сообщение от snake32 А для Length метод Get может выглядеть так: Result := Radius*2.0*pi; и Set так: Radius := value/(2.0*pi); то есть значение вычисляется в рантайме и не занимает память, но снаружи класса Length видится как обычное свойство с типом плавающей точки.

Возможность под простым Set() подразумевать какие-то вычисления, которые модифицируют несколько данных класса - не связана с темой их защиты. А если связи все же искать, то защита здесь только ухудшается. Если у нас есть класс Circle с данными Radius и Area, то метод SetRadius() может не только установить новое значение радиуса, но и заодно сразу же вычислить площадь Area. Таким образом мы меняем сразу два внутренних параметра класса, причем площадь Area меняется не явно. О какой тут защите данных можно говорить?

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

А вот в умных книжках, начиная с Страуструпа, пишут, что поначалу нужно все данные объявлять приватными, так как потом сделать данные публичными проще, нежели публичные данные превратить в приватные.

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

Вы акцентируете внимание на удобстве использования. Но речь идет о защите данных. Идея такая - давайте поместим данные в private-блок с тем, чтобы никто не смог их изменить. Как это работает - я не понимаю. Ведь есть методы модификаторы, например Set(). Если же исходить из удобства использования, то с этим я не спорю. Допустим мне удалось выделить набор данных и методы для их обработки в один класс, причем эти методы не нарушают выбранную нами абстракцию. В этом случае действительно удобно эти данные изолировать в классе и использовать только для собственных методов. Всем прочим частям программы ничего об этих данных знать не нужно. Но во-первых такие автономные данные довольно сложно выделить (у меня не выходит). А во-вторых, даже если такие данные удалось выделить - все равно можно поместить их в public-блок. Ведь поскольку эти данные никому больше в остальной программе не нужны, значит и изменить их никто не сможет - данные де-факто защищены.

Сообщение от Убежденный Значит, функции нужно проектировать таким образом, чтобы их сигнатуры менялись по возможности реже.

Ясно, что к этому надо стремиться. Но процесс программирования итеративный, постоянно приходится пересматривать старый код и модифицировать. Допустим я в первом приближении определил основные классы и определил для них внешний интерфейс. Затем в процессе реализации увидел, что удобнее в интерфейсе использовать другую сигнатуру функций - начал переписывать, соответственно менять вызов этих функций-членов из других частей программы. И насколько я понимаю - так происходит у всех. То есть это нормальная ситуация даже для профессиональных программистов. Такого, чтобы сел и написал красивую программу - не бывает.

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

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

Сообщение от Evg Понимание приходит с опытом, а вовсе не от того, что читать литературу по этому вопросу. Причем желательно иметь опыт работы с большими и сложными программами. ООП, как и многие другие вещи - это мощный инструмент в умелых руках и способ превратить программу в помойку в кривых руках.

Ну я не ограничивался чтением. Конечно же пробовал использовать принцип ООП. Но зачастую получалось так, что ООП использовалось ради ООП. Брожу по предметной области с тем, чтобы найти какую-нибудь сущность и сформировать в класс Толком не осознавая, что мне это даст. А зачастую это мне дает лишь усложненную структуру программы и сложный доступ к данным. Если пользовать классы, то нужно четко осознавать, какую именно пользу от использования класса я получу. В принципе один очевидный плюс я нашел - это полиморфизм. Иногда бывает очень полезно. Вероятно будет польза и в случае, если удастся выделить такие сущности, внутренние данные которых никому более не нужны. Тогда эти классы можно разрабатывать изолировано, что позволит не держать в голове большой объем информации. Третий возможный плюс - создание какого-то общего класса, который возможно использовать в большом количестве программ. Если ориентироваться на эти три плюсика ООП, то можно прийти к выводу, что ООП нужно далеко и далеко не всегда. Хотя, читая литературу по С++, складывается впечатление, что ООП - эта та самая панацея от всех бед программиста

0

Сообщение от Нитонисе Вообще некоторые базовые принципы ООП привлекают. Например бывают коллекции разных объектов, которые все прячутся за одним абстрактным типом, но каждый по своему реализует какое-либо действие. Ну, классический пример с абстрактным классом Shape и наследниками Circle, Rectangle, Triangle. У базового класса есть виртуальная функция Draw(), которую наследники реализуют каждый по своему. Такое полиморфное поведение я понимаю и вижу его преимущества.

А это и есть то единственное, что отличает ООП от остальных, и что собственно «поддержка ООП» даёт языку — простое и удобное написание виртуальных методов. Всё остальное, что обычно называют «основами ООП» особого отношения к ООП не имеет и является либо общей техникой вообще программирования (например инкапсуляция — модульность, абстрактные типы данных), либо частной техникой конкретных объектных моделей (наследование).

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

Сообщение от Нитонисе Возможность под простым Set() подразумевать какие-то вычисления, которые модифицируют несколько данных класса - не связана с темой их защиты. А если связи все же искать, то защита здесь только ухудшается. Если у нас есть класс Circle с данными Radius и Area, то метод SetRadius() может не только установить новое значение радиуса, но и заодно сразу же вычислить площадь Area. Таким образом мы меняем сразу два внутренних параметра класса, причем площадь Area меняется не явно. О какой тут защите данных можно говорить?

О такой, что никакой умник не выставит независимо площадь и радиус в некорректные значения.

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

Сообщение от Нитонисе Так что повторное использование наработок - это не уникальное преимущество ООП.

Ага. Просто ООП в своё время сильно распиарили.

0

Сообщение от Нитонисе Таким образом мы меняем сразу два внутренних параметра класса, причем площадь Area меняется не явно. О какой тут защите данных можно говорить?

Сообщение от korvin_ О такой, что никакой умник не выставит независимо площадь и радиус в некорректные значения.

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

Сообщение от Нитонисе А вот в умных книжках, начиная с Страуструпа, пишут, что поначалу нужно все данные объявлять приватными, так как потом сделать данные публичными проще, нежели публичные данные превратить в приватные.

Я не предлагаю менять интерфейсную часть класса. Все публичные данные класса остаются одними и теми же(имя и тип данных). Просто в процессе разработки некоторые из них(в идеале все) превратятся из полей в свойства. Тогда вопроса о Get/Set тупо копирующего значения из/в поле просто не будет.

Сообщение от Нитонисе А во-вторых, даже если такие данные удалось выделить - все равно можно поместить их в public-блок. Ведь поскольку эти данные никому больше в остальной программе не нужны, значит и изменить их никто не сможет - данные де-факто защищены.

По вашей логике можно сказать: Ямы на дорогах не нужно заделывать. Ведь если ямы никому не интересны то и заделывать их не надо. Просто обходите их стороной и всё - проблем нет.
Однако, как показывает практика, люди не всегда умело пользуются простым методом "обходить стороной". Это человеческий фактор. Как ни крути программист - тоже человек. Скрывая "лишние поля" мы уменьшаем воздействие человеческого фактора.

0

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

Рассинхронизация - это уже другой аспект проблемы. Например есть класс Многоугольник с двумя членами: СписокТочек и Площадь. Предположим, что логика основной программы такова, что иногда бывает часто нужно запрашивать площадь многоугольника, а иногда это не нужно вообще. Так как в общем случае скорость вычисления площади сложной фигуры высока, то в методе ЗадатьНаборТочек не нужно пересчитывать площадь. И в этом случае мы и получаем, что есть возможность задать набор точек, а площадь будет либо вообще не посчитана, либо посчитана по предыдущему набору. Возможно пример не самый хороший, но я думаю что ситуации, когда набор данных класса рассинхронизирован - не редки.

Сообщение от snake32 По вашей логике можно сказать: Ямы на дорогах не нужно заделывать. Ведь если ямы никому не интересны то и заделывать их не надо. Просто обходите их стороной и всё - проблем нет. Однако, как показывает практика, люди не всегда умело пользуются простым методом "обходить стороной". Это человеческий фактор. Как ни крути программист - тоже человек. Скрывая "лишние поля" мы уменьшаем воздействие человеческого фактора.

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

0

Сообщение от Нитонисе Рассинхронизация - это уже другой аспект проблемы. Например есть класс Многоугольник с двумя членами: СписокТочек и Площадь. Предположим, что логика основной программы такова, что иногда бывает часто нужно запрашивать площадь многоугольника, а иногда это не нужно вообще. Так как в общем случае скорость вычисления площади сложной фигуры высока, то в методе ЗадатьНаборТочек не нужно пересчитывать площадь. И в этом случае мы и получаем, что есть возможность задать набор точек, а площадь будет либо вообще не посчитана, либо посчитана по предыдущему набору. Возможно пример не самый хороший, но я думаю что ситуации, когда набор данных класса рассинхронизирован - не редки.

Это как раз хороший пример - все решается приватным членом с именем типа m_Dirty, сбрасывается false после подсчета площади и устанавливается true если геометрия изменилась. Private здесь очень к месту.

А вообще критика совершенно механического применения геттеров/сеттеров справедлива. Часто бывает - ото нарисовал get/set, с понтом "инкапсулировал" - да ничего подобного, фиговый листочек. Не зацикливайтесь на этом. Если хоть часть данных удалось обособить, удачно поселить - уже успех. Не все классы "в духе ООП", есть просто "рабочие лошадки" (насколько помню, в библии "конкретные"классы). Напр строка, вектор - ни полиморфизма, ни наследования - но работы они делают много. В конце-концов процедурный подход никуда не убежит

0

Сообщение от Igor3D Это как раз хороший пример - все решается приватным членом с именем типа m_Dirty, сбрасывается false после подсчета площади и устанавливается true если геометрия изменилась. Private здесь очень к месту.

То есть при запросе площади класс внутри проверяет m_Dirty и если true, то делаем пересчет, а если false, то просто возвращаем имеющееся значение? Да, мы так будем получать всегда корректную площадь. Но это не отменяет того, что в какой-то конкретный набор времени набор точек может не соответствовать значению площади. Хотя не в этом вообще суть... рассинхронизация и ее устранение - это не то, что меня смущает. Смущает ваше желание сделать член m_Dirty приватным. Для чего? Что будет, если этот член сделать публичным?

0

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

Ну пастись на (могучем) накопленном - розовая мечта каждого, вот только сбывается она не всегда Впрочем в этом есть и плюсы - новые впечатления, опыт

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

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

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

Не спешите, приобретите практический опыт, на хороших разговорах далеко не уехать

0

Сообщение от Igor3D Сделав же их private мы можем быть уверены что ошибка вычисления площади (если она есть) только в пределах данного класса.

Откуда такая уверенность? Не вижу взаимосвязи между выбором места размещения этой переменной m_Dirty и локализацией ошибки выполнения метода GetArea(). Если запускаем программу в режиме отладки и видим, что площадь посчитана криво, то может это неверный набор точек создан.

Сообщение от Igor3D Не спешите, приобретите практический опыт, на хороших разговорах далеко не уехать

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

0

Сообщение от Нитонисе Откуда такая уверенность?

Оттуда, что невозможно изменить площадь извне класса. К.О.

Начни отсюда.

0

Сообщение от korvin_ Оттуда, что невозможно изменить площадь извне класса. К.О.

А если эту переменную-индикатор сделать публичной, то возможно?

0

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

Возможно потому что Вы торопитесь с выводами Приведенный пример довольно простой, но осмыслить его у Вас нет желания, продолжаете действовать в "напористо-деловитом" стиле. А программирование предполагает некоторые размышления и философию. Конечно Вы можете писать и напр так
И, возможно, это кажется проще и выгоднее. Ведь связавшись с private не получится так лихо сделать +=, да и флажок можно обновить 1 раз (после того как поработали со всеми точками). Вероятно в примерно таких ситуациях Вы приходите к выводам типа "нафиг нужен тот private!" - на мой взгляд скороспелым

1

Сообщение от Igor3D Вероятно в примерно таких ситуациях Вы приходите к выводам типа "нафиг нужен тот private!" - на мой взгляд скороспелым

К мысли о вреде использования private я прихожу всякий раз, когда мне надо запросить данные класса и я вызываю метод Get(). Вывод этот не то чтобы скороспелый и конечно же не окончательный. Это мой сегодняшний взгляд на проблему. Может быть когда-нибудь я и изменю точку зрения, но пока к этому никаких предпосылок. Приводимые здесь аргументы неубедительны и больше смахивает на то, что private используют ради private, а не потому что это дает какую-то реальную и осязаемую пользу.

0

Сообщение от Нитонисе а не потому что это дает какую-то реальную и осязаемую пользу

А какую, например, ты можешь ощутить осязаемую пользу?

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

0

Сообщение от Evg А какую, например, ты можешь ощутить осязаемую пользу?

Польза может быть всякая.

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

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

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

Польза может быть всякой. От применения приватных данных такой пользы пока не вижу.

0

Сообщение от Нитонисе А если эту переменную-индикатор сделать публичной, то возможно?

А зачем ее делать публичной? К слову, в SmallTalk вообще нет публичных полей.

0

Сообщение от korvin_ А зачем ее делать публичной?

Исходя из принципа бритвы Оккамы.

0

Сообщение от Нитонисе Исходя из принципа бритвы Оккамы.

Лол, при чем тут бритва Оккама?

0

Сообщение от korvin_ Лол, при чем тут бритва Оккама?

При том, что не нужно усложнять, если можно сделать проще.

0

Сообщение от Нитонисе При том, что не нужно усложнять, если можно сделать проще

Не нужно усложнять сверх необходимого, а не всегда когда можно. Разделение доступа — это необходимость для обеспечения целостности и непротиворечивости объекта.

0