Class design question
I'm relatively new to OOP programming, so please excuse this newbish question :).
I've been assigned to take over for a co-worker that has left for vacation. A class that he wrote is partially implemented, so I'm supposed to finish it up.
One class in particular, his constructor is empty. And to set the instance variables, the user class is setting them directly, not through accessor methods. This seems like a bad idea, and defeats the whole purpose of encapsulation.
I wanted to re-do some of the code, but are there any good reasons as to why he might be doing this? Saving some overhead maybe?
> I'm relatively new to OOP programming, so please
> excuse this newbish question :).
>
> I've been assigned to take over for a co-worker that
> has left for vacation. A class that he wrote is
> partially implemented, so I'm supposed to finish it
> up.
>
> One class in particular, his constructor is empty.
That's fine, if that's what makes sense. I'd have one constructor that set all the private data members. Other constructors would call it using sensible defaults where needed.
If the ctor is empty and data members are null, that's very bad. An object should be 100 percent ready to go when you create it.
> And to set the instance variables, the user class is
> setting them directly, not through accessor methods.
So the data members are public? Oh, my. Where's the encapsulation?
> This seems like a bad idea, and defeats the whole
> purpose of encapsulation.
Indeed. Sounds like you know more than your co-worker.
> I wanted to re-do some of the code, but are there any
> good reasons as to why he might be doing this?
If it's a DTO C-struct with no other purpose than ferrying data it might be acceptable. I would say it's not acceptable, but that's my opinion.
> Saving some overhead maybe?
No, the "overhead" is probably not measurable. I wouldn't optimize such a thing without data that told me it was the bottleneck, and I'd make sure that this "fix" did address the problem before I cast it in stone.
%
