This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi, I wonder if all classes on each layer (dao, ejb, entity, view, controller) should have common name endings like Tomasz suggested "ThreadSafetyAdministratorHibernateDAO" or be placed in a meaningfull package and drop the ending like com.myapp.server.dao.ThreadSafetyAdministratorHibernate?
Frankly, I'm undecided on the length of the name. But besides that, I'd think that the name might better be
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
In my honest opinion it really comes down to preference. As long as you are not writing a paragraph for a name you should be fine, I have seen some horrible names in my short time in this field example being doThreadFailAB123 not one person in the whole place knew what it did nor were there any other methods that would indicate a <122 it was just a sad, sad day for me.
Originally posted by Paul Croarkin: Be careful with a name like that unless you can back it up (with tests) to prove that it is ThreadSafe.
I agree that you should "prove" it. (Although I hope that you are aware that tests don't actually *prove* a lot.) But even if you don't, the name would at least communicate intent. When maintaining code, knowing what the code was supposed to do often is even more important than knowing what it actually does. (The latter can always be tried out, the former might be lost forever otherwise.)
;-) Since all classes should be thread safe, I would simply call it AdministratorDAO. I would put the ThreadUnsafe prefix on it if it wasn't thread safe....
That's very interesting. This make me think harder.
1. Yes we do strive to make class immutable.(Implies it is thread safe) unless on is exposing the internal implementation to be manipulated outside it.
2. While that is the case, there are place where we use lot of bean classes which have setters and getters, in these places, we don't make them thread safe, but expect a instance of this created and for each operation, and leave it to the client class handle the threading if it is really required.
3. Let us take instance of java's HashMap, we don't need thread safe instance always. If we have all of objects thread safe, will it not lead to performance problem? We use thread safe version of HashMap only when it is needed. Isn't that we need to think of the usage, while we decide to make any class thread safe or not?
4. Another note on the class name - If the class name is not clear, all i can conclude is, the coder/developer is not clear of what he is doing or has a very poor coding discipline.
Joined: May 20, 2008
Heh Nice discussion but i wrote this class name only for example as a very long name. Probably i could use name "BlebleAbrakadabraSomethingClassName"
Long class names are not a bad practice at all. You just need to make the class name descriptive of what it does, and not make it longer than it should be. If you can name a class clearly using 10 characters, don't use 20. If you need a 100 characters to make it clear, so be it. Don't give it a name of 15 characters because you don't want a long name