Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #35543 > unrolled thread

Changing accessor on public static class

Back to article view | Back to comp.lang.java.programmer

Contents

  Changing accessor on public static class mike <mikaelpetterson@hotmail.com> - 2016-09-06 00:53 -0700
    Re: Changing accessor on public static class Alberto Salvati <zzzato@gmail.com> - 2016-09-06 01:12 -0700
    Re: Changing accessor on public static class Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-09-06 09:08 -0400
      Re: Changing accessor on public static class Andreas Leitgeb <avl@logic.at> - 2016-09-06 23:00 +0000
        Re: Changing accessor on public static class Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-09-07 07:48 -0400
    Re: Changing accessor on public static class Eric Douglas <e.d.programmer@gmail.com> - 2016-09-06 07:00 -0700
      Re: Changing accessor on public static class Arne Vajhøj <arne@vajhoej.dk> - 2016-09-06 19:31 -0400
        Re: Changing accessor on public static class Eric Douglas <e.d.programmer@gmail.com> - 2016-09-07 04:47 -0700
          Re: Changing accessor on public static class Arne Vajhøj <arne@vajhoej.dk> - 2016-09-07 18:52 -0400
            Re: Changing accessor on public static class Eric Douglas <e.d.programmer@gmail.com> - 2016-09-08 04:54 -0700
              Re: Changing accessor on public static class Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-09-08 08:38 -0400
                Re: Changing accessor on public static class Eric Douglas <e.d.programmer@gmail.com> - 2016-09-08 06:35 -0700
                  Re: Changing accessor on public static class Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-09-08 10:09 -0400
                    Re: Changing accessor on public static class Eric Douglas <e.d.programmer@gmail.com> - 2016-09-08 08:18 -0700
                    Re: Changing accessor on public static class Eric Douglas <e.d.programmer@gmail.com> - 2016-09-08 08:37 -0700
                      Re: Changing accessor on public static class Arne Vajhøj <arne@vajhoej.dk> - 2016-09-08 19:34 -0400
                    Re: Changing accessor on public static class Arne Vajhøj <arne@vajhoej.dk> - 2016-09-08 19:32 -0400
              Re: Changing accessor on public static class Arne Vajhøj <arne@vajhoej.dk> - 2016-09-08 19:30 -0400
                Re: Changing accessor on public static class Arne Vajhøj <arne@vajhoej.dk> - 2016-09-08 21:50 -0400
              Re: Changing accessor on public static class Lew <lewbloch@gmail.com> - 2016-09-13 17:44 -0700
      Re: Changing accessor on public static class Lew <lewbloch@gmail.com> - 2016-09-13 17:42 -0700
    Re: Changing accessor on public static class Arne Vajhøj <arne@vajhoej.dk> - 2016-09-06 19:33 -0400
    Re: Changing accessor on public static class Lew <lewbloch@gmail.com> - 2016-09-13 17:39 -0700

Page 1 of 2  [1] 2  Next page →

#35543 — Changing accessor on public static class

Hi,

I use this class from another library like this:

app.connect(new Configuration( ipAddress, username));

I tried to make class Configuration not public ( since I did not want to expose this name) and it can still be created.
Is there any point in making it Configuration class not public?

static class Configuration


br,

//mike


public static class Configuration {

       
        private String host;
        private String username;
      
        
        /**
         * Constructor
         * 
         * @param host
         * @param username
         */
        public Configuration( String host, String username) {  
            this.host = host;
            this.username = username;
            
        }

       
        /**
         * 
         * @return host
         */
        public String getHost() {
            return host;
        }
        /**
         * 
         * @return user name.
         */
        public String getUsername() {
            return username;
        }
        
       
    }

[toc] | [next] | [standalone]

#35544

Hi, mike.
Take a look:

http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html



A.

[toc] | [prev] | [next] | [standalone]

#35545

On 9/6/2016 3:53 AM, mike wrote:
> Hi,
>
> I use this class from another library like this:
>
> app.connect(new Configuration( ipAddress, username));
>
> I tried to make class Configuration not public ( since I did not want to expose this name) and it can still be created.
> Is there any point in making it Configuration class not public?

     I don't quite understand what you are doing.  You show that the
