Win a copy of Modern JavaScript for the Impatient this week in the Server-Side JavaScript and NodeJS forum!

Matts Smith

Ranch Hand
+ Follow
since Feb 03, 2001
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Matts Smith

This is the point I'm trying to prove day in day out! OOAD is meant to be simple.
[ January 15, 2002: Message edited by: Matts Smith ]

Originally posted by Pho Tek:
I read somewhere that you should let your domain model dictate the database model; not the other way round.

This is in an utopic world. In the real world most companies already have a database designed. Unless you start from scratch, you definitely have to consider the DB design
Simple question/simple answer.

Originally posted by Ilja Preuss:
Interesting - could you elaborate on this? Where did the problems emerge?

Basically, when the application persisted the data in the database, since the object model was so far away from DB design the persistence classes where not cohesive and tightly coupled. It led to maintenance nightmares. The architect got fired on that particular project... In practice, read-only data (lookup tables) should be accessed by cache objects (see Grand98 page 251) and work tables by EJBs because of easy transaction management (no entity beans please) whenever possible. My favorite way of doing it is SLSB calling DAOs. It might lead to poor design over time but in the project I've worked in it never got close to unmanageable. this is on 150+ tables in a schema.

I hope you didn't want to imply that your object model should be driven by database design

I've seen projects with so called top-notch object models fail because they were not taking into account the DB design. On the other hand the fastest app I've seen was using a 1to1 mapping between DB and object model.
I'm not saying a 1 to 1 mapping is always good. Still you need to consider DB design when modeling your objects. especially with work tables since you need to persist them.
I think the best book to clear 486 is Larman's. I scored 81% back in the days. Be sure you understand his GRASP patterns. Some say it's BS but I think it's essential when it comes to design cohesive objects.

Originally posted by Andron Dre:
But they never said about scalability and pooling.
So by accessing it without ejb, we are loosing all scalability.

Hi there,
First pooling is provided by the appserver, not only to EJBs but to all other layers. About scalability, I think the first step to have a good scalability is to have "efficient" code. the reason why fast-lane is better (even if in theory EJBs scale better because they can be easily distributed) is that the code is WAY faster without EJBs. Also you can easily distribute servlet engines, which would bring scalability.
hope it answers your question
From the 2nd article

need I say more? cough cough

And often harder to maintain, because of less encapsulation.

I don't get it. Why would it be less encapsulated if it's static?

Originally posted by Ilja Preuss:
That seems to be the wrong question to me. The more interesting question is: When do you see all static classes, when singletons?

you got a point there. Requirements drive software.

Originally posted by Alan Shalloway:
Actually, the essence of a singleton is controlling the construction of the object. protected will work just fine for that so inheritance will work.

quote from design patterns in java volume 1 by Mark Grand page 129.

To enforce the nature of a singleton class, you must code the class in a way that prevents other classes from directly creating instances of the class. The way to accomplish this is to declare all of the class' constructors private.

There is one other case I can think of, using a singleton can potentially control the order of when the object is instantiated better. With static methods, the static members will be instantiated the first time the class is referred to. This may be a reference to some const in the class. In the singleton pattern, it won't be instantiated until the getinstance is called.

getInstance is static. same as any other static method. please refer to JLS 5.3 if you would like to understand how and when classes are loaded. Unless what you meant is that your singleton implemented an interface (did I say to do it as a singleton?) and use the interface to access a singleton, which would be "gotten" in another class. Then again the load ordering differences would be minimal. And if you depend on that you know you're in trouble.

Originally posted by Ilja Preuss:
The point of the singleton pattern ist to hide the detail that there is only one instance.

fine so far. Static = no instance at all which is even better when you think about it.

In fact, getInstance() could give you a new instance each call, or alternate between two instances or...

I would not call it a singleton anymore. this is an instance pool. The subject at hand is singleton.

Also, using the singleton pattern you can still use polymorphism, that is getInstance() could give you an instance of an other (sub-)class (depending on some configuration, for example).

maybe I wasn't clear enough but when I talked about implementing an interface I kind of accepted that anything that had to do with inheritance has to be implemented as a singleton. Also don't forget that a singleton constructor is private so inheritance from the singleton is not possible. Gotcha there right?

Therefore, an all-static class is not a substitute for a singleton![/B]

My bottom line is that all static methods is a good substitute for singletons. less code, easier to understand. Look at the JDK. How many singleton do you see compared to all static classes?
off hand I see Runtime. I might be wrong but I guess java.lang classes can't be loaded twice which would not be the case with user's classes. Anyone can give a confirmation on this?

Originally posted by Wilfried LAURENT:
It depends on what you want to achieve.
With the singleton implementation, you can hide the real implementation of your service. The client only knows the contract (API) but does not know about the implementation. This is easily configurable with a bridge or a property file.
You can not do that with a 'static method' implementation.

I might miss the point but what is so hard to do with static methods? And what's that service part about? Please elaborate.
from server to client? hmmm?
begin irony;
There is a real tricky way but it is coded in HTML. look
<a href="file.txt">click here</a>
as you can see it is not an easy task to do it
end irony;
if you mean client to server then go there for some tool
18 years ago
I agree case 1 is better most of the times. The only reason I would use case 2 is when my object has to implement an interface.