Dear Atul,

I now see your point about using a struct instead and that makes sense to me. I’ll take my time to look at least at some of the references you provided and think again about our specific case whether NodeAddress it is really a pure data encapsulation class.

I continue to strongly believe, however, that you are misinterpreting Item 42 as it EXPLICITLY refers to handles (i.e. pointer or references) to the internal representation, which we do NOT do. I’m considering the “use struct instead” idea as a good one but again, IMHO, it does NOT qualify under Item 42 and I’d expect that everybody who reads Item 42 carefully would agree with me.

Furthermore your post (e.g. the Stroustrup quote) actually refers to point 2, which is should we use structs when we have purely data encapsulation problem. I’ll post a follow-up about that later.

Best regards,

Peter

atul wrote:Dear Peter

The post addresses point 1 … I will deal with point 2 in another post…

— cheers atul

atul wrote:

Dear Peter

I think we are discussing two different things here…
1. The violation of Item 42 — this applies to, for example,

Pong::port, Pong::setPort, Pong::ipAddress, Pong::setIpAddress, Packet::setTtl, Packet::ttl, NodeAddress::hostName, NodeAddress::setHostName etc…

And 2. should value classes be used?

I think Item 42 clearly applies here and we are violating it.
See

http://www.artima.com/intv/goldilocks3.html

To quote….
Bjarne Stroustrup: Yes. If every data can have any value, then it doesn’t make much sense to have a class. Take a single data structure that has a name and an address. Any string is a good name, and any string is a good address. If that’s what it is, it’s a structure. Just call it a struct. Don’t have anything private. Don’t do anything silly like having a hidden name and address field with get_name and set_address and get_name and set_name functions.

Also see http://www.adam-bien.com/roller/page/abien?entry=encapsulation_violation_with_getters_and

http://groups.google.com.au/group/comp.lang.c++.moderated/browse_thread/thread/536e3222ebd3194b/905ee0b1c01d996e?lnk=st&q=setters+getters+C%2B%2B&rnum=2&hl=en#905ee0b1c01d996e
From here, to quote…
OO design is about behavior. Classes should tell others what to do. If a
class takes data out of another, manipulates it, and puts it back in, then
the behavior is in the wrong class.

Also

http://groups.google.com.au/group/comp.lang.c++/browse_thread/thread/5dba6a150b57f2e5/6ec261ae12fbcbe4?lnk=st&q=setters+getters+C%2B%2B&rnum=9&hl=en#6ec261ae12fbcbe4

And

in

http://groups.google.com.au/group/alt.comp.lang.learn.c-c++/browse_thread/thread/ea05e439d14694f8/e7b5940bb3f8d304?lnk=gst&q=getters+setters&rnum=2&hl=en#e7b5940bb3f8d304

Sorry if I flooded you with references, but I still think we are violating the spirit of Item 42…

What I would agree doing is

i. we get a value

ii. Do a lot of manipulation

iii. set the result/value etc…

But most of the above code does not do any of these ;-)

Sorry for the longish mail …. While trying to support my argument, I surely came upon some very good articles on the net ;-)

Also … http://www.ddj.com/dept/cpp/184401805

What do you think?
— cheers atul

Peter Dimov wrote:Dear Atul,

I continue to insist that NodeAddress does not qualify under Item 42. Item 42 explicitly states that exposing handles or pointers or references to the internal representation is bad as the state of the object can be modified outside of the control of the object. Returning copies is a totally different story! Setters and getters are there to implement properties and properties are a perfectly valid OO concept. We can change the internal representation and still keep the properties the same. In that case only the setters and getters will become more complex as to make the conversions to/from the internal representation. IMHO you are exaggerating the scope and effect of Item 42 to copies of internal representation as copies can be modified but the internal state will not be affected.

You suggest that objects better be asked to perform services. I generally agree but in the very case of NodeAddress we have a class that encapsulates data and not services.

Pleas let me know what you think about that.

I’ll read again about feature envy and will try to justify my opinion why Private should be considered a part of the public class and why it should not necessarily have class look and behavior of its own.

Best regards,

Peter