I am not a professional coder, never studied it (just learned), it's more of a hobby.

 

Question is: In order to make namings "nice" - is it worth to make static classes, e.g:

 

public class ItemCore extends Item
{
public ItemCore(String name)
{
	super();
	//whatever (cut)
}

public static class ItemDust extends ItemCore
{
	public ItemDust(String name);
	{
		super("dust_" + name);
	}
}

public static class ItemOil extends ItemCore
{
	public ItemOil(String name)
	{
		super("oil_" + name);
	}
}
}

 

Meaning - is there a VALID (good practice or bad?) point in making it, or is it pointless?

Isn't one issue with nested classes that you need an instance of the outer class to create an instance of the inner class. So using it for items like in Ernio's example, you'd have to make an ItemCore instance that is just for purpose of allowing inner classes to be instantiated, even though the itemCore instance is never otherwise used/registered as an item in Forge.

 

Seems a little convoluted just for naming convenience, especially since you have a good, cleaner alternative: I think it makes more sense for naming to have the standard Items class where you have nicely named instances of the items as member fields (not classes).

Isn't one issue with nested classes that you need an instance of the outer class to create an instance of the inner class. So using it for items like in Ernio's example, you'd have to make an ItemCore instance that is just for purpose of allowing inner classes to be instantiated, even though the itemCore instance is never otherwise used/registered as an item in Forge.

 

Seems a little convoluted just for naming convenience, especially since you have a good, cleaner alternative: I think it makes more sense for naming to have the standard Items class where you have nicely named instances of the items as member fields (not classes).

As i know and if you haven't said it: static nested classes do not require instance of parent class (can be instanated by new ParentClass.NestedClass()), but non static do (only new parentClassIntsance.NestedClass() will work)...

elix is right with that. if u think a bit about what static means in java ull know

In all my years of using Java, I never knew you could have a static class(It makes sense though)

Hi

I have found myself using a static class only when I am creating subclasses in the super class for the purpose of quickness \ less classes with very little code (I have done this in the item initialization and registry class and created subclasses there). In the item registry class, the methods should be declared "static". If the case is that your subclass references a static variable or method from the super class, the subclass must be static or eclipse will throw errors. Sounds confusing until you try it!

elix is right with that. if u think a bit about what static means in java ull know

 

Yeah, the terminology for "nested" versus "inner" confuses me sometimes. I wish they just called them static nested and non-static nested. Instead non-static nested is called inner. I realize the terminology makes sense in terms of access of the outside class members, but still seems a bit inconsistent.

 

I was remembering (rightly) that all inner classes require an instance, but inner class is basically "non-static nested" class. There is no such thing as "static inner".

Ernio, I think in your example it would be better to just pass ('prefix_' + name) to your constructor as necessary with one single class, especially if you will only have one instance of each subclass.

 

Also, if you are planning on only using a class once, you may want to consider anonymous classes. I often use them if, for example, I have a 'special case' within my class that could instead be handled by overriding a single (or sometimes two) method as an anonymous class, most often with Items.

 

So instead of:

public void someMethod() {
  if (this == MyItems.specialItem) {
     // do something special
  } else {
     // do something mundane
  }
}

 

I end up with:

// original class:
public void someMethod() {
  // do something mundane
}

// when instantiating my SpecialItem:
specialItem = (new SomeItem() {
  @Override
  public void someMethod() {
     // do something special
  }
});
// note: you don't technically need to surround your anonymous class declaration in parentheses, but you will need to
// if you are going to chain any methods off of it, e.g. setUnlocalizedName, setCreativeTabs, or anything like that

 

This summary, while a bit too concise, still sort of explains typical use cases for nested, inner, and anonymous classes, among other things.

The reasons you would like to use nested static classes are explained here:

http://stackoverflow.com/a/253521

The reasons you would like to use nested static classes are explained here:

http://stackoverflow.com/a/253521

Not near my IDE atm but I'm pretty sure the Stitcher class has nested classes Holder and Slot which backs this as an example of packaging neatness