inheritance and access modifiers

[Lucas Smith]

Please consider the following pieces of code:

abstract class A{
    private int[] a = new int[10];
    public int[] getA(){
        return a;
    }
}

class B extends A{
    public void doSomethingWithA(){
        this.getA(); // and do somethind with it
    }
}

or maybe that's better:

abstract class A{
    int[] a = new int[10];
}

class B extends A{
    public void doSomethingWithA(){
         // do something with a - no getter method is required. "a" is inherited and accessible from within class B
    }
}

Unfortunatelly, all the classes in the package can access a variable without access modifier. Why there is no access modifier which can give the access only to the subclasses?

Which piece of code is better?

Thanks!

[Jimmy Clark]

Which piece of code is better?

This is an interesting question. However, to create a solid answer more information is required. For example, we should know why your are subclassing A. Your example code does not show a need for this. Also, we would need to know the context of the integer array. Or in other words what and who is doing what with this data and when and where and how.

With this information in hand, then you can better decide which design is "better" for your particular needs.

Generally, in principle, keeping an object's data fields strongly encapsulated is a good design technique. However, in practice, there might be reasons to deviate from "principle."

[Lucas Smith]

This is a project regarding recrystallization in metals, but it is not important. I have a design:

public abstract class GrainGrowthModel {
	private Lattice lattice;

        public GrainGrowthModel(Lattice lattice){
		this.lattice = lattice;
	}

        public Lattice getLattice(){
          return lattice;
       }

        public abstract void nextStep();

}

public class CAGrainGrowthModel2D extends GrainGrowthModel  {
        public CAGrainGrowthModel2D(Lattice2D lattice){
		super(lattice);
        }

        public void nextStep(){
       //many operations on lattice 
       //should I use getter? maybe I should change access modifier to lattice?
       }
}

[Jimmy Clark]

How about starting with ...

public abstract interface GrainGrowthModel {

        public abstract void nextStep();

}   


  
public final class CAGrainGrowthModel2D implements GrainGrowthModel  {   
    
        private Lattice lattice;   
  

        public CAGrainGrowthModel2D(Lattice x){   
            this.lattice = x;   
        }   
  
        public void nextStep(){   
        
        }   
}  

[Lucas Smith]

Good point James, but I did not present you all of the functionality, my fault.

Please consider this:

public abstract class GrainGrowthModel {
	private Lattice lattice;
	private NucleonGenerator nucleonGenerator;
	
        public abstract void nextStep();
	
	public GrainGrowthModel(Lattice lattice, NucleonGenerator nucleonGenerator){
		this.lattice = lattice;
		this.nucleonGenerator = nucleonGenerator;
	}
	
	public void setLattice(Lattice lattice){ //I need this so that I can change lattice during runtime
		this.lattice = lattice;
	}
	
	public Lattice getLattice(){
		return lattice;
	}
}

public class CAGrainGrowthModel2D extends GrainGrowthModel  {
	
	
	public CAGrainGrowthModel2D(Lattice2D lattice, NucleonGenerator2D nucleonGenerator){
		super(lattice, nucleonGenerator);
	}

        //here goes operations on Lattice2D (I need Lattice2dD because of its specific methods which are not common in Lattice)
//but unfortunately I have to cast from Lattice to Lattice2D. I do not know how to solve this problem.
}

I think that it is up to GrainGrowthModel to set Lattice and NucleonGenerator.

Any ideas?

[Jimmy Clark]

public abstract interface GrainGrowthModel {   
  
        public void nextStep();   
        public void setLattice(Lattice lattice);
        public Lattice getLattice();  
}      
  
public abstract interface Lattice  {   
  
    // Declare all of the methods that could possibly exist for anything related to a Lattice implementation  
  
}

public abstract interface NucleonGenerator  {   
  
    // Declare all of the methods that could possibly exist for anything related to a NucleonGenerator implementation  
  
}  
     
public final class CAGrainGrowthModel2D implements GrainGrowthModel  {      
       
