Kristen Nygaard, father of object oriented programming and the Simula programming language focused in his lectures on how to use objects to model the behavior of the real world and on how objects interacted to get a piece of work done. His favorite example was Cafe Objecta, where waiter objects served the appetites of hungry customer objects by allocating seating at table objects. The model consists of interacting objects passing complex messages in terms of menu and order objects to fulfill each others needs.

+

Kristen Nygaard, father of object oriented programming and the Simula programming language focused in his lectures on how to use objects to model the behavior of the real world and on how objects interacted to get a piece of work done. His favorite example was Cafe Objecta, where waiter objects served the appetites of hungry customer objects by allocating seating at table objects, providing menu objects and receiving order objects.

-

In this type of model we will find a restaurant object with a public interface methods such as <code>reserveTable(numberOfSeats,customer,timePoint)</code> and <code>availableTables(numberOfSeats,timePoint)</code>, object interfaces that reveal each object's intent and responsibility in terms of the domain of a restaurant.

+

In this type of model we will find a restaurant object with a public interface methods such as <code>reserveTable(numberOfSeats,customer,timePoint)</code> and <code>availableTables(numberOfSeats,timePoint)</code> and waither objects with methods such as <code>serveTable(tableNumber)</code>, object interfaces that reveal each object's intent and responsibility in terms of the domain at hand.

So, where are the ''setters'' and ''getters'' so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility.

So, where are the ''setters'' and ''getters'' so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility.

-

Some might then argue that we need setters to support ''dependency injection'' a.k.a. ''inversion of control'' design principle. Dependency injection provide reduced coupling at development time, making unit testing easier as an object can be tested using a mock-up of a dependency. At the code level this mean that the code <code>Table table = new TableImpl(..);</code> can be replaced with <code>Table table;</code> and then initialized from the outside at runtime.

+

Some might then argue that we need setters to support ''dependency injection'' a.k.a. ''inversion of control'' design principle. Dependency injection is a good thing as it provide reduced coupling and simplified unit testing as an object can be tested using a mock-up of a dependency. At the code level this mean that code such as <code>Table table = new TableImpl(..);</code> can be replaced with <code>Table table;</code> and then initialized from the outside at runtime.

-

The answer to that is that you do not need setters for that. Either you use the constructor or even better, create an interface in an appropriate package called <code>ExternalInjections</code> with methods prefixed with <code>initializeSomeAttribute()</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle.

+

The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called <code>ExternalInjections</code> with methods prefixed with <code>initializeSomeAttribute()</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.

-

So what about the ''getters''? I think personally you are better of just referring to the actual attribute, using methods such as <code>price()</code>, <code>name()</code>, and <code>timePoint()</code>. Methods that return attributes are by definition functions and therefore such ''getters'' read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code>.

+

So what about the ''getters''? I think personally you are better of just referring to the actual attribute, using methods such as <code>price()</code>, <code>name()</code>, and <code>timePoint()</code>. Methods that return attributes are by definition functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code>.

-

The conclusion on this is that setters and getters are alien constructs that do not reveal the intention of a behavior-centric interface, and therefore you should avoid using them.

+

The conclusion on this is that setters and getters are alien constructs that do not reveal the intention of a behavior-centric interfaces reviling the objects intent and responsibility. Therefore you should avoid using them, there are better alternatives.

-

+

-

TO BE COMPLETED

+

By [[Einar Landre]]

By [[Einar Landre]]

Revision as of 16:23, 22 October 2008

Kristen Nygaard, father of object oriented programming and the Simula programming language focused in his lectures on how to use objects to model the behavior of the real world and on how objects interacted to get a piece of work done. His favorite example was Cafe Objecta, where waiter objects served the appetites of hungry customer objects by allocating seating at table objects, providing menu objects and receiving order objects.

In this type of model we will find a restaurant object with a public interface methods such as reserveTable(numberOfSeats,customer,timePoint) and availableTables(numberOfSeats,timePoint) and waither objects with methods such as serveTable(tableNumber), object interfaces that reveal each object's intent and responsibility in terms of the domain at hand.

So, where are the setters and getters so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility.

Some might then argue that we need setters to support dependency injection a.k.a. inversion of control design principle. Dependency injection is a good thing as it provide reduced coupling and simplified unit testing as an object can be tested using a mock-up of a dependency. At the code level this mean that code such as Table table = new TableImpl(..); can be replaced with Table table; and then initialized from the outside at runtime.

The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called ExternalInjections with methods prefixed with initializeSomeAttribute(). Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.

So what about the getters? I think personally you are better of just referring to the actual attribute, using methods such as price(), name(), and timePoint(). Methods that return attributes are by definition functions and read better if they are direct: item.price() reads better than item.getPrice().

The conclusion on this is that setters and getters are alien constructs that do not reveal the intention of a behavior-centric interfaces reviling the objects intent and responsibility. Therefore you should avoid using them, there are better alternatives.