Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I don't know whether this question will make sense or if it's a naive question, but I haven't been able to find a satisfactory answer.
I would like to be able to share code across multiple static classes. Is there an "equivalent" of an abstract base class for static classes (i.e. can I have one static class inherit from another one)? If not, why not? Is there another way of sharing code across multiple static classes in a manner analogous to what you do with an abstract base class?
Also, how does a static class compare to a "sealed" class?
You're quite right. Reflection will show that a static class is both abstract and sealed:
public static class MyStaticTest {
}
...
// I'm abstract
Console.WriteLine(typeof(MyStaticTest).IsAbstract ? "I'm abstract" : "");
and that's why you can't create an instance (compile time error): new MyStaticTest();. However, reflection will show that any static class is sealed as well:
// I'm sealed
Console.WriteLine(typeof(MyStaticTest).IsSealed ? "I'm sealed" : "");
and so you can't inherit from it (compile time error): public class MyClass: MyStaticTest {..}. Thus, all you can do with static class is to declare static members (static fields, properties, methods etc.)
The abstract keyword enables to create classes and class members that are incomplete and must be implemented in a derived class whereas The sealed keyword enables you to prevent the inheritance of a class or certain class members that were previously marked virtual.
I think its complete for Above
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 months ago.
Improve this question
I've tried to search for other questions like mine but I can't find any good result
I'm trying to use a DLL that has a method that need to be called with a new class but that class is abstract.
thanks.
i tried to use new IClientHandler but it just errors
You're trying to instantiate an abstract class in C# code. This is not possible, as an abstract class is a class that cannot be instantiated on its own. Instead, you would need to create a non-abstract class that extends the abstract class and then use that to create an object.
Here's an example:
abstract class AbstractClass
{
public abstract void AbstractMethod();
}
class ConcreteClass : AbstractClass
{
public override void AbstractMethod()
{
Console.WriteLine("I'm a non-abstract method!");
}
}
// Now we can create an instance of ConcreteClass
var instance = new ConcreteClass();
You can then call the AbstractMethod on the instance object, since it has been implemented in the ConcreteClass.
Also my small mistake, as #ewerspej noticed:
IClientHandler is an interface, not an abstract class. Neither can be instantiated. Interfaces require implementations that can be instantiated and abstract classes must be extended by non-abstract classes that can be instantiated.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I have a hard time to figure out, how I can implement seemingly easy patterns with the strict typing system that C#'s generic system is restricted to. Coming from a mostly Java background, I am used to wildcards for generic types. Since C# does not allow such things I need your help to figure out the most elegant way to implement the following (my implementation is for a Unity3D project but that's really not important I think):
I have Content Providers that can provide various types of content (s.a. objects of the type "Texture", "String",...)
Therefore I created an abstract generic class and an interface such that my architecture look like this
Furthermore I have Content Receivers that are able to handle the content of a certain type and a managing class with a set of such Content Receivers. I want the logic for what receiver has to deal with the content of a given provider in a style something like this:
public void accept(IUIContentProvider provider){
//1. Check if a receiver for the generic type of the provider exists
//2. Ignore the call if no such receiver exists, otherwise pass the provider to this class and
//let it deal with it in some specific manner.
}
But due to the strong type system of C# it seems to be impossible to do anything elegant using Polymorphism. I also can not explicitly convert the IUIContentProvider apparently. I can not even use an abstract base method like:
public abstract object provideContent()
and to override it with e.g.:
public override Texture provideContent(){...}
At this point I start to wonder if it is even wise to use generics for this purpose in C#...
You said in your abstract/generic class UIContentProvider<T> you wanted to have such method :
public abstract object ProvideContent();
And you want to be able to have this override in your concrete implementation TextProvider :
public override string ProvideContent(){...};
But I think you miss the point of the generic in your abstract class... What is the point of having a type parameter T if you don't use it?
Isn't it what you want ?
public interface IUIContentProvider<T>
{
T ProvideContent();
}
public abstract class UIContentProvider<T> : IUIContentProvider<T>
{
public abstract T ProvideContent();
}
public class TextProvider : UIContentProvider<string>
{
public override string ProvideContent()
{
return "";
}
}
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I got a C# class which is making some actions based on data it receives which is held in other classes:
public Class ActionClass
{
public void DoStuff(List<MyItemsClass> data) { ... }
}
It started as a single class with a single items class, but then I needed to add another action class which does its stuff in a different way and receives different items.
Now I got an abstract class for the action part which enforces its derived class to implement how they do their stuff. It left me with a dilemma about the items class.. I want to have a single signature in the abstract class which receives the needed items class:
public abstract DoStuff(List<MySuperItemsClass> data);
So I created a common ancestor also to the 2 different items classes. However, since they have nothing in common, I got an empty class which now serves only for the purpose of being able to pass that super class, while dynamically instantiating the correct derived classes.
Is it a good practice to have an empty class for the purpose of creating a type? Is there another more common way of achieving what I need without the use of an empty class?
Use generic interface instead of abstract class. Class can implement multiple interfaces.
interface IActionClass<T>
{
void DoStuff(T data);
}
class MyClass : IActionClass<List<MySuperItemsClass>>, IActionClass<int>
{
public void DoStuff(List<MySuperItemsClass> data) { }
public void DoStuff(int data) { }
}
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I know that an interface inherits another interface, and a class can inherit from another interface, but can a class inherit from another interface?
Interfaces are meant to be implemented by classes. when you declare an interface you expect to work with an instance that implements it - that instance must be a class, since you cannot instantiate interfaces.
The case when you declare an interface which inherits from a different interface is possible, and allows you to separate the responsibility of each interface, but force a class to implement all of those responsibilities
As mentioned in my comment on the question, MSDN example for implementing interfaces HERE
It's called "implementing" the interface.
If interface Inter1{} and class A : Inter1, then if class B : A, class B will also "inherit" the interface Inter1.
From Microsoft's Inheritance (C# Programming Guide)
A class or struct can implement multiple interfaces. A class can inherit a base class and also implement one or more interfaces.
So, a class:
can implement multiple interfaces (no limits)
inherits from a base class (just the one. If none is declared, the base class is object by default)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have a class with only static methods. Should the class itself be made static too? Does it matter?
Does it matter?
Making a class static ensures that it can never be instantiated by generating a compiler error should the user attempt to do so. If the class, consisting of only static members, is simply not intended to be instantiated, there is no reason not to make it static. You can choose not to do so, but instances of such a class aren't going to be very useful, and users creating these instances are going to be left quite confused.
On the other hand, if you intend for instances of this class to be created but you expect derived classes to implement their own instance members, chances are that this class should be abstract, rather than static (and perhaps those instance members should be stated upfront via abstract definitions or an interface).
In general: Yes.
You can prevent the programmer to create object instances of a certain class by making the class static. If this is what you intend, then do it. This prevents mistakes, by showing (other collegues, etc.) that the class is not intended to be instantiated.
public static class A
{
// Some static member
}
A a = new A(); // Compilation error