Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Soon I was writing code in .net framework, I needed a method but can't access that. After a search I have learnt to implement an interface first. I know that interfaces provide differentiation or polymorphism (i think). But why did .net framework want me to implement that interface? Why is it necessary?
That was a generic handler that needs IReadOnlySessionState,IRequiresSessionState interfaces for Session usage.
As TomTom said, because it was designed that way... why was it designed that way? here's the most likely answer, the answer why Interfaces are so usefull.
Taken from here
"An interface contains definitions for a group of related functionalities that a class or a struct can implement.
By using interfaces, you can, for example, include behavior from multiple sources in a class. That capability is important in C# because the language doesn't support multiple inheritance of classes. In addition, you must use an interface if you want to simulate inheritance for structs, because they can't actually inherit from another struct or class."
In your case you are implementing multiple interfaces.
As for Polymorphism...
"A base class can also implement interface members by using virtual members. In that case, a derived class can change the interface behavior by overriding the virtual members. For more information about virtual members, see Polymorphism."
Related
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 1 year ago.
Improve this question
We all know that interfaces and abstract classes are needed for many design principles, and were told to be "the best practice" of programming, both for maintenance and expansion purposes.
But I also heard people saying, "Do NOT overuse interfaces or abstract classes"!
So then, how do I "draw the line"?
I know the difference between interface and abstract class (kind of).
So I'm not interested in "when to use which?", I'm interested in "when is too much"?
For example, the example given by r/PiggyChu620 from this post is clearly "overengineering" the interfaces, as r/AlarmedSlide1 down below puts it.
So to avoid the same mistake r/PiggyChu620 did, is there any "borderline guideline" as to "when should I use interface/abstract class and when should I not"?
Thank you very much for your help!
It's actually pretty easy.
If you can delete an interface from your code (maybe replace it with a specific class when it's used as a parameter) and your code still works, it wasn't needed.
As with every tool, the answer to the question "when should I use it" is "when you need too". If you use it "just because", then you probably make your program simpler (and therefor more maintainable) when you don't use it at all.
Interfaces, Base classes and OOP are important because you are solving problems with it. If you find yourself doing it without solving an actual problem with it, I would consider it "overused".
Interfaces are contracts that are signed between classes, and all classes that use it are bound by the rules of the interface.
This type of design makes it easier to reuse and increases maintenance.
Suppose you create a vehicle interface. All vehicles must implement this interface, including bicycles, motorcycles, cars, etc.
This style of design creates blood and creates a beautiful and principled architecture for your program
So if you have classes that behave similarly, you can use interfaces or abstract classes.
You can refer to this link to compare abstract classes and interfaces
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
My teacher kept saying that interfaces are not there so one could use them as a way to achieve multiple inheritance in c#.
Why is that? What are they for then? Noone could explain this to me easily yet, I'm so confused.
I read a few articles and books that described interfaces and it seems that all of them are suggesting to use interfaces as a workaround to implement multiple inheritance..
In a statically typed language, or when using static typing in a language that has both dynamic and static typing (such as C#), then inheritance consists of two pieces. The interface, and the implementation. The interface is a contract that says that it will fulfill a specific set of methods or properties. The implementation is the code that actually does it. Code implements an interface.
Interfaces are used to guarantee that an object implements specific contracts. This can be a single contract, or multiple ones. This is not multiple inheritance, which inherits both the interface and the implementation.
Yes, some people try to simulate multiple inheritance with multiple interfaces, but that's not its purpose, and that simulation is very poor anyways.
Multiple interfaces says that an object supports multiple contracts. Multiple inheritance says that an object re-uses multiple implementations. Again, inheritance requires both interface and implementation. Interface implementation is just the interface.
Interfaces form a contract (they say what an object can do), but don't provide implementation.
Why bother? Defining the contract is extra work, why not just create a class?
For example, let's say you want to develop a drawing app. You may come up with few objects like Circle, Triangle, Square, etc. then you start adding methods and add something like Draw(). That is something you could add to the interface that all shapes implement. In C#, by convention it would be named something like IDrawable.
But why not a class?
Let's imagine you are extending the app and adding a support for grouping shapes, to create more complex patterns. The groups can also be drawn, so they also have Draw() method. Now, if you only want to draw the "thing", you do not need to know if it is a shape or a group, or something else you haven't invented yet.
But why not a class?
Because there could be more capabilities, like Move(), Serialize(), etc, and C# doesn't allow you to inherit from multiple classes.
Why not?
It is not a technical limitation, but a choice made by C# language designers. Some languages, like C++ allow it, but it brings few technical problems, most famously the diamond problem. It also makes the compiler more complicated and it's been decided it is not worth it. It also
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 want to create many Service classes that use a common set of functions. All these classes will inherit ClientBase class which is provided by Microsoft. Currently I have written those common functionalities as private methods in class. What is the best way to do it to avoid code repetition and efficiency. I cannot add those common methods to base class as it cannot be modified.
Have your own abstract base class that inherits ClientBase<T>, call it MyClientBase<T>, move the common methods to it and make them protected so that successors could access them. Then make your service classes inherit MyClientBase<T>.
If all other classes are directly inheriting from ClientBase<T>I would try to define the additional functionalities via extension methods of ClientBase<T>.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
This might seem like a very trivial question to more experienced c# developers but please keep in mind I'am a beginner to the c# language but getting through it very well.
However I have came to a stumbling block regarding creating c# classes. I understand the whole concept of the intrinsic details on how to create the class i.e class is like a blueprint in which you create objects from in which there data is stored in fields in which you use constructors to initialize them (or default) and behaviours are performed in the form of methods bla bla etc etc.
However the question that I have is in regards to the purpose of creating your own classes in c#. I was wondering if we create our own classes like the ones that are available in the .net framework, I.e if the .Net framework hasn't got a class that wee need, so do wee then just create our own class defining the functionality that I need.
Is this the only purpose of creating classes or is this way more focused on creating DLL's, and I am missing something ?
Any ideas tips hints or expansions would be great (in laymen's Terms).
if the .Net framework hasn't got a class that wee need, so do wee then just create our own class defining the functionality that I need.
Yes.
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 9 years ago.
Improve this question
due to unit-testing we create for every class an Interface. The .Net Framework coding standards say that every class, interface, enum, etc. should be located in a different file.
As these interfaces are so closely related with the class we were thinking of creating an internal coding-standards rule to put together the class and the interface.
Have you seen this approach before? What do you think about it?
PD: Always talking about interfaces used only to mock the classes, not 'real' interfaces that can have more than one implementation.
You should follow .NET coding standards and separate the interfaces into their own files. You could create a folder Interfaces within your project. I usually have Concrete, Abstract and Interfaces folders within my projects.
Developers who may be unfamiliar with your solution will have a hard time finding interfaces if they are in class files.