Configuration class is `static', which can only mean that it is a
nested class embedded inside some other class: a top-level class
cannot be `static'.  You also show using `new Configuration()' to
instantiate this class, which implies that the `new' must be in
the containing class: if not, it would be `new Thing.Configuration()'
instead.  Yet you also say that the Configuration class belongs to
"another library," implying that the `new' is not in the containing
class at all but in some other class entirely.  These three things
cannot all be true simultaneously!

     Perhaps if you explained the situation in more detail, and cleared
up some of the apparent contradictions, someone would be able to help.

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35554

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> On 9/6/2016 3:53 AM, mike wrote:
>> Hi,
>> I use this class from another library like this:
>> app.connect(new Configuration( ipAddress, username));
>> I tried to make class Configuration not public ( since I did
>> not want to expose this name) and it can still be created.
>> Is there any point in making it Configuration class not public?
>      I don't quite understand what you are doing.  You show that the
> Configuration class is `static', which can only mean that it is a
> nested class embedded inside some other class: a top-level class
> cannot be `static'.  You also show using `new Configuration()' to
> instantiate this class, which implies that the `new' must be in
> the containing class: if not, it would be `new Thing.Configuration()'
> instead.

@Eric Sosman: Why disregard static imports of nested classes?

@mike: If you really don't want to expose the Configuration class, then
you could instead either (A) add a static (factory-)method and an inter-
face and have the static method return an instance of a hidden implemen-
tation class for that interface, or (B) just make an overload of connect
in app's class to accept the two arguments ipAddress, username directly.

[toc] | [prev] | [next] | [standalone]

#35563

On 9/6/2016 7:00 PM, Andreas Leitgeb wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>> On 9/6/2016 3:53 AM, mike wrote:
>>> Hi,
>>> I use this class from another library like this:
>>> app.connect(new Configuration( ipAddress, username));
>>> I tried to make class Configuration not public ( since I did
>>> not want to expose this name) and it can still be created.
>>> Is there any point in making it Configuration class not public?
>>      I don't quite understand what you are doing.  You show that the
>> Configuration class is `static', which can only mean that it is a
>> nested class embedded inside some other class: a top-level class
>> cannot be `static'.  You also show using `new Configuration()' to
>> instantiate this class, which implies that the `new' must be in
>> the containing class: if not, it would be `new Thing.Configuration()'
>> instead.
>
> @Eric Sosman: Why disregard static imports of nested classes?

     Because I overlooked the possibility!  (Thanks.)

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35546

On Tuesday, September 6, 2016 at 3:55:27 AM UTC-4, mike wrote:
> Hi,
> 
> I use this class from another library like this:
> 
> app.connect(new Configuration( ipAddress, username));
> 
> I tried to make class Configuration not public ( since I did not want to expose this name) and it can still be created.
> Is there any point in making it Configuration class not public?
> 
> static class Configuration
> 
> 
> br,
> 
> //mike
> 
> 
> public static class Configuration {
> 
>        
>         private String host;
>         private String username;
>       
>         
>         /**
>          * Constructor
>          * 
>          * @param host
>          * @param username
>          */
>         public Configuration( String host, String username) {  
>             this.host = host;
>             this.username = username;
>             
>         }
> 
>        
>         /**
>          * 
>          * @return host
>          */
>         public String getHost() {
>             return host;
>         }
>         /**
>          * 
>          * @return user name.
>          */
>         public String getUsername() {
>             return username;
>         }
>         
>        
>     }

Is there any point in making it public?
As Eric S said, a top-level class cannot be static, so we're assuming this is an inner class.  The only point to a static inner class is if you need an instance of it in a static method.  If your app.connect statement is in the outer class that contains this static class it can be a private class.  If you need other classes in the same package to reference it you can make it protected, and of course public allows everyone to use it, but of course they would refer to it as new OuterClass.Configuration().  You might as well limit it to the smallest scope if this is all there is to it.  Make it public if anything outside the outer class needs to configure it with anything other than what you want to pass through the outer class.

[toc] | [prev] | [next] | [standalone]

#35557

On 9/6/2016 10:00 AM, Eric Douglas wrote:
> Is there any point in making it public? As Eric S said, a top-level
> class cannot be static, so we're assuming this is an inner class.
> The only point to a static inner class is if you need an instance of
> it in a static method.

No. It is quite common to have static nested classes used in non-static
methods.

Arne

[toc] | [prev] | [next] | [standalone]

#35562

On Tuesday, September 6, 2016 at 7:31:56 PM UTC-4, Arne Vajhøj wrote:
> No. It is quite common to have static nested classes used in non-static
> methods.
> 
> Arne

