JavaWorld Forums: procedural versus object oriented thinking

The example "If X was an int, but now must be a long" causing compile errors is a bit contrived. It would cause a problem because it is a primitive value rather than an object. If X was an Account, and the Account implementation changed that might not be a problem at all due to encapsulation of Account. Also the reference to getters and setters implying procedural thinking is also a bit contrived. They "can" be used procedurally (see below), however use of getters and setters do not "imply" procedural thinking. In a situation where you are trying to "convert" a procedural thinker to an object-oriented thinker you should rightly watch out for examples of procedural thinking - but a getter/setter can be used without breaking encapsulation rules. Take the example where we have a getAge() method that returns an int. The object that owns the method might have a "birth date" attribute and calculate the age when invoked, so use of a getter or setter does not necessarily mean that you are accessing or updating an attribute directly and breaking encapsulation. Public attributes definitely break encapsulation as you are exposing the implementation. Getters and setters can also hide other information such as persistence (e.g. distributed objects, caching etc.), behavior delegated to another object and so on. Public attributes supply none of this behavior of course. In summary, the thing to avoid is using an object as a simple state container, externalizing behavior related to that state (procedural thinking), and using getters/setters to read or modify the state.

InfoWorld: Modernizing IT

JavaWorld: Solutions for Java Developers