Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
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.

<SpecialServiceAnnouncement>

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,


Posted 01-12-2008 12:59 PM by Derik Whittaker
Filed under: , ,

[Advertisement]

Comments

Nobody Real wrote re: Object Properties, make them public ONLY when needed.
on 01-12-2008 4:30 PM

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.

Derik Whittaker wrote re: Object Properties, make them public ONLY when needed.
on 01-12-2008 4:45 PM

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

Wojciech Gebczyk wrote re: Object Properties, make them public ONLY when needed.
on 01-12-2008 5:46 PM

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!

zambodi wrote re: Object Properties, make them public ONLY when needed.
on 01-13-2008 1:59 AM

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

RedGreenRefactor wrote re: Object Properties, make them public ONLY when needed.
on 01-13-2008 9:55 AM

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.

Wojciech Gebczyk wrote re: Object Properties, make them public ONLY when needed.
on 01-13-2008 11:15 AM

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?

RedGreenRefactor wrote re: Object Properties, make them public ONLY when needed.
on 01-13-2008 11:40 AM

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.

Peter Ritchie wrote re: Object Properties, make them public ONLY when needed.
on 01-14-2008 11:43 AM

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.

Eber Irigoyen wrote re: Object Properties, make them public ONLY when needed.
on 01-14-2008 1:30 PM

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

Derik Whittaker wrote re: Object Properties, make them public ONLY when needed.
on 01-14-2008 1:41 PM

@Eber,

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

Wojciech Gebczyk wrote re: Object Properties, make them public ONLY when needed.
on 01-14-2008 4:04 PM

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" ;-)

Derik Whittaker wrote re: Object Properties, make them public ONLY when needed.
on 01-14-2008 4:13 PM

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

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)