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.
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 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 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 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 years ago.
Improve this question
Let's say I have a class named Rectangle and it has some attributes like: color, width, height etc. So this class will for sure describe this object but I also want to save this object to database and later read and create object from db.
My question is should this class also have methods like "SaveRectangle", "GetOneRectangle ", "GetAllRectangles", "EditRectangle" that handles the SQL operations or is there a other good practice?
I would suggest you check out Martin Fowler's "Patterns of Enterprise Architecture".
There are several different patterns for data persistence. The pattern you describe is "Active Record". It can definitely make things easier in the short term but I have found that it often leads to issues when working with many objects.
I typically choose to use a combination of the "Data Mapper" and "Table Data Gateway" patterns that separates storage/retrieval concerns from the objects themselves. That allows me to handle both separately and, possibly, more efficiently.
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).
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
My MainViewModel has to deal with a lot of commands with complex actions inside, therefore its extension has grown inevitable. For keep the code organized I tend to use #region to group similar o related tasks.Does this considered an overuse of this feature or it's perfectly normal? You may say that it depends on me, if I feel right about it. I think that it helps a lot but I would like to know what do others. Here is a screenshot of how the code look like:
The bad practice is a massive single class. #region is simply hiding / coping with it.
If there are groups of methods, delegate them to another class.