Question about OOP in C#

Question

5.00/5 (1 vote)

See more:

Hi all,

Please i want to make sure that i understand those concepts well so please tell me if i am right :

-We declare a virtual method in a class so we can write a code in it and override it in a child class or hiding it by new keyword.

-We declare an abstract method in a class and we cant write a code in it but we can override it in a child class or hiding it by new keyword.

-A question goes here : cant i override a function without declaring it as virtual and abstract in the parent class ?

Thank you.

Posted 1-Feb-12 4:46am

mhamad zarif

Add a Solution

Comments

Sergey Alexandrovich Kryukov 1-Feb-12 13:23pm

It looks like the questions are asked by a novice, but they are correct and make sense (and actually asked more for just reassurance), so I voted 5 for correctly posed question, which happens pretty rarely these days. (Most questions are not even questions.)
--SA

mhamad zarif 1-Feb-12 13:34pm

thank you. I always try to search the internet and come out with results by myself but sometimes i need the help of experts to make sure that what i deduced was correct.

Sergey Alexandrovich Kryukov 1-Feb-12 14:18pm

Good to know that. Getting to the essence of things is very important and will pay off very well later.

By the way, your question sparkled some discussion on delicate detail of syntax which is maybe not so principle and rarely used by good to know. Please see our little argument with Pete over his answer and my reply; please see further discussion and my update in my answer (commented [EDIT]).

So, thank you for raising the issue. :-)
--SA

mhamad zarif 1-Feb-12 14:25pm

Those days i am so interested in oop, since i am moving to a big company for the first time in my life and they work on oop. So iam gaining knowledge in its principles(poymorphism,abstraction,encapsulation,inheritance),and i managed to understand everything, but i still have a problem in designing my classes reflecting my tables in database.So i think when i staart working i will gain this knowledge.

Sergey Alexandrovich Kryukov 1-Feb-12 15:33pm

Well, Analysis is apparently easier than Synthesis.
Wish you success in both :-)
--SA

mhamad zarif 1-Feb-12 16:15pm

thank you :)

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)

Pete O'Hanlon · Accepted Answer · 2012-02-01T04:58:00

Solution 1

You write a virtual method to provide the ability to override it, not to hide it.

Abstract method - this time you must override it (actually, you're providing an implementation) - you don't hide it.

Strictly speaking, if the method exists in a non sealed class, you could changed the implementation using the new keyword. The problem with this, though, is that you could end up not setting something or changing something that further methods on that class rely on. This approach hides the method in the class being derived from, so you have no access to set it.

Remember, if a method wasn't declared as virtual, there was a reason for this.

What are you trying to achieve here?

Posted 1-Feb-12 4:58am

Pete O'Hanlon

Comments

mhamad zarif 1-Feb-12 12:01pm

After further reading i deduced the following : Virtual method is a method that has implementation and it "can" be overridden in child class(not necessarily overridden).While abstract method has no implementation and it "must" be overridden in child class. Also abstract methods are only declared in abstract class while virtual can be declared in any class(abstract or not).And i cant override a method that is neither virtual nor abstract.Finally i use hiding when a method in parent class is neither abstract nor virtual in order to have different implementation in child class. Do you agree ?

Sergey Alexandrovich Kryukov 1-Feb-12 13:16pm

Mhamad,

I think you need to understand the mechanism itself using the "gray box" approach. To do that, you need to read about virtual method tables, "dynamic dispatch" and "late binding". You can start with the Wikipedia articles you can easily find on these topics.

--SA

Pete O'Hanlon 1-Feb-12 12:15pm

Correct.

mhamad zarif 1-Feb-12 12:45pm

thanks :)

Sergey Alexandrovich Kryukov 1-Feb-12 13:14pm

Pete, I added my answer.

In your answer, "you don't hide" is not 100% accurate. You can actually use hiding with "virtual", I tried it, with reasonable results. Completely different aspects are messed together though, so it's best avoided. It's kind of hard to describe all possible variant despite the fact it is all trivial, but I tried. Please see my answer.

Also, it looks like you did not answer the last question (the answer is: "no, you cannot").

I'll vote 4 this time.
--SA

Pete O'Hanlon 1-Feb-12 14:00pm

I said "you don't hide" against the abstract method, not the virtual one, so the accuracy is 100% on that one. Maybe it's just my idiomatic approach to the English language didn't render that clearly enough.:)

Sergey Alexandrovich Kryukov 1-Feb-12 14:10pm

Perhaps. As you mention "virtual", not "abstract" in this sentence, one could not see that you actually mean "abstract", and for "virtual".

But the main thing is: your note is not saving the slight incorrectness you put in your answer. In a minute, I'll add another code sample in my existing answer which will proof that hiding and resolution using "new" still can be used with "abstract" the same way as with "virtual", so you will just have to admit my correction was valid. Please see my updated answer after [EDIT].

Respect,
--SA

Pete O'Hanlon 1-Feb-12 14:24pm

I've reread my answser and I can't see where you think I'm saying "virtual" instead of "abstract" when I said "you don't hide".

I quote: "Abstract method - this time you must override it (actually, you're providing an implementation) - you don't hide it."

Anyway, I give you that you can hide it - it violates so many basic principals that I've never even thought of trying it. What twisted effect were you trying to achieve to come across this little gem?

Sergey Alexandrovich Kryukov 1-Feb-12 14:53pm

