Ref. Class's Function Is Not accessible Why?

Question

1.89/5 (2 votes)

See more:

Ref. Class's Function Is Not accessible Why?

hear is my code

C#

public class FieldShadowing_1
{
    public  String name = "FieldShadowing_1";
    public   String getName()
    {
        return "Hello";
    }


}

C#

public class FieldShadowing_2 extends FieldShadowing_1
{



    public  void display()
    {
        System.out.println("Check");
    }
 }

C#

public static void main(String[] args)
   {

FieldShadowing_1 b = new FieldShadowing_2();

       
        System.out.println(b.display()); //display() is not accesible hear O"
}

Posted 23-Feb-14 2:11am

vivektiwari97701

Add a Solution

3 solutions

Solution 2

Although it is really a FieldShadowing_2 underneath, the FieldShadowing_2 is pretending to be a FieldShadowing_1, which cannot display().

This is an example of inheritance and abstraction:
FieldShadowing_2 inherits FieldShadowing_1.
The variable b is an abstraction of FieldShadowing_2 because it is stored as a FieldShadowing_1.

Here is a rewritten version demonstrating more situations that do and don't have errors:

(I have changed the class names because FieldShadowing_1 is not a very descriptive class name, and because this code does not actually demonstrate shadowing, which is something else entirely!)

Java

public class A
{
    public String getName() { return "A"; }
}
public class B1 extends A
{
    public void display()
    {
        System.out.println("Check");
    }
}
public class B2 extends A
{
    public void doNothing()
    {

    }
}
public static void main(String[] args)
{
    B b1 = new B1();
    B b2 = new B2();
    A a1 = b1;
    A a2 = b2;

    System.out.println(b1.getName()); // OK: B1 has getName()
    System.out.println(b2.getName()); // OK: B2 has getName()    

    System.out.println(a1.getName()); // OK: A has getName()
    System.out.println(a2.getName()); // OK: A has getName()

    b1.display(); // OK:    B1 has display()    
    b2.display(); // ERROR: B2 does not have display()

    a1.display(); // ERROR: A does not have display()
    a2.display(); // ERROR: A does not have display()

    b1.doNothing(); // ERROR: B1 does not have doNothing()    
    b2.doNothing(); // OK:    B2 has doNothing()

    a1.doNothing(); // ERROR: A does not have doNothing()
    a2.doNothing(); // ERROR: A does not have doNothing()

    
}

Posted 23-Feb-14 2:39am

pharap@hotmail.com

Updated 23-Feb-14 2:42am

v3

Comments

Sergey Alexandrovich Kryukov 23-Feb-14 14:10pm

It is not "pretending". FieldShadowing_2 is actually FieldShadowing_1 at the same time.
And it can display! Only this is inadequate choose of compile-time type.
Correct, the OP's code is unrelated to shadowing.
—SA

Solution 1

Quote:
public class FieldShadowing_2 extends FieldShadowing_1

It means that FieldShadowing_2 has all the capabilities of FieldShadowing_1 but not the other way around!
By downcasting FieldShadowing_2 you also remove the extensions it adds...

Posted 23-Feb-14 2:24am

Kornfeld Eliyahu Peter

Comments

Sergey Alexandrovich Kryukov 23-Feb-14 14:09pm

Nothing is "removed". It simply means that the runtime type is FieldShadowing_2, but the compile-time typ FieldShadowing_1 is used, which does not provide access to extension.
—SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2014-02-23T08:23:00

Please see my comment to Solution 1 and Solution 2. They do not completely explain what's going on.

To understand it, you need to get the concept of compile-time and runtime types.

In FieldShadowing_1 b = new FieldShadowing_2(); compile-time type of b is FieldShadowing_1, but runtime type is FieldShadowing_2. You can think of it this way: b provides a reference to the instance of FieldShadowing_2 from the point of view of FieldShadowing_1. As those are references to instance type, you could have to references of different types which are physically pointing to the same place in memory. So, if you down-case b to FieldShadowing_2, it will give your the access to display. This is not a good idea, because in more general context, your compile-time information does not care information that this is the derived type. You would rather need to use dynamic cast which actually asks an instance which type is it, actually.

If those were the interface reference, the situation would be more complex, in the root of the problem, due to the weak form of multiple inheritance (multiple for interfaces only). The it is possible to have the situation where references of different interface types point to different place in memory — different places of the same runtime instance of some class.

And it all has nothing to do with shadowing.

—SA