DTOs with public final fields

I just read
Why getter and setter methods are evil
and an interesting discussion on this article on TSS

Opinion

I am myself leaning a lot towards using public final variables for a small and simple subsystem. There are no methods and I only need to transfer data in the form of String(s). I could use a String[], but it is easier to read code if I use an object consisting only of public final variables instead.

To mark these objects as 'Data Structures' rather than true objects, I can keep them all in a separate package with a name that clearly indicates that these are not objects in the OO sense.

The use of these objects is limited to a small subsystem, and is not part of a public API that will be used by external systems, so refactoring them to promote these to 'real' objects if needed wouldn't be too hard.

It just seems like the simplest thing that will get the work done, at the moment. What do the ranchers think?

Sonny

In my opinion, if you like it, then it's all good.

Thanks Lasse.

Which is better

A class with all static methods or a singelton for implementing utility function?

Originally posted by Pradeep Bhat:
A class with all static methods or a singelton for implementing utility function?

I usually start with static methods. Then, if I realize that a singleton would be better, I switch.

if no business logic inside, a class with static methods is better.

if there are business logics, singleton seems a better choice.

Nick

Originally posted by Nicholas Cheung:
if no business logic inside, a class with static methods is better.

if there are business logics, singleton seems a better choice.

Nick

What is wrong in putting business logic in static method?

Then, if I realize that a singleton would be better, I switch.

what was the realization?

What is wrong in putting business logic in static method?

Each business object has its own business logic, which should not be stateless. If some processes can be stateless, like data value validation, you may consider to put it in utility class.

Nick

what was the realization?

By 6th sense.

Nick

Originally posted by Nicholas Cheung:

If some processes can be stateless, like data value validation, you may consider to put it in utility class.

Nick

Nick in the above you agreed with having business in static :-). However in a service oriented architecture, you can have stateless business.

./pope

Originally posted by Pradeep Bhat:
A class with all static methods or a singelton for implementing utility function?

Well, often it's best to put the method on a real object...

However in a service oriented architecture, you can have stateless business.

It depends on how your system design.

Personally, I vote for business logic stated with stateful objects.

Nick

What does this have to do with DTOs with public final fields :roll:

What does this have to do with DTOs with public final fields :roll:

Nothing.

I am response to the 4th message raise by Pradeep.

Nick

Originally posted by Pradeep Bhat:
Which is better

A class with all static methods or a singelton for implementing utility function?

If you want to create only one object in all time, you should be use Singleton that it's best guideline or pattern.

But

If you want to use static method , you should be use with Utilities class.

What is wrong in putting business logic in static method?

I think, Static method should be used in Utilities class that better..

What does this have to do with DTOs with public final fields

http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html

Originally posted by Nicholas Cheung:

It depends on how your system design.

Personally, I vote for business logic stated with stateful objects.

Nick

I have to not agree with you this time. In an EJB session layer I would do my best to stay stateless ;-).

./pope

Personally, I vote for business logic stated with stateful objects.

I can have my state in singleton or as static fields in a class which has only static methods.

I have to not agree with you this time. In an EJB session layer I would do my best to stay stateless ;-).

Sometimes can, while sometimes cannot. We certainly need to keep some states for some business operations, especally when we need to adopt the Session Facade pattern.

Nick

I can have my state in singleton or as static fields in a class which has only static methods.

As there is only 1 object, there is only 1 state you can hold.

If the method is accessed by many stateful clients, it is not that easy to maintain their states.

Even you can argue that, the object contains a Vector which holds all states of clients, but it messes up everything.

I feel holding stateful info for multiple objects in a singleton is much more difficult.

Nick

State in static is possible but require much attention in case of concurrent/multithreading environment.

./pope

Originally posted by Nicholas Cheung:

Sometimes can, while sometimes cannot. We certainly need to keep some states for some business operations, especally when we need to adopt the Session Facade pattern.

Nick

How is involved session facades in your application that they require state? Does it mean it is a statefull session facade to other statefull sessions?

./pope