Re: Getting rid of setters/getters?

Hi Atul,

I see your point how setters and getters can hurt encapsulation and I agree with you that one should be careful what part of the object’s state should directly be modifiable from the outside.

I’m not sure however, to what extent we should take these concerns into consideration for that specific case. I have the feeling that the class Packet encapsulates mostly data – the contents of a Gnutella packet. The only state a packet object has, in my opinion, is whether it is validly parsed or not and this cannot be modified from the outside.

I was actually asking myself that exact question when I was designing the Packet class. Getters are necessary in any case to extract the data. If we had a bigger number of overloaded ctors we wouldn’t have needed the setters. I felt however that would lead to an excessive number of ctor, which would make the class interface and implementation more complex and less flexible.

Generally, the approach I took with Packet and its derived classes was to keep it as simple and generic as possible by having it know as little as possible about the different context where it can be used. My personal preference is to build up complexity by stepping on simpler and more generic concepts, instead of stuffing a hell lot of things in a presumably “clever” object. If Packet were cleverer, it would have needed to know all about GGEP extensions (we have only implemented about eight of probably more than twenty), probably about QRTs, metadata. Now, that’s maybe an extreme, but just to get my idea.

I’m open for any more specific proposal!

Thanks,

Peter

atul wrote:Dear all,

This is one of the two design points ( the other is about Null Objects ), that were coming nagging at my mind ;-)

I think giving set/get harms encapsulation ;-) Some code could erroneously set only one of them and take the object in a wrong state ( One way to look at objects is that they model states ;-)

Instead, I think we should look at what the outside code is doing with these get / set and

remove these set / get

push that operation to the object ( it could internally use setters / getters and always maintain a coherent state )

Some Get operations are ok ( like name() ) but things like setTtl()/ttl() maybe are not, IMHO ;-)
What do you all think?

—- cheers atul

Would you like to post a relpy?


This post is a reply to:
Getting rid of setters/getters?
Dear all, This is one of the two design points ( the other is about Null Objects ), that  were coming nagging at my mind ;-) I think giving set/get harms encapsulation (more...)

Follow-ups:
Re: Re: Getting rid of setters/getters?
My replies in bold ... Peter Dimov wrote: Hi Atul, I was actually asking myself that exact question when I was designing the Packet class. Getters are necessary in any case to extract (more...)