Click here to Skip to main content
13,255,711 members (71,249 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


Posted 28 Sep 2011

Assumed Mistake in Explicit Interface Implementation

, 28 Sep 2011
Rate this:
Please Sign up or sign in to vote.
Assumed mistake in explicit interface implementation

I won't be discussing anything about Explicit interface implementation feature in C# here. I am sure either you know about it or there are many great articles on the web that you can take a look at.

But I must say that you must read the excellent article by my friend Abhiseksur on the internals of Explicit interface implementation feature in C#.

Let me outline a particular point from Abhisek’s article which I or this article is interested in:

  • Explicit method is always implicitly private to its type
  • You can’t modify/specify any modifier to Explicit method

So that means we can't do this as shown below:

1.   interface IMyInterface
2.    {
3.        void InterfaceMethod();
4.    }
6.    class MyClass : IMyInterface
7.    {
8.        void IMyInterface.InterfaceMethod()
9.        {
11.        }
12.    }
       //Compiler Error, since InterfaceMethod is private to MyClass.
14.    new MyClass().InterfaceMethod()

So now, any developer can be relaxed about this explicit implementation method that his code is fail proof since it's private and nobody can corrupt it. Yes, logically at least, it looks like that. But my curiousness doesn’t end here. Now let's see how safe this Explicit implementation method in this class is.

Assume the below code:

1.   abstract class MyAbstractClass
2.    {
3.        public int MyValue { get; set; }
4.    }
6.    interface IMyInterface
7.    {
8.        void InterfaceMethod(MyAbstractClass absClassObj);
9.    }
11.    class MyClass : IMyInterface
12.    {
13.        void IMyInterface.InterfaceMethod(MyAbstractClass absClassObj)
14.        {
15.            var value = absClassObj.MyValue;
16.        }
18.        public void SomeOtherMethod()
19.        {
21.        }
22.    }
24.    class SomeEvilClass
25.    {
26.        MyClass myclass = new MyClass();
28.        public void SomeEvilMethod()
29.        {
30.            (myclass as IMyInterface).InterfaceMethod(null);
31.        }
32.    }

This above code crashes the application. Although it’s not a great catch what I am speculating here, but could be a bit of a flaw if the developer fails to oversee it. I have no idea where and when we make use of this feature. But the workaround I am thinking of is to keep the interface internal, at least you are sure that your assembly code is not evil and you can control it somehow but on the flip side, it won't pay off much if I have an interface which is not public.

That’s all friends, please leave comments for my learning. :)

Thanks for reading.


This article, along with any associated source code and files, is licensed under The GNU Lesser General Public License (LGPLv3)


About the Author

Software Developer (Senior) Siemens
India India
A .net developer since 4+ years, wild, curious and adventurous nerd.

Loves Trekking/Hiking, animals and nature.

A FOSS/Linux maniac by default Wink | ;)

An MVP aspirant and loves blogging ->

You may also be interested in...

Comments and Discussions

QuestionConfused Pin
DaveyM6928-Sep-11 8:05
mentorDaveyM6928-Sep-11 8:05 
AnswerRe: Confused Pin
zenwalker198528-Sep-11 9:27
memberzenwalker198528-Sep-11 9:27 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.171114.1 | Last Updated 28 Sep 2011
Article Copyright 2011 by zenwalker1985
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid