Всем привет, я не смотрел есть что-то типа этого здесь или нет. Так что извините, если чего.
Частенько сталкиваюсь с такой вещью.


class a
{
public:
  a();
  int & getA() { return a;} // или так
//  int * getA() { return &a;}
private:
  int a;
};


Если бы я это видел 1 - 2 раза и этот код был написан неумелым программистом - еще ничего.
Зачем тогда обьявлять закрытые данные в классе, если через функцию этого же класса можно получить прямой доступ к данным ??? Причем добавление const в обьявлении функции getA - не имеет значения. 
Я думаю тогда не стоит такие даные делать закрытыми, так как тут получается всего лишь лишний вызов функции класса и потерянное время написания ???
Например возьмите исходники Blendera - там сплошь и рядом - такие  обьявления и реализации.

для того чтоб разделить интерфейс и реализацию..
например если понадобится модернизитовать класс до такого : 



а на что оптимизатор ?!

По-моему, это все же дурной тон, псевдо-объектное программирование. Если уж делать доступ через функции, то 2 метода - get\set. Тогда на метод set можно навесить какую-то доп. функциональность, защитить как-то и т.д. Единственное, что можно сказать в защиту предоставления полного доступа через функцию - ее потом легче выловить в коде (поиском), если все же придет мысль переписать нормально код... 
Еще один возможный аргумент - это только макет, и дальше будет не переменная, а что-то посложнее. Функция в этом смысле дает больше возможностей, но и тогда лучше отдельные get\set. 

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



для случая get/set - да, бывает такое (зачастую у новичков),
 но не всегда их наличие является показателем псевдо-ООП.


Это сообщение отредактировал(а) mes - 21.6.2010, 08:36

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

Псевдо ООП - как раз в точку сказано.
Я пишу плагин к майя. Все структуры данных просто завернул в классы, проще писать.
Имеется три класса Mesh, Transform, и FString.
Потом я их завернул в один класс MeshNode и начал эти классы расписывать как по учебнику.
типа того как написал выше. Просто в некоторых случаях нужен именно "прямой" доступ к данным.
Провозился много и нудно с get set и типа этого. Но пришел к выводу - если юзер - использует только dll и не имеет никакого отношения к программированию - зачем извращаться столько писать. - написал - все или через friend class ... или просто все данные сделал открытыми. У меня просто нет никакого полиморфизма и глубокого наследования чтобы реализовывать принципы ООП на 5+. 

классы :

class Mesh
{
public:
friend class MeshNode;
private:
  mdata ...;
};
class Transform
{
public:
friend class MeshNode;
private:
  tdata ...;
};
class FString
{
public:
private:
  sdata ...;
};
class MeshNode
{
public:
private:
  Mesh        mMesh;
  Transform  mTransform;
  FString      mName;  
};


Когда учился в институте - практики было маловато. Ведь написать можно полюбому - хоть с помощью правильного ООП, хоть с помощью С и структур - не важно - все равно работать будет и придраться не к чему особо наверное.
Настоящего ООП - в этом примере нет - и быть не может, и я думаю что придумывать и превращать эти классы в непсевдо-ООП - смысла нет. Может ошибаюсь. 

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


// maya
#include "maya/MfnMesh.h"
#pragma comment (lib, "polyApi.LIB")
// mine
#include "nea/MeshNode.h"
#pragma comment (lib, "neaMesh.LIB")

using maya::MIntArray;
using nea::MIndexArray;

int ImportMeshData(MIntArray & in, MMeshNode & meshNode, FStatus * statusErr = 0)
{
    MIndexArray & out = meshNode.getMesh().mesh.getIndices();
    //MIndexArray & out = meshNode.mesh.indices // честно - неохота так делать
    size_t size = in.length();
    out.reserve(size);
    for (size_t i = 0; i < size; i++)
    {
        out.push_back(in[i]);
    }
    if ( 0 != statusErr )
        *statusErr = 0;

    return 0;
}



Либо это делать в функции класса MeshNode, но тогда библиотека майя должна быть привязана всегда, что мне точно не нужно.

Да кстати почему народ старается написать всегда свои классы контейнеров и строк, если есть std::vector, std::string, в конце концов STL Port и Boost ??? Особенно Связные списки и векторы - почти всегда свои народ пишет - но под свой выделитель памяти можно std::vrctor - настроить - как захочешь.
Правда string - слишком универсальный, причем все они работают с любыми самодельными распределителями памяти.
Я только передалал string на свой - он попроще читается - да и программируется - складывает с строками с символами с цифрами ...., также подстроку выделяет и форматирует с разным и любым количеством аргуметнов как sprintf_s().

Это сообщение отредактировал(а) neondartal - 21.6.2010, 14:16

не весь народ, а только велосипедисты или для обучения.. за исключением случаев когда к _продукту_ предъявляются требования, которым не соответсвует реализованное в (стандартных) библиотеках.

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

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

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