SELECT ARRAY_TO_STRING(ARRAY_AGG(SUBSTR(A.chars, (RANDOM()*1000)::int%(LENGTH(A.chars))+1, 1)), ”)
FROM (SELECT ‘ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%*’::varchar AS chars) A,
(SELECT generate_series(1, 6, 1) AS line) B

I think it also solves the problem.

Tested in postgresql 8.4.

`withdraw` and `deposit` it’s setters. All this code can be successfully done in `setBalance` method, almost nothing will be changed. All these checks, comparison – it’s usual work of setters.

Why public fields are evil? Because object can’t control their changing and because they can’t be declared in interfaces. Getters and setters can do it, so it’s perfect tool of OOP.

Accessors can be written silly, of course, but it doesn’t mean that they are evil. Any method in the class can be written silly.

[...] on this front that Berry Langerak puts forward a good case, and where I want to add my two cents worth. Berry attempts to stress that [...]

Great post! Any chance you are doing more on this topic? or should I say style of development?

[...] Excelente artículo sobre si usar o no usar getters y setters para nuestros objetos, y sobre cuando es práctico hacerlo. [...]

> If you fail to see how adding an accessor only when the need becomes
> clear will break an existing API then imagine a situation where your
> team uses a public varible 1000+ times and then you need to alter the
> value they receive based on some dynamic environment.

Agreed: if your team uses a public variable 1000+ times, and they use it and apply logic to it, the brown substance has hit the fan.

> The example is simple because I just wanted to say – nobody(!) ever
> uses accessor methods to move business logic outside an object but
> to achieve different kinds of polymorphism or make it achievable.

I hate to break it to you, but you’re contradicting yourself somewhat. You’re telling me that nobody(!) will ever use accessor methods to move business logic outside of an object, but you’re also telling me your team uses a public parameter to move business logic outside of an object?

> I hope you really meant you are against public properties and not
> against accessor methods. Otherwise the point is senseless, a usual
> programmer does not do what you have explained (and we don’t count
> newbies).

Perhaps not your colleagues, but I see it happening a lot in PHP projects. I’ll try to find some real life examples for you to enjoy.

The example is simple because I just wanted to say – nobody(!) ever uses accessor methods to move business logic outside an object but to achieve different kinds of polymorphism or make it achievable.

I hope you really meant you are against public properties and not against accessor methods. Otherwise the point is senseless, a usual programmer does not do what you have explained (and we don’t count newbies).

> 1 – An accessor method, even if it provides no other domain logic beyond
> returning it’s underlying field data, is a better API design as it protects
> from potentially breaking the API when domain logic must be factored in.
> This is a huge part of iterative development.

I fail to see how adding an accessor only when the need becomes clear will break an existing API. Also, in my book, iterative development also means don’t build today what you may need tomorrow. If you plan ahead for a possible change in the future, you’re planning too much. TDD actually dictates that you should do the simplest thing that works, and refactor afterwards. I’ve done TDD on a few projects, and there were no (unnecessary) accessors to be found. YAGNI++

Apart from that, I still stand by the thought that normal methods still facilitate changes much better than having a bunch of accessors. Part of the success from iterative development is that it facilitates change. OO facilitates change by containing the behaviour in one single unit. All in all, I’m not sure I agree with you.

> 2 – See #1 and ignore it if you are primarily working alone and not in a
> team — also, ignore #1 if you are the only one to ever consume this API.

Breaking your own code would be just as bad as breaking others’ code though right? The only benefit is that you only affect your own code, and you will know what you’ve changed. That’s a plus.

> 3 – Just because you don’t have a need for accessors at the outset doesn’t
> mean you won’t need them later.

And vice-versa: just because you have a parameters, doesn’t mean you’ll ever need an accessor for it — if you keep behaviour in the Unit itself, that is. Mind you, I’m still not trying to bash accessors in general: I’m talking about collaborators that take over behaviour that belongs to another object.

> I also notice (not just here but in a lot of PHP debate articles) a lot
> of comparisons with Java; however, Java is not the only language to utilize
> these concepts we debate.

I’m not comparing to PHP to Java a lot in the article though am I? I merely stated I was introduced to accessors in my Java classes, and that PHP seems to have borrowed the whole “we need accessors for everything”-attitude from Java.

> For instance, Ruby *BAKES* into the language the very thing we are
> debating here.

