Свойства класов - зачем помещать свойство в приват

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

PS. тут ещё мысля возникла, если в Си (не C++, а простой Си) небыло оператора new то получается небыло утечек памяти?

0

Страуструпу я "доверяю, но проверяю". а вот тебе и твоему автору публикации - даже не доверяю.

0

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

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

0

Так я могу бросить исключение в случае, когда c невалидный, написать thread-safe вариант класса, посчитать количество обращений к c, промониторить изменения ... и все это всего из одного места в кода.
В этом случае чтоб сделать все это мне придется переписать половину всего кода.
Вопрос в поддержке и расширяемости.

0

0

2

Сообщение от villu Так я могу бросить исключение в случае, когда c невалидный, написать thread-safe вариант класса, посчитать количество обращений к c, промониторить изменения ... и все это всего из одного места в кода.

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

0

Сообщение от silent_1991 Не по теме: Сообщение от villu Вопрос в поддержке и расширяемости. Я уже говорил это Kuzia domovenokу в другой теме... Мой комментарий он проигнорировал.

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

0

Сообщение от Kuzia domovenok C++ 1 void setter(int v): value(v){}

Что-то кажется мне невалидным код этот.

0

Сообщение от CyBOSSeR Что-то кажется мне невалидным код этот.

В каком месте. Я конечно признаю, что могу ошибаться, но ошибки не вижу.

0

Сообщение от Kuzia domovenok В каком месте.

В наличии списка инициализации в методе.

0

а везде и не надо совать.
В той же std есть pair, который структура

а вот такой вариант
мне однажды очень много времени сэкономил и даже помог отловить бажину в железке. а класс, на сколько помню, у меня тогда просто данные с кардио-датчика содержал, то есть фактически несколько полей (как тот самый вектор x y z), которые можно было сделать структурой.
Тут же TC спрашивал о вариантах, где это полезно может быть, нет разве?

1

Kuzia domovenok, ну, если не учитывать, что мои геттеры/сеттеры так не выглядят, потому что список инициализации можно использовать только в конструкторе, то довольно редко. Потому что у меня классы обычно представляют поведение, а не данные, как и должно быть. Сами классы могут пользоваться несколько более высокоуровневыми данными, чем сырые данные стандартных типов, но такие данные я оборачиваю в структуры, описанные внутри классов, в приватной области. Если класс состоит из одних данных и методов доступа, т.е. представляет данные, то надо пересмотреть надобность использования класса.

4

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

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

0

0

kravam, нет, если принять, что геттер написан верно и не пропустит неправильные данные. Отладка классов - отдельная история, мы говорим о законченном рабочем коде.

0

ИМХО, сокрытие в первую очередь нужно, чтобы упростить отладку программы. Например, при моделировании органайзера, мы должны быть твёрдо уверены, что встреча, намеченная в декабре, может проходить только в числах от 1 до 31. В то же время инкапсуляция позволяет делать программы более масштабируемыми. Например, если мы грамотно напишем обобщенный интерфейс доступа к базе данных, то в случае изменения самого сервера( или библиотеки ) БД нам придётся изменить код только в интерфейсе

0

Сообщение от Buckstabue В то же время инкапсуляция позволяет делать программы более масштабируемыми

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

0

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

не пойдёт. Ты вызовешь самый правильный суперпупергеттер в ненужном месте и весь код насмарку. Это я и называю (и оно по-моему такое и по сути)- ошибочно изменить поле класса.

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

0

А меня аргумент "потому, что так правильно" вполне устраивает, если произнесён кем-то сведующим в вопросе. Причины, по которым "так надо", станут понятны по мере приобретения опыта. Читаю книжку Perl Cookbook Тома Кристиансена и Натана Торкингтона (по мере прочтения проникся искренним уважением к авторам, к тому же в самой документации perl сплошь и рядом ссылки на эту книгу). В perl поддержка ООП вообще весьма своеобразно сделана. В частности нет стандартных средств языка для ограничения доступа к данным класса (что, в прочем не мешает истинным параноикам запрятать данные так, что захочешь - не доберёшься), но вот, что пишут авторы по этому поводу:

Работа методов зависит от того, как вы организуете открытый интерфейс к объекту. Нормальный класс не любит, чтобы окружающие копались у него во внутренностях. Для каждого атрибута данных должен существовать метод, обеспечивающий его чтение или обновление. Если пользователь пишет фрагмент вида: Perl 1 2 3 $him = Person->new(); $him->{NAME} = "Sylvester"; $him->{AGE} = 23; он нарушает интерфейс объекта и напрашивается на неприятности.

Ну а в С++, где есть способ запретить пользователю прямой доступ к данным класса, просто грех этим не воспользоваться. Разумеется, если класс не просто хранит значения переменной plain типа, при этом не заботясь о смысле и допустимости этих самых значений...

2

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

0