I don't know how common it is but it's not necessary.  You can create an instance of a static class in a non static method but you can't create an instance of a non static class in a static method, so whether or not you instantiate it in a non static method, the point of making the class static is so you can instantiate it in a static method.

[toc] | [prev] | [next] | [standalone]

#35564

On 9/7/2016 7:47 AM, Eric Douglas wrote:
> On Tuesday, September 6, 2016 at 7:31:56 PM UTC-4, Arne Vajhøj
> wrote:
>> No. It is quite common to have static nested classes used in
>> non-static methods.
>
> I don't know how common it is but it's not necessary.  You can create
> an instance of a static class in a non static method but you can't
> create an instance of a non static class in a static method, so
> whether or not you instantiate it in a non static method, the point
> of making the class static is so you can instantiate it in a static
> method.

No no no.

A static nested class is a relative normal class just declared
within another class. It is often a good choice when the enclosing
class needs to return something implementing an interface or
similar. The same concept is known from both C# and C++ (they
don't use the static keyword, but a nested class without static in
those languages is the same as a static nested class in Java).

An inner class (non-static nested class) is a very complex
construct with its capture or automatic reference to the
creating instance. If you don't need this specific
feature then don't use this type of class. I don't think
I have ever had that need (not counting the closely
related anonymous inner class, which was very useful
before lambdas and still are somewhat useful).

So your decision logic should be:

if I want to put class declaration within another class then
     if the class really need to refer directly to members of the 
enclosing instance then
         use inner class
     else
         use static nested class
     end if
else
     use a normal class
end if

Arne

[toc] | [prev] | [next] | [standalone]

#35567

On Wednesday, September 7, 2016 at 6:52:53 PM UTC-4, Arne Vajhøj wrote:
> So your decision logic should be:
> 
> if I want to put class declaration within another class then
>      if the class really need to refer directly to members of the 
> enclosing instance then
>          use inner class
>      else
>          use static nested class
>      end if
> else
>      use a normal class
> end if
> 
> Arne

I'm not sure what you're saying.  I have plenty of inner classes but I've only ever made them static when there's a need to instantiate them from a static method or static block.

[toc] | [prev] | [next] | [standalone]

#35568

On 9/8/2016 7:54 AM, Eric Douglas wrote:
> On Wednesday, September 7, 2016 at 6:52:53 PM UTC-4, Arne Vajhøj wrote:
>> So your decision logic should be:
>>
>> if I want to put class declaration within another class then
>>      if the class really need to refer directly to members of the
>> enclosing instance then
>>          use inner class
>>      else
>>          use static nested class
>>      end if
>> else
>>      use a normal class
>> end if
>>
>> Arne
>
> I'm not sure what you're saying.  I have plenty of inner classes but I've only ever made them static when there's a need to instantiate them from a static method or static block.

     Do you have a copy of "Effective Java" by Joshua Bloch?  If not,
I strongly recommend you get one; it's an excellent work that I think
will improve just about anyone's Java.

     When you get the book, read "Item 18: Favor static member classes
over nonstatic" for Bloch's take on the pros and cons of static nested
classes vs. inner classes.

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35569

On Thursday, September 8, 2016 at 8:38:33 AM UTC-4, Eric Sosman wrote:
>      Do you have a copy of "Effective Java" by Joshua Bloch?  If not,
> I strongly recommend you get one; it's an excellent work that I think
> will improve just about anyone's Java.
> 
>      When you get the book, read "Item 18: Favor static member classes
> over nonstatic" for Bloch's take on the pros and cons of static nested
> classes vs. inner classes.

I don't have a copy but I searched and found it online.
https://github.com/HackathonHackers/programming-ebooks/blob/master/Java/Effective%20Java%20(2nd%20Edition).pdf

This was actually item 22, and I'm not sure the use case for static applies to any of my inner classes.  I believe all inner classes I've written are private classes and normally if not always require references to variables and/or methods of the outer class.

One of my classes that is full of inner classes uses them as helpers and declares them as classes because I believe it makes them more readable, where they could also be created as anonymous classes if the outer class only ever has one instance and they're only extending or implementing a single class (some implement multiple interfaces).  These classes do things like extend AbstractAction or MouseAdapter, or implement an interface used to connect the outer component class with member components.

[toc] | [prev] | [next] | [standalone]

#35570