If that’s what you think we’re debating, I’m afraid we’re not on the same subject. My point is that you should wonder if code actually belongs in class A, if all it does is use data from class B, where class B consists solely of accessors. And yes, accessors create that possibility, which means that when you write them, you’ll want to wonder if you aren’t “Doing it wrong” It may sound rediculous to you, but in PHP, it seems to be a common phenomenon.

> I guess my argument here is that we stop bashing Java and pick on a
> language that can actually defend itself on a more level playing field.
> I would assume that bashing session wouldn’t last very long

I actually *like* Java, so I don’t bash it at all. All the mentions on Java in the comments is because the commenters are Java developers.

Many software do that :

- Listen for HTTP request with HTTP parameters
- Embed theses parameters into a behaviour less object.
- Send this object to the business layer that do nearly nothing but forward it to the access layer.
- The access layer use it to generate a request to the database.
- The access layer put the response to a list of behaviour less objects.
- The business layer get the response from access and transform it to bring it back to the UI
- The UI show it on the screen.

If you really try to understand this pipeline, you see that this design :
- Allow easy changes : UI / Access can be changed with minimal impacts
- Allow good encapsulation : UI can corrupt Access/Business data. And Access can’t corrupt Business/UI data too.
- That this not OOP at all. This is a plain procedural pipeline. This is simply a very good pratice. Not everything fit in an OOP way. Basically in this design, we might use object and interfaces, but we don’t do OOP other that for technical reason and because we do program with an OO language.

Then there is no need at all to use getter/setters. They serve nothing. Public fields are more consise. Using a map can even be a better choice if you don’t mind having type/name information at runtime only. Then your business layer and access layer is reduced to nearly nothing and use 99% the same generic code. (Think about ActiveRecord).

The thing is that theses sort of applications are in reality data driven. The more objects, the more OOP you try to bring in (using ORM with complex class hierachy for exemple), the more complex your project become and the more problems you have. Introducing OOP in this sort of application is just introducing what we call an impedance mismatch.

Why they are data driven ? Because basically all you do is CRUD operations. There is nearly no business. Just a UI and a database. That’s why plain old PHP is so good for that sort of applications/website. You don’t loose time on useless OO design. You design your datamodel instead.

All data intensive applications have the same sort of concern. 3D Video games for exemple. At first using objects everywhere seems good. But then your data are not ordered and aligned in memory. You have lot of cache miss, because you loose spacial proximity. Your graphic card (that is a giant pipeline) rely on spacial proximity and have cache everywhere. What your GPU want is a big array of data. But if you use too much objects, too much new everywhere instead of big array, your performance will be abyssal hurting the hardware.

A good architechture is not something that we choose because we like it, even because it is beautifull, but because it is efficiant and simple.

You should think OO when you really need the concepts. When coupling data and code make sence and really help the modelisation of your domain. When polymorphism bring really something interresting to the table.

There is a hint of the limitations of OOP. A hint that nearly everybody have seen at school. Of course the teacher didn’t speak about them. You guess what is it ? Well it is the examples you are given to understand OOP.

When you are lucky, they give you good exemple like an UI framework (where any specialised widget appear to be a standard widget with a specialized behavior).

But how many time your are given silly exemple ? Like animal that make smell ? Vehicules with it subhierarchy (Car / Plane…) that just have a method that print the noise they make ? Or shape that draw themselves ?

Do you understand what is the real problem about theses examples ? You’ll never have to modelize something like that in most softwares. The best OOP example you are given are simply useless theoretical example that nobody care about in reality.

Well you can have the exemple of the library. And you will modelize it. Just for the fun… Try it to modelize it with a data driven approach (3NF, relationnal databases and all) and try to not espacialy use objects concepts. You’ll see that your design with be perfectly right and efficiant.

In most modern project we don’t use OOP to modelize something real. No. Oh we do use pattern. An abstract factory, a singleton, things like that. We use inheritence to reuse code more than to really modelize a class hierarchy that as sence for the domain.

We use OOP most of the time for purely technical concerns. It is not especially better, it is just that well we have OO languages and that we use what our languages can do.

An interface is basically a glorified header file in C. (And an interface has nothing to do with OO, it has no behaviour). Many objects we use have no behaviour, but just data containers. The pattern we use are here for technical concern. How to be able to mock this service for testing ? How to be able to replace this implementation with another one ? How to ensure that we have only one instance of this thing at runtime ?

OOP is hype. OOP is a buzzword. It is usefull, but overlooked.