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 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.

What works, AFAIK, is the design which evolves. As you rightly put it, there are many options… And the more you keep refactoring ( tinkering?;-), the right design comes out…( right design is a bit subjective term ;-)

this is what XP advocates.
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.

Yes I love that… It is a neat thing to have ;-)
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.

I have had similar experience… Nowadays, I would settle down with a simple design that works… and then refactor and weigh and look at what is more elegant/natural fit…

I am looking into

bool PacketModel::insertPacket (const Packet *packet, Direction direction)

and here packetInfo should be generated by Packet… This goes by the name of “FACTORY METHOD” pattern…
Incidentally, I was skimming thru “C++ Common Knowledge” and one item gives a very similar example… ;-) 

Now I think that is a right way to extend Packet. And follows that above idiom so I feel I am going in the right direction…

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:
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 (more...)

Follow-ups:
Re: Re: Re: Getting rid of setters/getters?
Hi Atul, You are again making a good point, this time about how and who generates this PacketInfo struct from a Packet object. Your way of thinking complements with what I (more...)