• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

inheritance and access modifiers

 
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Please consider the following pieces of code:



or maybe that's better:



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!
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is a project regarding recrystallization in metals, but it is not important. I have a design:

 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How about starting with ...

 
Lucas Smith
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good point James, but I did not present you all of the functionality, my fault.

Please consider this:



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

Any ideas?
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
 
Lucas Smith
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks, but I need the functionality of Lattice2D which superclass is Lattice. I do not know where I should cast.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
James, thanks for your help.

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

 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator










 
Lucas Smith
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:

What do you think, James?
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.









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.


 
Lucas Smith
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
I'm still in control here. LOOK at this tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic