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 3 years ago.
Improve this question
Dear editors, Why you mark this question as Opinion-based? I have no opinion, I just asked a basic question.
I have a basic confusion with C# 8 Interface implementation concept, As you know Interface is not more than a Contract, Why we need to default implementation? Is it correct conceptually? Why a Contract must have an Implementation?
Suppose we inherited from an interface in different places if we wanted to add a new member
and we don’t want to affect any existing class with this change.
This is how we define interface with current version of C# and we are stuck.
In C# 8.0 we can solve the problem by providing implementation to method.
Default implementations is powerful language feature coming to C# 8.0. Although it may seem dangerous for some developers then others will certainly be happy with it. Those who are writing libraries and components for public use may find default implementations specially useful as they let us avoid breaking changes in interfaces.
Document
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 8 months ago.
Improve this question
I have a generic interface and I have no functional need for a non-generic version. However, all of the CLR and professional code I've seen has defined a non-generic base interface. Is this for a functional reason, a guideline, or just community habit?
No, if there is no functional need for it, don't add it.
There is some legacy in the framework classes due to historic reasons. But if you take a look at some newer interfaces like IReadOnlyCollection it only have a generic version. Older interfaces like IEnumerable predates the generic version.
There are some situations where a non generic base type is useful, like when you want to treat a bunch of objects with different generic parameters in the same way, but that is a rather specialized use case.
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 2 years ago.
Improve this question
Where does the concept of C# Properties come from? And are they part of Object Oriented programming paradigm?
Some other OO languages such as Java or C++ do not have Properties. Due to on-Topic guidelines of this forum, I am not asking about Pros and Cons of Properties but it's origin.
The concept of a property in OOP is based on Bertrand Meyer's uniform access principle. The idea behind this principle is that directly exposing a field violates encapsulation by showing how a class is implemented.
Clients of a class should not know or care whether the data they ask for is stored in a field or computed on demand. This implementation detail is unfortunately built into languages like Java where the syntax for accessing a field differs from the syntax for accessing a method.
Languages that support properties close this encapsulation loophole by providing a uniform syntax to hide the implementation detail.
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 5 years ago.
Improve this question
I've read Clean Code by R.C. Martin and I'm trying to adopt his suggestions about clean code as broadly as possible.
But I'm not sure how to name related classes.
Let's say I have a class named TreeDirectoryList.
I want to cut implementation of this class into many smaller classes.
Let's say I'll create a class named ParentIndexStack.
ParentIndexStack will implement functionality very dependent on TreeDirectoryList, so it's very not probable that this implementation of ParentIndexStack will be useful with any other class in the future.
But the name of ParentIndexStack is very generic, it's possible, that I'll need another class with the same name, within the same project.
So I thought I'll name ParentIndexStack more precise, like TDLParentIndexStack (prefix TDL is from TreeDirectoryList).
Would it be correct ?
I'll end with many classes starting with TDLxxxxx.
One option is to put that set of classes in their own namespace. Then you can have simple, concise names that still communicate the full meaning of the class through the namespace context.
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 explored c# source code reference. And I came across with interesting mention of IArithmetic<T> interface. For example, Int32, Double contain commented implementations of IArithmetic interface. I am interested by these details. As I understood, it is attempt to add "supporting" of arithmetic operations. But why are they commented? Is it bad way to add supporting generic "operators"?
It was probably scrapped due to performance reasons and not very much usability.
Primitive types supporting arithmetic operations through an interface is really not a very attractive scenario; performance would be horrible compared to simply using the value type itself due to the necessary boxing and unboxing.
What possible uses? Well, the first one to spring to mind would be the following scenario:
public Matrix<T> where T: IArithmetic<T>
or some such. Although this could be interesting, due to performance reasons, it would probably need to be solved some other way, not through interfaces; read this for very educated musing on the subject.
On top of all that, if you really need something similar to Arithmetic<T> you can always build your own with an added level of indirection.
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
I am working with several developers who develop .net components for me.
I manage the licensing mechanism and want to hide the implementation.
I would like to just provide them the interface, with for example the methodIsLicenseValid() so they must use it in the code but cannot access the implementation.
Which pattern or technology should I use to reach that objective?
You should be using a Web Service to expose the methodIsLicenseValid(), and let your devs invoke it whenever necessary.
This will be suitable for your production environment anyways and also will allow you to change the implementation of the methodIsLicenseValid(), without causing hasles to the devs, as opposed to providing a library/dll to them