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.
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 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
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 4 years ago.
Improve this question
I was just wondering where there any downsides to using in method argument from c# 7.2
I know this is recommended for dealing with Structs and they say it won't increase performance that much but from what I can tell this won't have any negative impact on the code and might help you with stack overflow exceptions when doing recursions.
Dose anyone know of a good reason why all methods should not be marked as in?
I found why people recommend to avoid ref and out but they don't work here.
As this is a performance related question, as a matter of discussion in was introduced for that reason, it's hard to find single, correct answer, without really measuring performance on concrete code sample.
But...
We know that in creates a reference which is 32bit on x86 OS, and 64bit on x64 OS.
Now consider a structure like
struct Token
{
char x;
}
on x64 OS, copy this structure on the stack, likely, will execute faster, than creating 64bit reference to the same data.
Plus, do not forget, that in implies "constantness" on an instance, which goes beyond performance reasoning, and targets directly your design. Hence, while from performance related matters, some of reasoning might be arguable, from design point of view, in has distinct and clear semantics to target specific design use cases.
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 9 years ago.
Improve this question
Recently I have been asked in an Interview that: "Can you give an example of a situation where is it necessary to break the Inheritance chain?". I am not very sure if I could follow the question exactly.
Does any such situation exist when we to break the inheritance chain?
I tried google, but didn't get any clues.
A. When we get stupid questions that make no sense.
Inheritance is just a tool for managing and re-using code. Composition is a strong tool that is not part of an "inheritance-chain" so I'm guessing that's an answer they're looking for?
Another possible answer they're looking for is utilizing interfaces. As interfaces don't require an "inheritance chain". They enable you to be a little more flexible with your architecture and step away from strict inheritance "chains".
However the question implies that you have a number of objects that all inherit from one another and for some reason you "break" the chain of inheritance somewhere. There is no "set" reason why you'd do this as each implementation of OOP that addresses a problem is typically unique.
The way the interviewer phrased the question makes little to no sense. It's a bad interview question that wont result in the best answers or necessarily tell you anything about a candidate except that they don't understand your madness either ;).
EDIT: added some "better" questions.
Better questions include:
Q. What is the difference between inheritance and composition?
Q. I have the following class model (one crying out for an interface), can I improve it at all?
Q. I'm re-designing a base class and want to prevent other people from overriding this function. Can I do that?
Q. Is there a problem with calling virtual methods in class constructors, if so, what?
There's this blog post with a good explanation on why you'd want to "break the inheritance chain" (or "seal" your class).