we use this system,


class temp
{
long m_variable;
void Variable(long set){m_variable=set};
long Variable(void){return m_variable};

};

get/sets are a waste of time and returning a reference to a private is an even bigger waste of time. If it's public, it's public and it's not a contract nor component oriented design for that class.
It's OK to make utility classes for convience sake that are not 100% to the letter modern OO designs; xsp when you waste time writing useless code to make the class less intuitive to use.

And I've always said lots of get/set tuples are a good indication of a poor design. 99% of the time they don't abstraction anything, so they do no useful work. The other 1% of the time they are poorly named mutators (methods). If it does something, give it a real function name that tells you what it does.

TCPSocket.ServerAddress = 192.168.0.1;
cout << TCPSocket.ServerAddress;
- or -
tcp_socket.connect(192.168.0.1);
cout << tcp_socket.server_address();

To me, the first way is retarded, but this is how several connection abstraction layers work (ADO comes to mind).

...

Quote:Original post by thedevdan
Wait... VC++2005 has properties?

MSVC5 did (MSVC2005 is MSVC7.2 I think) even 4 might have.
C++ Builder has had them since v1 or 2.
I think gcc even has an extention for them.
The only place they are typically used is in generated code, such as MS COM or from Borland's UI builder (and sometimes in Borland's VCL).
You can write them yourself, if you dig deep in Software Engineering I think I posted the syntax of them all about two years ago.


PS Friends are generally worse than accessors. Only useful/needed in a few case, e.g. operator overloading or extremely tightly coupled classes, such as DirectShow filters & pins.

Often, an inner class is tightly coupled, and that means that often, inner classes are friends.

Or you can design your program (in C++) to not expose the implementation at all. Define abstract base classes as interfaces in the public headers, declare a factory for your abstract interface, and implement a concrete class in a .cpp file. That way, the concrete implementation is only in a single file, and can make everything public to the implementation in that file. This also loosens coupling; changing the implementation doesn't mean re-compiling all users.


Regarding delegates in C#, if you haven't learned delegates yet, run, don't walk, to the help file, and figure it out. A delegate is a way to bind a function prototype and an object instance into a single data item. It looks like a function pointer, but when someone invokes the delegate, the specific object it delegates to is invoked. (All the WinForms events are delegates)

This is IDEAL for a narrow interface such as a DAL.