Design Patterns

[Pieter Jacobs]

Hi guys,

When using Design Patterns, do we use a Design Pattern for the Client, and a Design Pattern for the Server; or do we use a few different Design Patterns within the same "thing" (e.g. Server, Client, etc.) ?

I hope this question make sense!

Is it correct to use a Singleton Design Pattern for a Utility class?

Have fun!
Pieter

[Roberto Perillo]

Howdy, Pieter!

Champion, you may use design patterns if you think it is necessary for your solution. The thing is, you don't have to apply a design pattern just to say that you are using design patterns. For the client, some people choose to use Observer (even though it is not required). For the server, some people choose to apply the factory pattern to RMI.

It can be correct to use a utility class as a singleton, it just depends on your solution! I myself made the Data class a singleton.

[Andrew Monkhouse]

I think you should use the design patterns that you feel are right for the job at the point where they fit naturally. Don't get worried about whether you have a design pattern in a particular section of your code or whether someone else has used a design pattern that you have not used - if it is not right for you, don't use it.

In my mind, design patterns have 2 primary functions:

They give us a shorthand way of describing a bit of code. Roberto mentions that some people use the Observer pattern in the client, and I know instantly what he is talking about: no need for 3 or 4 paragraphs describing what the code does.

They can provide us with a way of thinking about how we might write our code. If I were writing some client code, I might think about whether I want the View to be automatically notified whenever the Model is updated, and immediately realize that I am talking about the Observer pattern (while using the Model-View-Controller pattern!), and that helps me think about what sort of code I want to write to enable this functionality.

The one thing I don't do is start by saying that I am going to develop some software and I am going to use pattern 'x' - it is too constraining for me. If I force myself to do this, I could end up writing some ugly code just to force that particular pattern into the program, rather than developing an optimal solution.

To give an analogy - if you were told that you are going to build a house, and you decide you are going to use a hammer and nails. But what happens if the cheapest materials are bricks? Do you force the use of a hammer, thereby going with the more expensive wood solution? Or do you somehow try to use the hammer and nails to hold the bricks together?

[Roel De Nijs]

Hi Pieter,

For a real utility class I think singleton design pattern is a bit overhead. There are many examples of utility classes in different open source projects (and where you can take a look at the code), for example BooleanUtils.

I see your other question is already been answered by the Great King of Brasil and God himself

Kind regards,
Roel

[Pieter Jacobs]

Hi guys,

Thanks a lot for the feedback - I really appreciate all the ideas etc.!

Thanks,
Pieter

[Fernando Franzini]

hi Pieter

Is it correct to use a Singleton Design Pattern for a Utility class?

In my opinion no. Cause utility class is when you created some class with methods that dont managed object state, i.e. you dont need instantiate object and preserve stated. So...because of this that we usully created utility class with all static methods. Now...DP singleton advocates the object states...but you just control the number of instances...that is one ! So...singleton and utility class dont make sense mix together.

[Roberto Perillo]

Roel De Nijs wrote:I see your other question is already been answered by the Great King of Brasil and God himself

And who is the Great King of Belgium?! That's my good buddy Roel!!!

[Jeffry Kristianto Yanuar]

In my assignment I used Facade and MVC design pattern. I also using business object design pattern.


Jeffry Kristianto Yanuar SCJP, SCJA, SCJD

[Pieter Jacobs]

Hi again,

1- Thanks; so one would rather create a Utility class and make all methods static and prevent people from instantiating the class ?

2- Ps: I went out and bought myself the book: "Head First Design Patterns" and what an excellent book!!!

3- As I could gather from all of your guys' responses and what I read from this above mentioned book; the Singleton Pattern could work perfectly for a class that purely reads something from a Properties File instead of reading the Properties file every single time someone uses it ? ( your feelings ? )

Enjoy!
Pieter

[Roberto Perillo]

Pieter Jacobs wrote:the Singleton Pattern could work perfectly for a class that purely reads something from a Properties File instead of reading the Properties file every single time someone uses it ?

There you go! I don't have my code here right now, but as far as I can remember, I did exactly that!

[Fernando Franzini]

Hi Pieter

1- Thanks; so one would rather create a Utility class and make all methods static and prevent people from instantiating the class ?

Actually, you dont need worry about instantiation class when they have static resourses.....the programer should be aware how to use it. But answering your question...you can set private constructor that prevent instantiation out site of the class....but you dont need do it for any "utility class"

2- Ps: I went out and bought myself the book: "Head First Design Patterns" and what an excellent book!!!

Yeahh...any head first book is amazing.....I've read all about java.

3- As I could gather from all of your guys' responses and what I read from this above mentioned book; the Singleton Pattern could work perfectly for a class that purely reads something from a Properties File instead of reading the Properties file every single time someone uses it ? ( your feelings ? )

What justified the patterns use, it your "motivation"...and motivation behind Singleton is have "just one object". Answering your question: yeah....singleton fix here....but you still build a class to managed this situation without use singleton.

[Pieter Jacobs]

Hi Roberto,

Excellent; will I then do the actual reading of the properties file in the "getInstance" method, or within the private constructor?

Thanks,
Pieter

[Roberto Perillo]

Howdy, Pieter!

As far as I can remember, here's what I did: in my getInstance() method, if the Properties class variable is empty, then I read the file; otherwise, I just retrieve properties from there. My private constructor is empty.

[Pieter Jacobs]

Hi Roberto,

Thanks, that was what I thought. Thanks !!

Enjoy!