        private Lattice lattice;
        private NucleonGenerator nucleonGenerator;      
     
  
        public CAGrainGrowthModel2D(Lattice x, NucleonGenerator y){      
            this.lattice = x;      
            this.nucleonGenerator = y;     
        }      
     
        public void nextStep(){      
           
        }      

        public void setLattice(Lattice lattice){  
            this.lattice = lattice;   
        }   
       
        public Lattice getLattice(){   
            return lattice;   
        }   

}    

[Lucas Smith]

thanks, but I need the functionality of Lattice2D which superclass is Lattice. I do not know where I should cast.

[Jimmy Clark]

Create an interface for Lattice and then declare all of the methods that you need in all of the implementations.

Take whatever is in your Lattice class now and change the name, e.g. Limple, and have it implement the Lattice interface.

Then have your Lattice2D class extend from Limple.

No need to cast anything.

[Lucas Smith]

But I want to use Lattice2D as a reference in CAGrainGrowthModel2D. I want to use composition (association).
So I have GrainGrowthModel with a reference to Lattice. Then I want to extend GrainGrowthModel with CAGrainGrowthModel2D, but I need Lattice2D funcionality. I need to cast from Lattice to Lattice2D in CAGrainGrowthModel2D. Lattice2D has more methods than Lattice.
I do not know if this is a good design.
What do you think?

[Jimmy Clark]

You are having trouble comprehending interface design as an alternative to older style subclassing.

I have presented an alternative design that removes the need to cast besides other things. If there is something that you don't understand below then say so.


Create an interface for Lattice and then declare all of the methods that you need in all of the implementations.

Take whatever is in your Lattice class now and change the name, e.g. Limple, and have it implement the Lattice interface.

Then have your Lattice2D class extend from Limple.

No need to cast anything.

Post the Latice and Lattice2d classes.

[Lucas Smith]

OK, but Lattice2d has more methods than Limple and I need those extra methods in my CAGrainGrowthModel2D. So I have to cast. What can you say about it?

[Jimmy Clark]

You only "have" to cast if you design it "your" way. There are other ways to design using interfaces eliminating the "need" to cast. I've already explained how in earlier posts.

Create an interface for Lattice and then declare all of the methods that you need in all of the implementations.

[Lucas Smith]

James Clarks wrote:
Create an interface for Lattice and then declare all of the methods that you need in all of the implementations.

I can not do it. A few methods make sense only in the lower parts of inheritance tree. There is no use declaring them in the interface. How about them?

[Jimmy Clark]

I can not do it. A few methods make sense only in the lower parts of inheritance tree. There is no use declaring them in the interface. How about them?

Then maybe these methods really don't have anything to do with a "Lattice" and they don't belong in the Lattice2D class anyway. The purpose of declaring them in the interface is to avoid having to do "awkward" things in order to correctly cast.

In other words, if these methods don't make sense for "Lattice" then take them out. If they do make sense for Lattice, then putting them in a common Lattice interface makes sense. All of the Lattice implementations don't necessarily need to use every single method.

If these "methods" don't fit in to what a Lattice is, but are needed for a particular implementation, then they should most likely be private methods of the implementing class.

Good luck with your design!

[Lucas Smith]

James, thanks for your help.

I have the particular example. I would appreciate it if you could have a look.

public interface Dimension{} //just marker interface

public class Dimension 2D implements Dimension{
    private int x, y;
    public int getXsize(){return x;}
    public int getYsize(){return y;}
}

public abstract Lattice{
    private Dimension dimension;
     //the initialization is in constructor
     //getter method for dimension   
}

public class Lattice2D{
    public Lattice2D(Dimension2D dimension){
        super(dimension);
    }

    public getXsize(){
        return ((Lattice2D)this.getDimension()).getXsize(); //I have to cast. Any ideas? 
        //Maybe I should declare Dimension in Latice as protected and invoke:
        // return ((Lattice2D)dimension).getXsize();
        // But I have to cast as well.
    }
}

What can you say?

[Jimmy Clark]

public abstract interface Lattice {
    public Dimension getDimension();
    public int getXsize();
}

