[C++] Идеология. Открытые члены-переменные

Эх...кажется у меня зачатки быдлокодера...
Вроде бы тут http://www.e-reading.org.ua/chapter.php/1002058/58/Mayers_-_Effektivnoe_ispol... вполне неплохие доводы насчет использования только методов.
Вроде бы язык знаю, но постоянно возникают вопросы «Правильно ли делать так, а не иначе?». Неплохо было бы почитать про это. Майерс хорош?

Мне кажется удобным сделать переменные-члены x и y, этого класса, открытыми, и хранить в них ссылки на соответствующие компоненты вектора

Язабан^U В посте явное разжигание напалмом. Пусть это будет не класс, а структурка, в которой не хранится ссылка, а сама она хранится в векторе и членов-переменных не много (не больше двух, простого типа), тогда еще можно простить Обычный пример такого «некласса» что-то вроде

 struct PointXY { int x; int y; }; 

и то можно нарваться на пуристов, которые любят явные определения всего (конструкторы explicit дефолтом, а если копирования-преобразования - так явные). А в сложных классах, содержащих не простые типы, при повседневном программировании, видишь ли, подобные «преступления против инкапсуляции» - создают предпосылки для массовой ходьбы по минному полю.

С ним весело, если вмеру :) Александреску тоже местами доставляет - особенно когда его в сорцах цитируют. как причину для использования какого-то трюка с шаблонами... «Можем использовать - надо срочно использовать!!!111» - психология такая. Лечится, но должен быть вменяемый руководитель.

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

Плохо ли делать переменные-члены класса открытыми?

s/класса/структуры/
нормально! делайте!

Когда много открытых членов, то это уже структура. В том числе и вектор не помешает оформить в виде структуры.

Прикинь будущий рефакторинг. Сможешь ли ты, если тебе понадобится, относительно быстро заменить все strct.x = e на strct.setX(e)? «Относительно быстро» — это, в том числе, и такой вариант: структура используется в пяти местах и заменить всё ручками — не проблема вовсе.

ломающей побочкой будет код в виде

strct.setX(x); strct.y = y;

...

Вообще я хотел такой метод: [code] float &x() { return components[0]; }

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

Классическим примером в данном случае послужит класс вектора, с которым можно работать и в полярных, и в декартовых координатах. Пользователю совсем не нужно знать, какое именно представление было выбрано для хранения информации внутри класса, ему достаточно иметь методы get_cartesian(), get_polar(), get_length() итд.

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

sol_linux

Плохо ли делать переменные-члены класса открытыми?

Смысл ООП в том, что объект сам выдаёт знания о себе и сам выполняет действия. К примеру, у тебя есть яблоко со свойством - количество семечек. Чтобы узнать, сколько семечек в яблоке, ты спрашиваешь у яблока геттером. А уж что оно тебе скажет - это его дело (яблоко может и соврать, если такое предусматривается). Так-то. Если яблоко падает - ты не присваиваешь координаты, а вызываешь действие у яблока - «упасть» и тебя не волнует что с ним будет. Если интересно - спроси яблоко о его координатах.

Я не уверен, что в твоей задаче оправдано ООП вообще (оно требуется для больших проектов), но я ответил, так как ты спросил об идеологии. Потому что если пишешь программу «Яблочный сад» на миллионы строк кода и тебе заказчик вдруг скажет, что зёрна в яблоках не нужны, а проект сдавать завтра - ты просто заменяешь геттер, который будет выдавать 0.

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

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

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

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

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

struct { int x; int y; int z; } без всякого ооп и перегрузки операторов кастуется к массиву int - удобно.

Если речь идет о декартовом векторе, то не плохо. И вообще не плохо, если конечно Вы не адепт абстрактного искусства расово чистого кодирования.

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

It depends.

С закрытием и написанием правильных конструкторов копирования / сеттеров / геттеров количество строк кода, использующего твой класс обычно меньше, чем если бы он был POD-типом. Но опять же всякие вещи типа s = { 0 }; или нагленькое memset / memcpy уже не очень-то смотрятся, или не компилируются вовсе, что в принципе хорошо, тк потенциальные ошибки - на этапе компиляции ;)

в жопу любую идеологию как удобно в данный момент так и делай любая идеология это маразм и бред надо быть выше всего этого не надо приобщатся к маразматикам живущим по идеологиям

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

делайте как Вам удобно и вообще зря Вы по этому поводу паритесь это такая хрень никак не влиющая на работоспособность программы

Тут дело не в идеалогии, а в эффективном использовании инструмента. Инкапсуляция реально помогает, для того ее и придумали. Если объект сложный, лучше стремиться создавать его интерфейс на основе методов-действий (например move(x, y), вместо setX(x), setY(y)) с минимумом геттеров и сеттеров. Ну а если же объект настолько простой, что его интерфейс представляет собой только геттеры и сеттеры, вполне возможно следует использовать простую структуру.

в жопу любую идеологию как удобно в данный момент так и делай

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

98% кода «на всякий случай» никогда не дожидается того самого случая, когда он будет использоватся.

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

конкретно в большой группе и над другим проектом неудобно делать так как удобно, ибо есть code style convention, app design and so fourth, котоым надо следовать.

ломающей побочкой

Покарай неверного, Святой Розенталь!