On 9/8/2016 9:35 AM, Eric Douglas wrote:
> On Thursday, September 8, 2016 at 8:38:33 AM UTC-4, Eric Sosman wrote:
>>      Do you have a copy of "Effective Java" by Joshua Bloch?  If not,
>> I strongly recommend you get one; it's an excellent work that I think
>> will improve just about anyone's Java.
>>
>>      When you get the book, read "Item 18: Favor static member classes
>> over nonstatic" for Bloch's take on the pros and cons of static nested
>> classes vs. inner classes.
>
> I don't have a copy but I searched and found it online.
> https://github.com/HackathonHackers/programming-ebooks/blob/master/Java/Effective%20Java%20(2nd%20Edition).pdf
>
> This was actually item 22, and I'm not sure the use case for static applies to any of my inner classes.  I believe all inner classes I've written are private classes and normally if not always require references to variables and/or methods of the outer class.

     In my copy, Item 22 is "Replace function pointers with classes and
interfaces."  (Perhaps you found an edition newer than my venerable 2004
"7th printing.")  I still recommend obtaining the book; it's a good 'un.

     In any event, it is of course possible that your patterns of use for
nested classes are unlike those Bloch knows about -- and if they are,
Bloch's reasons for preferring the simplicity of static classes don't
apply.  Whether the O.P.'s classes (Whatever became of the O.P., anyhow?
Did he lose interest in his own question?) are more like yours or more
like Bloch's remains unknown.

     One final nitpick and niggle: An "inner class" is by definition
not static, so "not sure the use case for static applies to any of my
inner classes" is a tautology.

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35573

On Thursday, September 8, 2016 at 10:09:42 AM UTC-4, Eric Sosman wrote:
>      One final nitpick and niggle: An "inner class" is by definition
> not static, so "not sure the use case for static applies to any of my
> inner classes" is a tautology.

Right, fun with terminology... as I stated I'm not sure any of my inner/nested classes could be static since they're typically helper classes which call methods of the outer class.  They could be in separate class files but that seemed pointless if the constructor would require an instance of the outer class.  So yes they are nested classes, they are inner classes, if they could be static they would still be nested but would no longer be considered inner.

From the online version of the book.
"There are four kinds of nested classes: static member classes, nonstatic member classes, anonymous classes, and local classes. All but the first kind are known as inner classes."

So, I believe the text says make them static if they're self contained, even if they need to apply to a single instance of the outer class.  For instance if you have a custom control and a class within that control to store the properties of the control, so the control calls methods of the properties class but the properties class never references the control.

[toc] | [prev] | [next] | [standalone]

#35574

On Thursday, September 8, 2016 at 10:09:42 AM UTC-4, Eric Sosman wrote:
>      In my copy, Item 22 is "Replace function pointers with classes and
> interfaces."  (Perhaps you found an edition newer than my venerable 2004
> "7th printing.")  I still recommend obtaining the book; it's a good 'un.

You might want to check out the newer version.  That online version I found matches what's in this 2008 interview with the author.

http://www.oracle.com/technetwork/articles/java/bloch-effective-08-qa-140880.html

Amazon shows just 2 versions of this, 1st in 2001, 2nd in 2008.

[toc] | [prev] | [next] | [standalone]

#35578

On 9/8/2016 11:37 AM, Eric Douglas wrote:
> On Thursday, September 8, 2016 at 10:09:42 AM UTC-4, Eric Sosman wrote:
>>      In my copy, Item 22 is "Replace function pointers with classes and
>> interfaces."  (Perhaps you found an edition newer than my venerable 2004
>> "7th printing.")  I still recommend obtaining the book; it's a good 'un.
>
> You might want to check out the newer version.  That online version I found
 >
matches what's in this 2008 interview with the author.
>
> http://www.oracle.com/technetwork/articles/java/bloch-effective-08-qa-140880.html
>
> Amazon shows just 2 versions of this, 1st in 2001, 2nd in 2008.

Two editions. Multiple printings.

I got 1st ed 5th print and 2nd ed 12th print.

Arne

[toc] | [prev] | [next] | [standalone]

#35577