public class BaseLatticeImpl implements Lattice {
     protected Dimension dim;
     private BaseLatticeImpl() {}
     public BaseLatticeImpl(Dimension d) {
         this.dim = d;
     }
     public Dimension getDimension() {
         return this.dim;
     }
     public int getXsize() {
         return this.dim.getXsize();

         // *** LOOK HERE ***  No need to cast 
     }
}

public final class Lattice2DImpl extends BaseLatticeImpl {
    
    public Lattice2DImpl(Dimension x) {
        super(x);
    }
}

public abstract interface Dimension {
    public int getYsize();
    public int getXsize();
    public void setYsize(int y);
    public void setXsize(int x);
}

public final class Dimension2D implements Dimension {
    private int x;
    private int y;
    public int getYsize() {return this.y;}
    public int getXsize() {return this.x;}
    public void setYsize(int _y) {this.y =_y;}
    public void setXsize(int _x) {this.x =_x;}
}

...

        Dimension _dim = new Dimension2D();
        _dim.setXsize(1);
        _dim.setXsize(2);
        Lattice _lat = new Lattice2DImpl(_dim);
        
        System.out.println("Lattice Dimension X = " +_lat.getXsize());

...

[Lucas Smith]

It is really helpful, I got it.
But note that Dimension is going to vary. Maybe I will need Dimension3D. I think it can be solved like this:

interface Dimension3D extends Dimension{
public void setZsize...
public int getZsize...    

What do you think, James?

[Jimmy Clark]

Your are progressing.... However, you need to think of the objects at a higher level of abstraction. There rarely is a "true"
need to have interfaces extend from others. Proper interface design takes time and patience. This is something that some "programmer" types typically lack. They want to start writing codez...immediately, lol.

One of the key goals is to elimiate syntax-level dependencies on classnames. Client objects should not have to know about the classname of the implementing class, only the interface name.

public abstract interface Dimension {   
    public int getYsize();   
    public int getXsize();   
    public int getZsize();   

    public void setYsize(int y);   
    public void setXsize(int x); 
    public void setZsize(int x); 
}

public class BaseDimensionImpl implements Dimension {   
    protected int x;   
    protected int y;   
    protected int z;   
    public int getYsize() {return this.y;}   
    public int getXsize() {return this.x;}   
    public int getZsize() {return this.z;}   

    public void setYsize(int _y) {this.y =_y;}   
    public void setXsize(int _x) {this.x =_x;}   
    public void setZsize(int _z) {this.z =_z;}   

}

public final class Dimension3DImpl extends BaseDimensionImpl {   


}

public final class Dimension2DImpl extends BaseDimensionImpl {   


}

Below is the code in the client object. Notice how none of the lines have the actual implementing classname. The
only objects that have the hard-coded classname are the factory objects. This is the essence of the Factory design patterns.

...   
  
        Dimension _dim = DimensionFactory.getDimension(Constants._3D);   
        _dim.setXsize(1);   
        _dim.setYsize(2);   
        _dim.setZsize(3);   

        Lattice _lat = LatticeFactory.getLattice(_dim);   
           
        System.out.println("Lattice Dimension Z = " +_lat.getZsize());   
  
...  

[Lucas Smith]

I see, I am reading a book about design patterns. But I can not realize how to implement Dimension interface. Every subclass will have one method more - one dimension more. Will subclassing be unavoidable?

[Jimmy Clark]

Sounds good. Note, we are not avoiding "subclassing" here, we have just added an additional design layer above via interface. As you
can see, we *are* extending from a base class for Lattice and Dimension.

In regards to "designing" the Dimension interface class, you need to step back and look at your requirements and analyze every type of dimension there could be.
Then you can easily design the interface class and the concrete implementation class. If there are 10 more dimensions, that is fine. If there are 100 more, that is fine too.

At this point, it is unclear why you would need subclasses of the base Dimension concrete class (which implements the Design interface class.) Creating an entirely new concrete subclass just to hold an integer value or two does not make much sense.