Hello everyone,
I have always seen some methods are described as "best practice". I am wondering what means "best practice", an algorithm?
Thanks in advance,
George
Can you post an exaple of where "best practice" is used?
Thanks OurNation,
Can you post an exaple of where "best practice" is used?
There are many examples. For example, you can search "best practice" in http://java.sun.com, and you can find many of them.
regards,
George
Probably whatever is the most efficent...Like if you have a small program that could be accomplished with an iterative loop, it would NOT be good practice to use recursion.
Anyone know of some simple best practice lists somewhere? Searching the sun link above is a bit blinding.
Here is a simple issue which new Java programmers meet quite quickly...
If I write a class that will be instantiated ONLY once is it best practice to put most of the initialisation code in the initialiser block or in the constructor?
In many cases there is loads of code that would work in either position because it is pre-configuring instance variables before they are used or displayed.
For trivial classes this doesn't make much difference but as classes grow it gets more important to have a clear structure or sequence for the initialisation code.
This ref covers some useful basic stuff on layout.
http://java.sun.com/docs/codeconv/CodeConventions.pdf
Umfortunately it doesn't extend to my initialisation code issue et al.
Anyone have a link to something that takes it a bit further?
If the class only needs to be instantiated once, does it need to be instantiated at all? Why not use static methods? My personal preference is to avoid adding object-orientation that doesn't have to be there - it makes everything seem cleaner, somehow. This also takes care of the constructor vs init method issue - if there's no instantiation, there's no constructor.
Just a thought.
Static methods are not OO, and therefore not recommended by good OO approaches (which are best practice).
That's not to say they don't have their uses, but in strict OO design you will not find them.
At most some singletons and methods which have no instance specific functionality may be turned into static methods at some point if such yields superior performance.
Of course in reality that's often factored into the design as people get experienced enough to make such decisions at an early stage, but it's only the absolute beginners who make everything static, effectively abandoning OO altogether.
Thanks. Looks like it's the constructor. I understand that design patterns also indicate this although I'm unsure how to check that one out.
Buy yourself "Head First Design Patterns" by Eric and Elisabeth Freeman (0596007124).
It's an excellent book that explains not just the patterns but why and how to use them.
I knew the basic idea before reading that book and could recognise them, but couldn't for the life of me figure out how to apply that knowledge consistently.
Buy yourself "Head First Design Patterns" by Eric and Elisabeth Freeman (0596007124).
It's an excellent book that explains not just the patterns but why and how to use them.
I knew the basic idea before reading that book and could recognise them, but couldn't for the life of me figure out how to apply that knowledge consistently.
Thanks for the reference.
Maybe it's just me, but I wouldn't "modify" anything to be static unless it's a utility class like Math, or if I really have to. I've seen a few people that say make everything static unless you don't need to, which I don't agree with. I guess a lot of people get tripped up when using the main method since it cannot reference anything but static contexts.
Maybe it's just me, but I wouldn't "modify" anything to be static unless it's a utility class like Math, or if I really have to. I've seen a few people that say make everything static unless you don't need to, which I don't agree with. I guess a lot of people get tripped up when using the main method since it cannot reference anything but static contexts.
I see our point on Main.
Sorry your point!
yes, making main static may have been the worst design decision James and his team made when designing the language.
Or maybe it was providing for static stuff at all :)
I think "best practices" is just referring to source layout and use of white space. Basically, it is bad design to put multiple statements on one line. It is also considered bad design to neglect indenting blocks of code.
Most of these "best practices" have origins in making the source easier for other programmers to decipher. Basically, it's stuff that you probably already do.
That's part of it, but best practice extends to code written...In my opinion. For example, use methods and utility classes as much as you can, rather than re-inventing the wheel. Also, definately leave out repetitive code.
The list could go on and on, but that's just a few points.
Best practice can be anything from code layout to algorithms and design patterns used to business processes and procedures depending on the level you're talking at.
Use of UP for software design is a best practice, use of version control, unit testing frameworks, etc. etc.
Gargol,
If I write a class that will be instantiated ONLY once is it best practice to put most of the initialisation code in the initialiser block or in the constructor?
In many cases there is loads of code that would work in either position because it is pre-configuring instance variables before they are used or displayed.
For trivial classes this doesn't make much difference but as classes grow it gets more important to have a clear structure or sequence for the initialisation code.
I do not quite understand your points here. I think in your above three paragraphs, you mentioned three different ideas. Is that correct?
I am very interested in them. Could you provide samples to support your ideas please?
regards,
George
Have a think about this peice of code and tell me what you think.
import java.util.Vector;
public class Jottings {
//This is the Initialiser Block
//s1 is initialised here
String[] s1 = new String[]{"Entry One", "Entry Two" };
//s2 is initialised in the constructor
String[] s2 = new String[1];
//s2 is initialised in both Places
String[] s3 = new String[]{"Entry One"};
public Jottings() {
super();
//Design Patterns Suggest That This is the Preferred
//Place to Initialise if all Other concerns are Equal
//Initialisation of Some Variables Above
//and Other Variables Here is Not a Good Idea
//Try to Imagine How This Might Create Problems
//if we had 10 variables with 10 Entries Each
s2[0] = "Entry One";
s2[1] = "Entry Two";
s3[1] = "Entry Two";
}
public static void main(String[] args) {
}
}
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.