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
When writing a method that takes a string and populates a poco based on it, is it better to have a static Parse(string s) method like Int32.Parse() or overload the constructor so it takes a string?
I prefer the constructor version, but including both is easy, since the constructor can just call Parse. This is the pattern followed by the Guid struct (and likely others as well.)
I should add that if you're not dealing with a struct, then the static method should probably be referring to the constructor (or even a separate method that both can call) since you can't assign to this in a class constructor.
EDIT: As TrueWill points out, if you do include Parse, you should include TryParse as well. Incidentally, Guid is once again instructive: the Parse method actually uses TryParse, and just throws an exception if TryParse returns false.
If the method might fail due to an invalid string, I'd lean towards Parse and include TryParse as per the TryParse pattern.
I would recommend using .Parse(string s) if its a simple object, if the object stores more then 1-2 values you should use the constructor, or in other words, dont parse if the return value will be an instance with memebers unaffected by the parse value.
Related
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 1 year ago.
Improve this question
Is it possible to make a couple of overrides for ToString() method in class instead of one?
I have a project, that would use ToString() method, depends on the result set of searching.
Is it possible to make a couple of overrides for ToString() method in class instead of one?
It depends
You either mean "overloads" in which case, sure - make as many variations of a method as you want but they have to have different signatures (some unique combination of number of/type of/order of types of arguments)
Or you really do mean "overrides" in which case you can only do it if there is a suitable method in a base class to override. If your class descends from object then no; object has only one overridable ToString. You could overload other variations of ToString but they wouldn't be overrides
No. Overloads have to differ in signature, and in this case there's nothing to vary because the function doesn't have any arguments.
If you had more than one identical toString function, how would the compiler know which one you intended to call?
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
Can a single dictionary object be used in place to replace method parameters (similar to args in Main method) is this a good idea or if bad? what would be a better approach than this?
private async Task<OperationResult> AddOrUpdateRecord(Dictionary<string, object> args)
{
args.TryGetValue("record", out object record);
...
... etc
var recordExists = new RecordExists(record as RecordDto, _dnsCommonActionsRepo);
}
is this a good idea or if bad
This is in the vast majority of cases a very bad idea. The caller will have no idea what parameters are needed. You cannot pass any typed object, so you lose all type safety. You will have no compiler checks to catch potential errors. You are also likely to reduce performance if that is a concern.
what would be a better approach than this?
In most cases, regular parameters. In some cases, where you have way to many parameters, and is unable to refactor the method, a parameter object that gathers many different parameters might be motivated. The only use case I can think of for something like this is when you are getting untyped parameters from some source, for example, key-value pairs from a database or file.
If the problem is breaking builds due to signature changed, that is intentional. The compiler saves you from shooting yourself in the foot. Good refactoring tools, like R# allows modification of signatures, but if you add a parameter, chances are you need to fix call sites by hand.
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 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 4 years ago.
Improve this question
I wonder why can't we just convert IEnumerable to string using ToString() ! I mean what is the underlying reason behind this.
Microsoft docs say " ToString() returns A string that represents the current object." What is this A string ? Is it a special property of the object ? Why int.ToString() works but IEnumerable.ToString() doesn't ?
An IEnumerable<char> is not neccessarily a string. Imagine you have some service that returns an infinite number of characters (e.g. a stream). As there´s no end of that stream and data flows endlessly you are not able to call ToString and materialize a string from it.
However ToString just returns a representation of the object, not its data. In case of an array for instance, the object is the collection of items, or more general just a container. What you expect is the data that is contained in that container.
So when calling myArray.Totring for example you don´t get { 1, 2, 3 }, but simply System.int[]. That´s what ToString returns if there is no override for the type: its type-name. The same happens in your case: there is no overrdie for ToString defined for char[] or List<char> or whatever, so the method falls back to use typeofObject.FullName.
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
Given web service method:
public void FindSomeEntities(int? Id, string param1, int? param2, ...)
Refactored:
public void FindSomeEntities(SelectionParameters selectionParameters)
class SelectionParameters
{
public int? Id;
public string param1;
public int? param2
...
}
Pros:
too many parameters in original web service method reduced to the
only one
if there is need to change we won't have to change the
interface of the method - only the definition of SelectionParameters
Cons:
class SelectionParameters hasn't any business value - it's used only
as helper class and it's used in a single method. As a result we'll
have many methods with 1 parameters and plenty of one-off classes
Actually the interface IS changed, we just push these changes a bit
deeper.
This refactoring is called Introduce Parameter Object. It is likely to be a good idea if the parameters are naturally related to each other, and especially if they're frequently used together as parameter lists to multiple methods.
I'm not sure there is much value in this kind of refactoring because as you say, the number of supporting classes will/could be a pain to maintain and serve no other purpose.
If the parameters have distinct purposes, such as in your example 'ID' then I would think it would be sensible to keep them separate so as to make it easy to identify them and what you want to do with them in the method body.
If however your params are just a collection of values which perform similar/the same functions in the method body, you could look at using the params keyword and defining your method like this:
public void FindSomeEnteties(params object[] theParameters)
It depends whether you want to have to dig through an array to pull out index 0 and treat it as the ID, etc etc, or whether your method simply wants to do the same thing to all the parameters passed.
If there is any reason to believe that the same (sub)set of parameters is shared by other web services, this is reasonable.
Whether you do it not, you have a defacto struct as the argument list anyway. This observation is realized in our PARLANSE programming language, which has always a single argument to function, named '?' (sort of like "self" in OO ). That argument has a type; it can be a scalar or complex variable (int or string), or it can be struct. Normally one defines a struct by a struct declaration; in PARLANSE, writing what appears to be multiple arguments implicitly defines a struct. In those cases where the argument list is passed to a child function, one can simply call that child function on '?' and the entire argument list is passed.