why don't abstract members be marked as public automatically?

Question

1.00/5 (1 vote)

See more:

C#

abstract class mybase
{
    public int a, b, result;

    public int Multi()
    {
        return 0;
    }
}

class derived : mybase
{
    static void Main()
    {
        derived de = new derived();

        Console.WriteLine("Result of 3 * 5 = {0}", de.Multi());
        Console.ReadLine();
    }

    public int Multi()
    {
        a = 3;
        b = 5;
        return (result = a * b);
    }
}

If i change the line:

C#

public int a, b, result;

to

C#

int a, b, result;

it will not work.

And here is my question:
Why don't variables a, b, result be marked as "public abstract members"?

Posted 4-Mar-15 7:16am

user8x86

Add a Solution

Comments

phil.o 4-Mar-15 13:33pm

Member (instance) variables are not available from static methods/properties. Which is exactly the case here: you set up a static Main() method where you try to access an instance method (Multi).

Try to wipe the static out of Main and see what happens.

[no name] 4-Mar-15 13:39pm

He doesn't access the members in question inside the static method.

phil.o 4-Mar-15 13:46pm

Oh yes you're right; I definitely should not answer on evening before dinner :(
Thank for pointing it out.

2 solutions

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 · 2015-03-04T08:44:00

Not only it would be silly to limit the functionality that badly, but let's aloso think access what modifier would be most likely with virtual members, with any at least a bit reasonable code design? Of course, protected. But what would be about your suggestion, public? Amazingly, it is the least likely, also by far. Moreover, if it could be possible, it could be a pretty strong indication of likely abuse of technology, and in this, cases, quite bad abuse. So, your idea appeared to be, in this sense, "directly opposite" to the reasonable.

Do I have to explain why? It is very obvious, but takes learning OOP, from the very beginning. As to the access modifiers, this topic is pretty trivial:
https://msdn.microsoft.com/en-us/library/ms173121.aspx[^],
https://msdn.microsoft.com/en-us/library/wxh6fsc7.aspx[^].

—SA

manchanx · Accepted Answer · 2015-03-04T07:37:00

Solution 1

There's another access modifier, which would be the appropriate one in this case: protected

"Protected" members are accessible to the declaring class and to its subclasses, but not from outside.

So this will work:

protected int a, b, result;

edit:

If you don't specify an access modifier explicitly, private is the default (for class members). So this:

int a, b, result;

is equivalent to

private int a, b, result;

and private members aren't accessible to subclasses.

My suggestion: Always specify all access modifiers explicitly, for members as well as for classes.

Posted 4-Mar-15 7:37am

manchanx

Updated 4-Mar-15 7:55am

v2

Comments

PIEBALDconsult 4-Mar-15 14:04pm

"Always specify all access modifiers explicitly"

Hear! Hear!

[no name] 4-Mar-15 14:17pm

I know this, I once had to write it down a hundred times *g*

Thanks for the upvote!

Sergey Alexandrovich Kryukov 4-Mar-15 14:48pm

Why specifying access modifiers explicitly, why? Who told you so? Any use case when doing it any better than relying on default (private for members, internal for top-level types)?

Now, you are right in your advice to use "protected", but only partially. This is only the most likely access or the virtual members, but there are many (relatively rare) cases, when it can be internal of even public. Only "private" would never make any sense. Please see also my answer.

—SA

[no name] 4-Mar-15 14:59pm

Of course it doesn't *have* to be protected here. But I'm fairly certain that he/she just started to learn programming (or OOP at least) and that "protected" would be what he/she intended and that "internal" would be more confusing than helping at this point.

For the explicit access modifiers - I just regard it as good practise.

Sergey Alexandrovich Kryukov 4-Mar-15 15:10pm

I would be more careful with this advice. I have no idea why this would be any better practice than leaving the default. There is no a rational reason to overstate the default. It can be considered as a matter of style, and the styles are questionable. This is like commenting '}' part.
—SA

[no name] 4-Mar-15 15:15pm

Agree.

Santosh K. Tripathi 4-Mar-15 23:33pm

5+

Sergey Alexandrovich Kryukov 4-Mar-15 23:49pm

Thank you, Santosh.
—SA