in Search

Do you Twitter? Follow us @devlicious

Derik Whittaker

Thoughts on Software Development, .Net, OOP, Design Patterns and all things cool

IOC(SM):MOC(RM):TDD(NU):SCC(Svn):ORM(L2S):XPP(-):XPP(+):DDD(T+)

Object Properties, make them public ONLY when needed.

Sorry we have interrupted your daily blog reading, but we have a special service announcement for all developers.

Only make properties public on an object when you KNOW they are needed. Please make all properties private by default.

If you need to access the property from outside your object, make the getter public and leave the setter private.

Only open up the setter when you KNOW it is needed, this should be a last resort option.

</SpecialServiceAnnouncement>

Till next time,

Published Jan 12 2008, 12:59 PM by Derik Whittaker

Filed under: Opinion, Best Practice, Rant

Comments

Nobody Real said:

I think you should qualify your comment. This is a rather selfish and greedy way of writing software, and basically is an excuse to not analyze the use cases for your objects.

Let's say you work for a company that has a lot of internal re-use. You create a "customer" object. That object may get re-used by others. But, using your rule, it will mean anyone doing anything with it that i'm not has to override the object and create their own getters and setters. That's just wasteful IMO.

Unless you're a one-man, or one product company, i can't really see the benefit of doing this, unless the object is VERY specialized and has no chance of being re-used, in which case the likelihood of someone else coming along and tampering with it seems small.

# January 12, 2008 4:30 PM

Derik Whittaker said:

@Nobody

As a rule, everything should be private and NOT exposed until it is needed. I have no objections making anything public, but ONLY once there is a need established.

If you make things open and public by default you are opening yourself up to trouble.

# January 12, 2008 4:45 PM

Wojciech Gebczyk said:

I would rather agree with nobody.

Example:

Some time ago I've created some component. This component exposed ONLY what was needed to finish some app. After a year it appeared that additional attributes of this component should be exposed as it can be used by some newer application. I had to expose those properties, check them, ect.

Generally speaking, there is nothing wrong with your statements. The only nuance is with "as needed". Under this phrase there could be A) "as using app needs and nothing more" OR B) "as all company/suite/division/ect app could need".

Let me dissect/analyze you statements under both conditions:

A) In such case those statement are rather not useful. For example if you are creating let's say reader of some log files. Log file has 20 attributes/columns with well known structure and values, but your current needs will use only 3 of them. If additionally such log files are rather common/handy/ect then it is high probability that there will be at least on app in future that will try to read log file, it is justifiable to expose ALL 20 attributes not only those 3.

B) In this case I perfectly agree with your statements, but... they are nothing new as this is (I could say) one of the principles of code/component/functionality reuse.

BTW: Of course I agree that exposing not wanted elements can break component in future, but that's why smart developers are hired to THINK ahead and MINIMIZE such accidents.

Regards!

# January 12, 2008 5:46 PM

zambodi said:

I'm curious, what brought this on? I've experienced a time when asking a young developer (fresh out of college) to build a component that I could use as a DAL swiss army knife for my datagrid. When the tool began to have serious problems I wanted him to expose the SQL property for troubleshooting... He insisted that his extensive programming experience taught him not to expose such properties (even as readonly). I informed him otherwise, in my situation; however he was still reluctant. Odd I would say, as I was his boss. It cost me about 20 hours worth of troubleshooting time, just waiting for him to fix the darn thing and finally expose the property so I could fix my code. He no longer works for me.

My opinion: If the method is benificial to the production of another developer and it will not hose up how the object should operate, then expose. Most times we should write to make sure that invalid use of a method isn't allowed.

Thoughts?

-Zam

# January 13, 2008 1:59 AM

RedGreenRefactor said:

I agree Derik. If you don't need it, don't build it. YAGNI. Why make something public if there is no need for it. Build what you need, not what you think you need.

# January 13, 2008 9:55 AM

Wojciech Gebczyk said:

RGR: you are using again ambiguous "you need". Please write what you mean writing "need". Without such clarification your statements are of class "It's good when it's not raining". Because everyone can substitute "need" to anything that is true for person, then such statements are simply not falsifable. I think that I don't have to argue you low value of such class of statements. Right?

# January 13, 2008 11:15 AM

RedGreenRefactor said:

Hi Wojciech. With need i mean. If it is not used publicly, or not used at all because someone just always uses a public setter and getter. If that's the case then i get rid of it. Imho all code has to be justifiable to the user stories and their scenario's.

# January 13, 2008 11:40 AM

Peter Ritchie said:

It's a pretty basic design tenet: design something for how it will be used. If you don't have a use case for accessing a property of a class then it won't have a public property. If you don't have a use case for changing that property it won't have a setter.

Derik's advice is sound. It's impossible to write a class that can account for every possible scenario, so it should concentrate on the scenarios it knows about and try to limit its use to those scenarios. Simply adding a setter because it might be needed someday is not very responsible.

# January 14, 2008 11:43 AM

Eber Irigoyen said:

been there done that... you got yourself in a religious battle

# January 14, 2008 1:30 PM

Derik Whittaker said:

@Eber,

That is fine. Everyone has to believe in something, even if they are wrong :)

# January 14, 2008 1:41 PM

Wojciech Gebczyk said:

Good point Eber!

When I see those "You should do this!", "There is tenet!", "YAGNI", "agile", ect. It seems to be one of those zealousness fanaticism...

We will wait 2-3 years and new "religion" appear as "one true dev methodology" ;-)

# January 14, 2008 4:04 PM

Derik Whittaker said:

@Wojciech

The origin of this post was that i was trying to make changes for a new feature. The change required me to change out one property for another. But since the property i needed was public in some places, as well as being required by the constructor i had to hunt high and low to see where the value could be changed.

Personally, I feel that if something does not need to be exposed based on the intent of the author, don't expose it. If another person somewhere down the road needs something exposed, then feel free. But do it with the understanding of what you are doing.

Blindly making everything public means that there is NO thought put into WHY it is public.

# January 14, 2008 4:13 PM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?

Enter the numbers above:

Add

About Derik Whittaker

Derik is a .Net Developer/Architect specializing in WinForms working out the northern suburbs of Chicago. He is also believer and advocate for Agile development including SCRUM, TDD, CI, etc.

When Derik is not writing code he can be found spending time with his wife and young son, climbing on his bouldering wall, watching sports (mostly baseball), and generally vegging out.

Derik Whittaker

Object Properties, make them public ONLY when needed.

Comments

Nobody Real said:

Derik Whittaker said:

Wojciech Gebczyk said:

zambodi said:

RedGreenRefactor said:

Wojciech Gebczyk said:

RedGreenRefactor said:

Peter Ritchie said:

Eber Irigoyen said:

Derik Whittaker said:

Wojciech Gebczyk said:

Derik Whittaker said:

Leave a Comment

About Derik Whittaker

Our Sponsors

Proudly Partnered With

This Blog

Syndication

Recent Posts

Tags

News

Blogs I Read

Current Readings

Links

Archives