Q1: Does C# allow classes to have multiple inheritance?

C# allows you to to have multiple interface inheritance, but it does NOT allow you to have multiple implementation inheritance like C++. Get over it - this design decision actually makes things easier most of the time.

Q2: Can you add static methods to an interface?  

NO. Although other languages like PHP have this (Late Static Binding), in C# the designers stuck with the OOP principle that interfaces define behaviour of instances - that is they define a contract but not the implementation, hence static methods should be excluded. Java also prevents this. From a technical standpoint it is certainly possible for both Java and C# to add this feature but I suspect the respective language designers would need to be convinced before that happens.

Q3: Can you add operator overload definitions to an interface?

NO because operator overload definitions are static methods and static methods are not allowed in interfaces.

Q4: Can you add accessibility modifiers to interface members?  

NO. The point of an interface is to describe a contract between an implementing type and users of the interface. Outside callers aren't going to care and shouldn't have to care about implementation. If an interface is public then every part of that contract has to be public, otherwise it would mean one thing to friend/internal classes and a different thing to everything else. If you need default implementation then it's best to use an abstract class.

Q5: What's the difference between explicitly and implicitly implemented interfaces?

Unlike C++, in C# we can implement an interface implicitly as well as explicitly. Explicitly implemented interfaces are only available when the instance is cast to that interface. In contrast, implicit interfaces are available via the instance and via a cast of the instance to the interface in question. Explicit interfaces also help skirt the classic diamond problem associated with multiple inheritance and they are allowed to be private if necessary, but they cannot be virtual or abstract. Implicitly implemented interface member functions can be virtual or abstract, but they have to be public.

Q6: Can you define a default, parameterless constructor for a struct? 

NO. Structs provides value-type semantics, while classes provide reference-type semantics. So for efficiency in creating a struct, the rule adopted by the C# team was "the default value for any type can't rely on any initialization". Instead, the C# team resorted to the same trick they use to default value and reference types - doing a bitwise zeroing of the storage location. This results in 0 being assigned to value types used in structs and you can't do anything in the default constructor to change this since you're prevented from creating one.

Q7: Can structs implement interfaces?

Yes they can, but beware - when you cast a struct to an interface it implements you are implicitly boxing the struct since the interface reference is a reference type. This can lead to subtle issues in code as can be seen here.

Q8: Can structs be sub-classed?

NO they are implicitly sealed.


Q9: What sort of static constructors are you allowed to define on non-static classes?

Only a parameterless one - with the same name as the class obviously. Why? Well, a static constructor is run once per type, rather than once per instance, and it is guaranteed to run before any instances of the class are created, before any other static methods are accessed, but after static field initialization occurs although we don't know exactly when it runs - that part is non-deterministic. Since we don't explicitly call the constructor there is no way for the programmer to pass in parameters which is why the compiler ensures you don't waste your time writing static constructors that take parameters.

Q10: Can static constructors of non-static classes be called explicitly?

NO. They are only ever called implicitly by the runtime, and the timing of these calls is non-deterministic.

Q11: Can static classes be sub-classed?

NO. Static classes are implicitly sealed.

Q12: What is meant by the statement "References in C# are polymorphic"?

It means that a reference to a base class can point to an instance of a sub-class. That allows the developer to have methods parameters defined as the base type which accept any sub-class of that base type! Extremely handy.

Q13: Why is calling virtual-methods in a constructor a bad thing?

Consider the case where you have a base class and a derived class and the constructor of the base class calls into a virtual method which is defined in the base class but also overridden by the derived class. In C++, the base class is guaranteed to be created before the derived class so when the constructor of the base class is run it sees the most derived function as the one it has defined. In C# the base class constructor will also run before the constructor of the derived class but calls to virtual methods are always passed to the most derived version which will be the overridden function in the derived class. The problem with this is that the derived class has not been fully initialized at this point and it's constructor hasn't even been run. This is because initializers run in the opposite order as constructors. The fact that the derived class running the virtual override is not fully initialized leads to subtle side-effects that confuse the hell out of people and eventually breaks code. For these reasons it's good practice to avoid calling virtual methods from constructors, unless the class is sealed. IMHO this is one behavior where C++ is more intuitive than C#.

Q14: Is an overridden class member virtual? 

YES. If B is a sub-class of A and overrides a virtual function in A, the function can be overridden again by C, a sub-class of B. This pattern exists unless you use "override sealed" which is equivalent to the "final" keyword in Java - it prevents further overriding thus ending the virtual chain for that specific method.

Q15: Are instance members virtual or non-virtual by default in C#?

Non-virtual. Interestingly, unlike C# which requires the virtual keyword, instance methods in Java are virtual by default. C# went against this for performance and versioning reasons. They figured Java developers often forget to use the final keyword.

Q16: Can you declare a virtual static method in C#? 

NO. Makes no sense. To quote Eric Lippet... the core design principle of static methods, the principle that gives them their name, states that static methods can always be determined exactly, at compile time, what method will be called. That is, the method can be resolved solely by static analysis of the code. Virtual is the exact opposite - the virtual keyword tells the compiler that the method to be called will be determined at run time and based on run time type information.

Q17: Can you have abstract static methods in C#?

No. Abstract methods are implicitly virtual so the same argument applies as given above. See Section 10.6.6 in the C# spec... "When an instance method declaration includes an abstract modifier, that method is said to be an abstract method. Although an abstract method is implicitly also a virtual method, it cannot have the modifier virtual."

Q18: Does the "protected internal" access modifer mean OR or AND?

protected **OR** internal. Not both.


Q19: Can you override static methods in sub-classes?

No - in both Java and C#. It makes no sense to have virtual and overridden static methods.

Q20: Can abstract and virtual methods of a class be marked as private?

No because it makes no sense. The purpose of virtual and abstract methods is to permit/force a derived class to override the base functionality. Hence allowing these to be private defeats that purpose and is disallowed. Note that abstract methods are implicitly virtual.

Q21: Which of these must be done explicitly: upcasting to a base class, or downcasting to a derived class?

Downcasting to a derived class. Since upcasting to a base class is a safe operation that is guaranteed to work it is done implicitly. Conversely, downcasting is not a safe operation which is why the compiler requires you to do it as an explicit cast so it is clear on your intent.

Q22: When you upcast a reference type what happens to the object instance that you apply the cast to?

Nothing. Casting affects only the references. The object instance is not touched.

Q23: Do sub-classes automatically expose the same constructors as their base types?

NO, you have to manually re-declare them.

Q24: Does C# support covariant return types?

NO it doesn't - that's a CLR restriction, not something specific to C# - but they can be simulated using explicit, generic interfaces. Bill Wagner has a good article on that here. This is definitely one thing C++ developers find frustrating when moving over to C# since covariant return types are supported in C++ and Java. [According to this, Microsoft has no plan to change this in the future, however C# 4.0 is planned to allow co- and contra-variance on parameterized interface and delegate types.]

Q25: Can you declare a generic property in C#?

NO, only methods and types can introduce new generic parameters. Properties can of course use existing generic parameters defined in the containing class.

Q26: How do you define a concrete class that implements both an interface and a base class in C#?

You need to specify the base class first after the colon before listing any interfaces implemented.

Bookmark and Share