OK, more exactly, you used both terms (sorry for confusing reference to your text): first sentence - virtual, second sentence -- abstract. Actually, this is irrelevant, because I illustrated in my code samples that you can hide the method of a base class in both cases. Can you see?

See also my last comments in the discussion with OP in the comments to the original question.

--SA

Sergey Alexandrovich Kryukov 1-Feb-12 15:01pm

By the way, there is no twisted effect, all totally valid and predictable.

The only problem is: hiding means a very poor code style in almost all cases (I know rare cases when it makes sense, but only when you have to use some poorly designed library which you cannot modify, so hiding can only be a work-around).

Hiding is only a matter of poor style, on par with such thing as insignificant names, too short names or violating naming conventions -- very bad for maintenance, valid formally.

--SA

Sergey Alexandrovich Kryukov 1-Feb-12 14:13pm

Done, please see.

Of course, this argument is no so principle. Nevertheless, this is the syntax as it it.

Thank you (and OP) for useful discussion.
--SA

Espen Harlinn 1-Feb-12 16:49pm

5'ed!

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-02-01T07:10:00

Solution 2

First of all, there is no such thing as child class. The relationship can be "base class (ancestor) — derived class"). It is also called "generalization".

The keyword "new" is important to avoid compilation warning related to the fact that you hide some member of the base class. Consider this:

C#

class Base {
    internal virtual void Shaded() {}
}
class Derived : Base {
    internal new void Shaded() { }
}

[EDIT: to prove my point in a little argument with Pete, please see his answer]

Exact same thing is valid if the method in a base class is abstract:

C#

abstract class Base {
    internal abstract void Shaded();
}
abstract class Derived : Base {
    internal new void Shaded() {}
}

[END EDIT]

If you remove new, the warning is: "Warning 2 'Derived.Shaded()' hides inherited member 'Base.Shaded()'. To make the current member override that implementation, add the override keyword. Otherwise add the new keyword."

By saying new you say: "Yes, I hide the member, but not accidentally. I know what I'm doing. Don't worry, comrade compiler, I'll be just fine without your silly warning!"

Needless to say, it should be best avoided in most cases (which do exist). It's even better not to mess up with virtual (as shown above), but it principle this is possible.

Now, if you remove virtual from Base.Shaded or add virtual to Derived.Shaded, the effect will be the same. In these cases, nothing object-oriented happens. The only object-oriented effect (late binding) is possible when first method is marked virtual or abstract, and the second one — override. Then the dynamic dispatch of the call happens even if you compile-time type is Base.

That comes to your last question. The answer is: no.

—SA

Posted 1-Feb-12 7:10am

Sergey Alexandrovich Kryukov

Updated 1-Feb-12 14:33pm

v6

Comments

mhamad zarif 1-Feb-12 13:14pm

Thank you very much. You made it crystal clear as Pete O'Hanlon did(look up please). I always learn from you SAKryukov. You are just and simply great !

Sergey Alexandrovich Kryukov 1-Feb-12 13:17pm

You are simply a shameless flatterer :-) but thank you very much for your nice words.
You are very welcome.

Good luck, call again.
--SA

mhamad zarif 1-Feb-12 13:20pm

why are you saying to me shameless flatterer ?

Sergey Alexandrovich Kryukov 1-Feb-12 13:32pm

"Shameless flatterer" is the cliche of English language. Sorry if I confused you with this thing.

It means: "How can you attribute so high qualities to me which I don't really have?" or "You are telling so exaggerated compliments to me which I don't really deserve, but you are telling them feeling no shame :-)"

"To flatter" means to tell overly nice or exaggerated compliments to someone.

--SA

mhamad zarif 1-Feb-12 13:34pm

ah OK. My bad i did not know that it means this. But at the end off course you deserved what i said with no doubt.

Sergey Alexandrovich Kryukov 1-Feb-12 13:36pm

I don't know at what moment did you read my previous comment (explanation of the cliche expression), but I just put couple of fixes.
--SA

mhamad zarif 1-Feb-12 14:37pm

I am surprised that we can use new with abstract also ! but logically i dont see it good, since and abstract method has no code and it should be overridden logically but it seems that the logic of abstract method is not well applied in the syntax that c# is giving. I think that it should generate an error when using new with abstract method. What is your opinion ?

Sergey Alexandrovich Kryukov 1-Feb-12 14:45pm

The "new" is used not at "abstract" (how could it) but where you try to hide this abstract method name in the derived class. Please see my second code sample.
--SA

mhamad zarif 1-Feb-12 14:40pm

Oh.. i just tried what you did by putting new instead of override in the derived class but it generated an error. Didn't it generate an error for you.

Sergey Alexandrovich Kryukov 1-Feb-12 14:46pm

No. I actually tried it all before posting. You probably did not reproduce 100% of my code. Also, I tried it only in .NET v.3.5.

Also, I think I explained the background. When you hide some name, it does not mean the name of what it was in the base class. "Hiding" simply means creating a brand new totally unrelated member which only has the same name as the name in a base class, confusingly. "New" is only used to de-confuse the compiler. If you don't use "new", the functionality will be exactly the same during run time, but you will suffer a compile-time warning.

--SA

Espen Harlinn 1-Feb-12 16:49pm

Excellent, my 5 :)

Sergey Alexandrovich Kryukov 1-Feb-12 20:32pm

Thank you, Espen.
--SA