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 got this idea from Java - i was told that you should declare a collection like this
List<Object> myList = new ArrayList<Object>();
where ArrayList is a class implementing List interface. The point of this is to enhance maintainability by generalizing code - as, should you change teh implementation to, e.g LinkedList<Object>, you could to it 100% painlessly.
So, projecting this on C#, is it considered a good practice to do the same thing in C# :
IList<Object> list = new List<Object>()
?
EDIT : i just found that LinkedList in C# does not even implement the IList interface, so i guess it settles the question for lists at least
Yes, generally this is a good practice to use interfaces wherever you can.
There are two important exceptions for containers, though:
When you must use a hash-based container for objects that are not comparable, use HashSet<T> or Dictionary<TK,TV>,
When you declare a local variable, using var for implicit typing is often preferred for convenience,
Note that if you plan to use a sorted container you have IOrderedSet<T> and IOrderedDictionary<TK,TV>.
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
I have a methode searching for a winform control by name. My first approche was to do it like that
private Control SearchControlByName(Control parent, string name){recursive search...}
Calling the methode looks like
Label temp = (Label)SearchControlByName(panel1, "label4");
Then a thought to myself it would be better do do it with an generic methode like this
private T SearchControlByName<T>(Control parent, string name) where T : Control {recursive search}
calling like
Label temp = SearchControlByName<Label>(panel1, "label4");
And now I'm not sure which is the better approach. What are the advantages / drawbacks of the generic method vs casting after calling the method?
In the generic methode I also have to cast the result like this
return (T)result
I don't think there are any disadvantages.
Since there are at least two advantages (see below), I would use the generic version.
It's prettier (no need for that cast).
You could use OfType<T> on Control.Controls inside the implementation (your recursive search) so you don't have to worry about returning a Label when the person wants a PictureBox. However keep in mind that you can only do that at the bottom level, otherwise you won't go through all the elements of course.
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 7 years ago.
Improve this question
Is there any preference on either appending DTO or Entity to a class name?
Is there any standard around this?
1 Class is used by ORM (EntityFramework) and the other class is used for serialization.
The reason for this is so that there is no duplication of all fields as the EntityFramework is a wrapper around the DTO class(most but not all properties).
The DTO class is in a shared library, and decoupled from EF.
E.g. Which of these is the most common/standard approach?
// 1.
MyNamespace.Entities.MyClass
MyNamespace.Models .MyClassDto
// 2.
MyNamespace.Entities.MyClassEntity
MyNamespace.Models .MyClass
// 3.
MyNamespace.Entities.MyClassEntity
MyNamespace.Models .MyClassDto
In my personal experience your third example is the only implementation I have worked with and it is the one I would argue for because the intent of the object you are working with will always be clear whereas with the other two it only becomes clear when looking at both objects together.
That being said as long as your team comes to an agreement on which to use any would work.
In my opinion, you typically don't want to put implementation details into class names for similar reasons to why you don't want to use Hungarian Notation.
If there's a bit of code that needs to work with both types and differentiate between them, another option is including aliased using statements like this:
using entities = MyNamespace.Entities;
using dto = MyNamespace.Models;
//in code
var myClassEntity = new entities.MyClass();
var myClassDto = new dto.MyClass();
//work with both
My assumption is that the code that needs to work with both types is limited to an isolated library, and that client code typically works with one, not both types.
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 8 years ago.
Improve this question
I have been learning collection and generics and understood that generics were introduced to
provide more type safe containers and to improve the application performance by reducing number of boxing/unboxing.
But, If that was the case, why does the framework allows to create generics collection of type system.objects which can take any other type?
List<object> listObj = new List<object>();
listObj.Add(new Program1());
listObj.Add(new Program2());
Thanks in advance.
Yes the collection is List<T> is object not a type? object is a type like any other (being the base type doesn't make it any different) and therefor can be used as the type argument for generic collections, there is nothing wrong with that, just don't do it when you know what the specific type is.
I would say: why not. A list of objects, in which form you want it is totally legit. I personally don't want the framework to tell me what to do. It is fine to do suggestions, but prevent this code? No.
If you want a list of things that are neither the same type, nor share a base class, nor share an interface, then you need List<Object>.
You very rarely need this.
But if you pursue the thought that List<Object> should be disallowed because it encourages unnecessary and dangerous downcasts, and anyway with generics you can just specify the types actually can handle, shouldn't you then go all the way and disallow the use of Object entirely?
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
Original Questions: I know the question sounds pretty "thin", since generic classes (interfaces) and collections go hand in hand. Out of curiosity and a desire to 'cover all the bases' ... are there uses for these generics other than as collections?
The response is that there are too many possibilities to make for a good thread, so let me try to clarify the question because I ( and probably others) will definitely benefit.
My revised question is:
What are applications of instantiated generics (not methods!) in addition to collections? So, now I know there are many ... however, classified by use... what are they?
A concise format for answers is:
Use: Short description or example
(ie) Collections: The generic allows for collections of objects and with a where T: constraint gives access to methods on all members of the collection. (link or reference).
I'm really eager to hear responses.
You can create not only generic types but also generic methods. Though the most common use of generics is for creating collections they are also used for many other purposes such as containers or algorithms.
class Point<T>
{
T x;
T y;
};
class Math<T>
{
T Add(T a, T b);
};
You should also have a look at this discussion: What is cool about generics, why use them?.
I've used generics for a "EventHandler" (with a restriction on the generic that the parameter implemented my BaseEvent class) when sending events via WCF to another piece of the system.
As the comments note, the answer is unequivocally yes. You use generics whenever multiple types (and ideally all types) should have the same behavior (and occasionally state). Collections are an easy example of this, but there are many, many other situations where this holds true and generics are a good choice.
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
Writing UnitTests with MSTest I want to assert the equality of a return value vs. the one I'm expecting.
Expected type is a custom type that does not implement the IComparable interface nor the IEquatable interface, thats why I want to give Assert.AreEqual a possibility to compare the two objects.
I am aware that this possibility exists in CollectionAssert.AreEqual. This method however requires two ojects that inherit ICollection which my objects do not.
Why does Assert.AreEqual not allow me to specify a custom comparer? Am I missing something?
Not sure if this is the actual reason, but what if your custom IComparer was faulty - your unit test would be meaningless (bearing in mind that the test framework has no way to tell if you wrote unit tests for it let alone if they are "correct")
Could you just create a comparer in your test?
var com = new MyComparer<Foo>();
int expected=0;
int actual = com.Compare(a,b);
if (actual!=0)
{
Assert.Fail("oops");
}
Maybe not ideal, but should work...
I also found this question from a few years ago on msdn, with no answers - but an interesting approach to the workaround by the question poster.