how to call the constructor of a Singleton
hi everyone ..
i have this class which is singleton
public class single{
private static single onlyOne;
private single(int arg1){
....
}
public static synchronized single getInstance(int arg2){
if (onlyOne == null)
onlyOne = new single(arg2);
return;
}
}
this class compiles without any problem .. my problem is when i try to instanciate a variable of that class .. for example :
single test = new single().getInstance(1);
gives me the compilation error "cannot resolve symbol" for the method single()
so i added an empty body constructor for the class single like this:
public single(){}
and now when i try to instaciate a variable this way
single test = new single().getInstance(1);
it compiles .. and works without any problems (creates one and just one class)
is there any civilized way to do it (i mean without the empty body constructor)?
thanks all and have a good one
[1017 byte] By [
malrawia] at [2007-9-27 23:38:09]
>
>single test = new single().getInstance(1);
You should be calling it like this...
single test = single.getInstance(1);
Note that passing an argument in seems a little suspect with the code segement above.
There is only one, so if you want to initialize it then something like the following would probably be better (it would obviously require a new static method.)
single.initialize(1);
I can't imagine how this code might compile.
return;
Should probably be
return onlyOne;
Passing an argument to the getInstance() method seems quite dubious (unless you use some Map or something to return a different instance for every possible value).
new single().getInstance(1);
Should be:
single.getInstance(1);
Also note that it is standard Java style to use caps for class names, so Single would be more appropriate. You can use any style you choose, but 99% of expirienced Java programmers would simply have a hard time reading your code this way, because they are used to the standard style.
Gal
GalBa at 2007-7-7 16:09:23 >
You may read more about Java Coding Conventions, and why they are relevant to follow right here: http://java.sun.com/docs/codeconv/Kind regardsPovl
> You may read more about Java Coding Conventions, and
> why they are relevant to follow right here:
>
> http://java.sun.com/docs/codeconv/
>
No you can read about Sun's coding conventions there. Unfortunately they are poor representation of coding standards. There are few workable points, but other parts that are wrong or are missing.
True, it's Sun's coding conventions. But I see them as a very good start for several reasons:
- They are sufficiently short for everyone to read and understand.
- They cover the basics within formatting code for better readability.
- There's still room for sufficient personal programming style.
- They are widely used within the Java community.
The coding conventions does not cover all aspects of programming. And IMHO coding conventions shouldn't. You cannot make rules for good programming practices anyway - we still need skilled professionals to do professional jobs.
Sun's Java Coding Conventions are good basics. I see them as a superclass for a company's more specialized coding conventions.
This is getting slightly off topic... Should we start another thread? ;)
Kind regards
> True, it's Sun's coding conventions. But I see
> them as a very good start for several reasons:
>
> - They are sufficiently short for everyone to read and
> understand.
Yep.
> - They cover the basics within formatting code for
> better readability.
No they do not. They cover extremely minor points and miss substantial items.
> - There's still room for sufficient personal
> programming style.
> - They are widely used within the Java community.
>
Based on which study?
> The coding conventions does not cover all aspects of
> programming. And IMHO coding conventions shouldn't.
I didn't say that they did.
> You cannot make rules for good programming practices
> anyway - we still need skilled professionals to do
> professional jobs.
>
> Sun's Java Coding Conventions are good basics. I see
> them as a superclass for a company's more specialized
> coding conventions.
>
No. They are severly crippled. Refining them is a mistake.
> No you can read about Sun's coding conventions
> there. Unfortunately they are poor representation of
> coding standards. There are few workable points, but
> other parts that are wrong or are missing.
ok, i'll bite. would you elaborate on the inadequacies of sun's coding conventions?
> > No you can read about Sun's coding
> conventions
> > there. Unfortunately they are poor representation
> of
> > coding standards. There are few workable points,
> but
> > other parts that are wrong or are missing.
>
> ok, i'll bite. would you elaborate on the
> inadequacies of sun's coding conventions?
bracing styles are a triviality - which the document addresses.
The document address how comments should be formatted but does not specify that anything at all should actually be commented. This is reflected in the java source code which has entire files with no comments.
There are redundant areas reflecting the real possibility that the standard was not reviewed. For example it specifies that methods are seperated by a blank line in two different places and it specifies bracing styles for the if statement in different places.
It states that braces should be used around single statements giving as the reason that it prevents bugs in the future when other lines are added. That is poor reasoning (there are better reasons even those those are trivial as well.)
It provides a rule that java does not even allow syntactically (don't use '=' in an if.)
It implies that it is perfectly acceptable to produce code that is incomplete or incorrect as long as it is commented to say that.
As I said however there are some workable points, such as the section on wrapping lines.
I'm not sure whether the specific use of comments or correctness semantics of code should be a part of a widely-accepted coding conventions document. It differs significantly from project to project, and doesn't strike me as a "stylistic" convention.
I do agree that the if-related conventions are not very convincingly reasoned, and in fact I don't even follow them (particularly the one-statement-braces rule).
I don't see the point about arguing about redundancy or duplication in the document. Maybe it exists, but I don't really care, as far as this discussion goes. We are discussing the *coding standards*, not the document that explains them. Whether or not the document explains these standards well (e.g., without duplicate explanations) is a different question.
Gal
GalBa at 2007-7-7 16:09:23 >
Coding guidelines states important things like number of spaces to indent, where to use capital letters, where to use lower case, where to put braces ect.
Coding guide lines can never guarantee design- or coding quality. It is a simple set of formatting rules, that helps make the code easier to read.
Specialized versions of coding guide lines may include rules for copyright statements, version branding, etc. As with the basic coding guide lines, that does not imply that the programmers understands versioning or configuration management.
> I'm not sure whether the specific use of comments or
> correctness semantics of code should be a part of a
> widely-accepted coding conventions document. It
> differs significantly from project to project, and
> doesn't strike me as a "stylistic" convention.
You work on projects where it is incorrect to add comments?
>
> I do agree that the if-related conventions are not
> very convincingly reasoned, and in fact I don't even
> follow them (particularly the one-statement-braces
> rule).
>
> I don't see the point about arguing about redundancy
> or duplication in the document. Maybe it exists, but I
> don't really care, as far as this discussion goes.
Coding guidelines should be one of the last things added in a process control system. That is because it has the least effect on process. Process control system, regardless of the system, all use reviews. This document was not reviewed. Thus it suggests that it is not part of a process control system and thus the intent of the guidelines are suspect (it strongly suggests that it was imposed by an individual or several individuals rather that by striving for a consensus.)
> We are discussing the *coding standards*, not the
> document that explains them. Whether or not the
> document explains these standards well (e.g., without
> duplicate explanations) is a different question.
Nope.
I never said that standards were a bad idea. I said that using that particular document as a starting point was a bad idea. One can certainly read it and take some ideas from it. But it should not be used as the base because most of it is worthless.
> Coding guidelines states important things like number
> of spaces to indent, where to use capital letters,
> where to use lower case, where to put braces ect.
No. Because most of what you mentioned is not that important.
The most important things in coding guidelines are the imposition of comments. The second most important thing is the regulation of whitespace (of which indention might or might not be considered.) This second one is important as the proper use of white space makes the organisation of the code easier to understand. Naming conventions can play a part but are as not as important (although I prefer them.) Bracing styles are a triviality for most businesses except to the extent that a single source file must be consistent.
>
> Coding guide lines can never guarantee design- or
> coding quality. It is a simple set of formatting
> rules, that helps make the code easier to read.
>
Yes. But then coding guidelines should not address design guidelines nor designs themselves so I am not sure how that applies.
