Lets say we have class SomeObject with many fields and storing instances in HashSet.
For HashSet comprison we need only one field: int ID, so we have overriden GetHashCode() and Equals() methods.
And now my question is: Can we somehow use hashSet.Contains(someIntVariable) instead of creating whole new object of type SomeObject?
I mean if only int field is important can we use Contains function with int argument given?
I need it to check if object already exists and don't want create whole sample object.
HashSet unfortunately does not have the ability to search with a different type of objects and get what's stored. This capability could theoretically exist and maybe you can find a collection library on the web that does this.
Best workaround:
Create a separate key struct (e.g. MyKey) and use a Dictionary<MyKey, MyValue>. That way you can create a key without creating an object.
Alternatively, you could create a wrapper struct that encapsulates either a key or a whole object. You can than cheaply instantiate that struct and pass it to the HashSet. I find that to be more complicated than the first idea.
Related
how is a tuple different from a class? instead of the following code, we can make a class with 3 fields and make objects from it. How is this Tuple different from that? Is it only reducing the code we write or does it have something to do with speed as well, given the fact that you can't change the items in a tuple.
Tuple<int, string, bool> tuple = new Tuple<int, string, bool>(1, "cat", true);
It saves you from having to define a new class with custom properties.
It does define equality by the value of the three items, which is something that a bare-bones class would not do without custom coding. That plus the fact that it's immutable makes it a reasonable candidate for a hash key in a Dictionary.
One drawback is that the properties are vanilla Item1, Item2, etc., so they don't provide any context to the values within them, where properties like ID, Name, Age would.
Tuple is a class. One that holds any data you want (in terribly named properties like Item1).
You should be making classes instead so your code is more readable/maintainable. Its primary function is as a "quick fix" when you want to associate pieces of data without making a class to hold them.
Tuples are in my opinion an invitation to bad data modeling. Instead of creating a proper model you get a generic object that can hold n item properties. The naming is very generic too.. Item1..ItemN
You use Tuples as a mean to pass data between method call without having to define a new class. Typically use to return multiple pieces of data from a method rather than use "out" parameters.
Keep in mind that out parameter cannot be use with async/await methods, this is where Tuples come in handy.
You probably want to define a class for your data if you code a reusable class library though. However, tuple is great in presentation layer.
I know how to utilize the ConcurrentDictionary<TKey, TValue> class by using a GetOrAdd() method very nicely. Is there a similar class for a single object instead? I'd rather not create a dictionary for a single object just to get concurrency.
Right now, I'm doing the following:
return _singledict.GetOrAdd(_sync, CreateSingleItem);
It sounds like you want to have some means of accessing an existing object if it has already been constructed, and constructing a new one if it hasn't been, with the appropriate tools in place to prevent the construction of multiple objects.
This is exactly what Lazy<T> exists for.
I'm trying to make a small application that can edit the data files from an earlier project. I have access to that projects "data classes" (pretty dumb classes whose main purpose is to expose it's (public) member variables) that can read/write to the files. All I have to do is make a GUI that can edit the different member variables that each data class have (preferably without modifying the data class) and I'm trying to figure out how to do this so that it will be easy to adapt for future changes/additions.
(I don't feel like I can assume that all member variables should be editable, might only be a selection of them).
All the data can be converted to/from strings (numbers and text) and I don't see much problem in generating textboxes and/or something like a DataGridView in the GUI, but I'm not sure as to how I would like to represent the data needed to generate those.
My first thought was to use a list with all variables for each data class. With each row in the list containing the name+description of the variable (for the GUI), a pointer to the variable in the data-class and perhaps some form of validation-function for different variables.
Store that list in a class that inherits the original data-class (and that implements an interface/abstract-class for any specific GUI-related functions (load/save etc.)).
The thing that makes me worry about this solution is just that I feel like this should be a somewhat common problem and I'm a bit rusty when it comes to OO and this solution smells like something I'd write if I had to do it in C.
There might even be a handy language construct, design pattern or something that is suitable but I don't know what to search for.
Does this approach even seem sensible?
Reflection is your friend in this case. Your data classes have a structure which can be explored using that class's Type. A Type is the base class for metadata concerning a class or structure, and includes methods to, for instance, get a list of all fields, properties and/or methods belonging to that class. The objects representing these class "members" can then be used to set or get field or property values, or invoke methods, given an instance of an object of that type.
A reflective algorithm can be designed to handle any object structure it is given, and it doesn't have to know those structures at compile-time unlike an algorithm based on static types. The downside? It's slow, and you get very little compile-time checking of your algorithm so it can fail at run-time in unexpected ways.
Here's something to get you started:
//statically set up an instance of some arbitrary object
MyClass myObject = new MyClass();
myObject.Field1 = "Hello";
myObject.Field2 = "World";
//This method is available on any object, and produces a Type representing the class definition
Type myType = myObject.GetType();
//C# also has a typeof() keyword that works when you have a static type and not an instance
myType = typeof(MyObject);
//Interrogate the Type instance to get its fields
FieldInfo[] fields = myType.GetFields();
//then, iterate through the fields to perform some (useful?) work.
//Here, we are outputting a list of paired field names and their current values.
//You will probably want to instantiate a Label and Textbox representing this value
//and show them on a Form.
foreach(FieldInfo field in fields)
Console.WriteLine(String.Format("{0}: {1}", field.Name, field.GetValue(myObject));
To handle editability, you will need some sort of record of what the user has permission to change and what they don't. If that information will never change from user to user, you can incorporate that information into the data class itself using attributes (which won't change the "interface" of the object; it'll still have all the same members, but those members will have additional metadata). You could also create another set of classes that implement an interface defining each one as a set of "field permissions" for its parent class, and then you can dynamically construct an instance of the "field permission" class with a Type instance representing your object definition, and knowledge of the name of the interface that field permission objects implement.
How to assign same object list but in different namespace.
list, list2
list = list2;
Cannot implicitly convert type
System.Collections.Generic.List<namespace1.MyData> to System.Collections.Generic.List<namespace2.MyData>
This sounds to me like a WCF proxy that has been generated and you want to reuse the existing class libraries instead of the proxy generated ones.
If this is the case, then see this answer or this answer.
Edit:
as a follow up to this, occassionally you may be in the position where you can't reuse the common class definitions (in the case of Silverlight you have to create a whole new assembly which may not be practical). If you are in this position, there is another option: the proxy generated classes are defined as partial, so you can extend them with a Clone() or Copy() method that returns the identical object from the other namespace, with the values copied over.
If the objects can be cast to each other, you can do this, but it is looping though the lists and making a copy, it's not a direct assignment.
var newList = oldList.Cast<NewType>().ToList();
One example of the general case:
public class Validator
{
// ...
public ReadOnlyCollection<InvalidContainer> ContainersUnderMinimum
{
get { return _containersUnderMinimum.AsReadOnly(); }
}
}
public class InvalidContainer
{
// ...
public int LowestVolume { get; set; }
}
The Validator class above takes a collection of other items in its constructor, then adds invalid items to the internal List. Each container has many sub-containers (think a rack of test tubes), and the class wants to find the lowest volume. The constructor is adding to the list when an item (tube) is not found, and updating the existing list object when an item is found.
The problem is that the Validator wants to return a read-only collection of immutable objects, but the objects (InvalidContainers) must be mutable post-construction so that values can be (essentially) accumulated.
Refactoring to use an interface (IInvalidContainer) causes headaches, as generic collections cannot be cast to collections of a base type.
What are some good patterns or practices to solve this issue?
EDIT: To clarify, the intention is to have the property value (the collection) be immutable. I understand that ReadOnlyCollection only enforces immutability of the collection, not of the collection items. Normally I would make the items immutable, but I can't in this (and similar) cases. However, I only want the items mutated at the time the Validator class is being constructed. Preventing callers from doing unwise casting is not a design goal; the goal is to avoid tempting callers with a settable public property.
EDIT: Changed the title for clarity.
EDIT: Here's the refactored version (based on suggestions from LBushkin and recursive):
public IEnumerable<IInvalidContainer> ContainersUnderMinimum
{
get
{
return _containersUnderMinimum.Cast<IInvalidContainer>();
}
}
If I understand your problem correctly, you want to return a collection of immutable types, but internally retain a mutable collection. The typical way of doing so, is to create a base type (or interface) for your type that is immutable and return that.
You can either cast items to that type (a weak form of immutability control), or you can create wrapper objects and return those (a strong type of control). Wrapper objects can be more expensive to create - but they prevent external code from simply being able to perform a type-cast to get around immutability. This is, by the way, the mechanism that ReadOnlyCollection<T> uses to return immutable collections.
To overcome that fact that collection types have limited casting support, you can use LINQ to return a immutable copy of the immutable type:
_containersUnderMinimum.Cast<IInvalidContainer>().ToList().AsReadOnly()
This creates a copy of the collection - but it may be good enough - if you don't need to the collection to reflect changes at runtime.
Also, be aware that ReadOnlyCollection does not require (or enforce) immutability of the elements of the collection. Rather, it prevents the receiver from being able to add or remove elements - changing existing elements in the collection is still possible.
Actually, it is possible to cast generic collections:
ReadOnlyCollection<IInvalidContainer> result =
_containersUnderMinimum.Cast<IInvalidContainer>().ToList().AsReadOnly();
However, this does not stop the consumer from casting the elements back.
If your mutable objects can only be changed via methods, I would suggest that you include within your mutable type a reference which, if non-null, will identify an instance of an immutable type which encapsulates that same data. Your mutable type should include a method to create an immutable copy; that method should make and cache a new immutable object if it doesn't already hold a reference to one. Otherwise it should return the cached reference. Any mutating method should invalidate the immutable-object reference. Using that approach, one should be able to avoid having to make repeated copies of objects that are never mutated.
Maybe I'm misunderstanding, but a ReadOnlyCollection only implies that the collection is ReadOnly, not the objects themselves...