Best Practice Question: Should You Have Getters and Setters for Private Properties in a Component?

Thanks BKBK for the insight.

I definitely agree with you and have a rule for myself to only create getters/setters if the property is public.  The only exception to this rule would be for any private property that needs to have some other behavior or validation occur when set.  In the case of the latter, I make sure the setter/getter is private as well so it is not exposed.

e.g. Public Properties:

// public getter
function getName() {
     return variables.name
}

// public setter
function setName( required value ) {
     variables.name = arguments.value
}

e.g. Private Properties

// no getter/setter needed for something like a dependency class
function init( required privateDependency ) {
    variables.privateDependency = arguments.privateDependency;
    variables.privateDependency.doSomething();
}

// setter needed for private property that needs to do something when set
private function setPrivateValue( required value ) {
     // perform validation or do something magical
     ...

     // set it to the variables scope
     variables.privateValue = arguments.value;

}

Homestar9 wrote: Now, when you're working inside the component, is it considered best-practice to have getters and setters for private properties even when they will never be exposed outside of the component?

No. Object-Oriented Design best-practice says "private remains private (the rule), unless you are compelled to expose (the exception)". That's encapsulation or information-hiding. The "unless" means that getters and setters are optional.

It seems to me that if you don't use getters/setters for private properties, you wind up with  potentially much leaner code (if you have a lot of private properties). However, I'm not sure if this way of doing things violates some best-practice rule of OOP.

Not exposing any private properties via getters and setters is actually best-practice. You introduce getters and setters only because you must. And you restrict the getters/setters only to those properties which the caller requires to use the component. That is the principle of encapsulation.

I would think of it this way. As component or class, I am the server or service. Whoever invokes my methods is the client.

Now, think of the client as someone at the other end of the telephone, asking questions. Then it may be necessary to enable the client to

getFirstname ()

or even to

getLastname().

Will you allow them to

getAddress()?

getDateOfBirth()?

getSSN()?

Were they to ask me such, I guess my answer would be "And a nice day to you, too.".

I agree with you on the bit about having leaner code without the getters/setters.  And I'm not sure if there is any best-practice violation by not using them.  However, I will say this:

I took over as lead developer where I work, and the previous lead has been pissing me off for years even though he's no longer here.  Why?  Well, because he discovered ColdFusion Builder and it's ability to point to any DNS in CFAdmin and create CFCs for every table that all have getter/setter.  It has created what I refer to as "Celtic knot" processing because it creates a Gateway, DAO, and bean for every table, and they all become involved for every transaction.  The old site (we recently updated) contained (I'm not kidding) 3500 files (.cfm, .cfc) partly because we had so many tables in our database.

The updated site contains less than 200 cfm and cfc files beause I manually created only what we needed, and I'm only putting bare minimum code in our components.  I feel like the site processes faster without all the get/set stuff.

But that's just my opinion.  I don't have numbers to back that up.

V/r,

^ _ ^

PS.  I don't like MVCs, either.  Complexity for the sake of being complex.