On 9/8/2016 10:09 AM, Eric Sosman wrote:
> On 9/8/2016 9:35 AM, Eric Douglas wrote:
>> On Thursday, September 8, 2016 at 8:38:33 AM UTC-4, Eric Sosman wrote:
>>>      Do you have a copy of "Effective Java" by Joshua Bloch?  If not,
>>> I strongly recommend you get one; it's an excellent work that I think
>>> will improve just about anyone's Java.
>>>
>>>      When you get the book, read "Item 18: Favor static member classes
>>> over nonstatic" for Bloch's take on the pros and cons of static nested
>>> classes vs. inner classes.
>>
>> I don't have a copy but I searched and found it online.
>> https://github.com/HackathonHackers/programming-ebooks/blob/master/Java/Effective%20Java%20(2nd%20Edition).pdf
>>
>>
>> This was actually item 22, and I'm not sure the use case for static
>> applies to any of my inner classes.  I believe all inner classes I've
>> written are private classes and normally if not always require
>> references to variables and/or methods of the outer class.
>
>     In my copy, Item 22 is "Replace function pointers with classes and
> interfaces."  (Perhaps you found an edition newer than my venerable 2004
> "7th printing.")  I still recommend obtaining the book; it's a good 'un.

It is 18 in first edition and 22 in second edition.

(yes - I got both)

Arne

[toc] | [prev] | [next] | [standalone]

#35576

On 9/8/2016 7:54 AM, Eric Douglas wrote:
> On Wednesday, September 7, 2016 at 6:52:53 PM UTC-4, Arne Vajhøj wrote:
>> So your decision logic should be:
>>
>> if I want to put class declaration within another class then
>>      if the class really need to refer directly to members of the enclosing instance then
>>          use inner class
>>      else
>>          use static nested class
>>      end if
>> else
>>      use a normal class
>> end if
>
> I'm not sure what you're saying.  I have plenty of inner classes but
> I've only ever made them static when there's a need to instantiate
> them from a static method or static block.

I am saying that you should do different.

Not:

only if I need to use from static method use static

But:

only if I need direct access to enclosing instances data use non-static

I am saying that you should change your default.

Java chose a slightly misleading syntax.

actual syntax: public static class Foobar
better syntax: public class Foobar

because:
- it is really just a normal class with an unusual name
- that is the syntax for the same semantics in C++ and C#

actual syntax: public class Foobar
better syntax: public verycompleximplicitrelationship class Foobar

because:
- that is what it is
- it would discourage accidental usage

Arne

[toc] | [prev] | [next] | [standalone]

#35579

On 9/8/2016 7:30 PM, Arne Vajhøj wrote:
> I am saying that you should do different.
>
> Not:
>
> only if I need to use from static method use static
>
> But:
>
> only if I need direct access to enclosing instances data use non-static
>
> I am saying that you should change your default.
>
> Java chose a slightly misleading syntax.
>
> actual syntax: public static class Foobar
> better syntax: public class Foobar
>
> because:
> - it is really just a normal class with an unusual name
> - that is the syntax for the same semantics in C++ and C#
>
> actual syntax: public class Foobar
> better syntax: public verycompleximplicitrelationship class Foobar
>
> because:
> - that is what it is
> - it would discourage accidental usage

Just for the fun of it try figuring out this little program:

public class InnerSpagetti {
	private int v;
	public class InnerSpagettiHelp {
		private int v;
		public InnerSpagettiHelp(int v) {
			this.v = v;
		}
		public void test() {
			System.out.println(v - InnerSpagetti.this.v);
		}
	}
	public InnerSpagetti(int v) {
		this.v = v;
	}
	public InnerSpagettiHelp setup(InnerSpagetti o) {
		return o.new InnerSpagettiHelp(v + 1);
	}
	public static void main(String[] args) {
		InnerSpagetti o1 = new InnerSpagetti(10);
		InnerSpagetti o2 = new InnerSpagetti(12);
		InnerSpagettiHelp io1 = o1.setup(o2);
		InnerSpagettiHelp io2 = o1.setup(o1);
		io1.test();
		io2.test();
	}
}

Arne

[toc] | [prev] | [next] | [standalone]

#35595

On Thursday, September 8, 2016 at 4:55:08 AM UTC-7, Eric Douglas wrote:
> On Wednesday, September 7, 2016 at 6:52:53 PM UTC-4, Arne Vajhøj wrote:
> > So your decision logic should be:
> > 
> > if I want to put class declaration within another class then
> >      if the class really need to refer directly to members of the 
> > enclosing instance then
> >          use inner class
> >      else
> >          use static nested class
> >      end if
> > else
> >      use a normal class
> > end if
> > 
> > Arne
> 
> I'm not sure what you're saying.  I have plenty of inner classes but I've only ever made them static when there's a need to instantiate them from a static method or static block.

Then you aren't using static nested (not "inner") classes correctly.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web