|
Member 13511312 wrote: I'm actually developing my application in the WPF c# environment. And we are supposed to guess that?
|
|
|
|
|
Sorry for having forgotten to mention this detail.
|
|
|
|
|
Is there any difference between:
DataHelpers dh = new DataHelpers {};
and
DataHelpers dh = new DataHelpers ();
|
|
|
|
|
Not as written; both redundant in this case.
Otherwise, {...} is used to initialize fields / properties; whereas (...) might be used to pass parameters to a constructor.
Other options: ... (...){...}
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Thanks for the reply. If both are redundant, why am I getting a red line in Visual Studio?
|
|
|
|
|
You post "fragments" and expect comprehensive answers ...
I suspect you spent 0 time looking up either topic.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
That kind of comment makes people who are just starting out, not want to ask questions. Maybe if you're feedback is neither helpful nor constructive, you might consider not being so "helpful."
|
|
|
|
|
Hi Rick, your profile here on CP suggests you are not "just starting out."
Nothing "wrong" with that, but I do wonder if you are taking the time to do some basic research before posting. CodeProject is "bursting at the seams" with relevant content on almost any topic ... ditto StackOverflow.
cheers, Bill
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
|
|
|
|
|
Thanks Bill. I'm sure Gerry appreciates your coming to his rescue, but the answer you gave below is exactly the opposite of the answer that that Gary gave. I only mention this because you both have taken so much time out of your day to criticize my question. Should I check with you two before posting next time?
modified 27-Dec-17 0:31am.
|
|
|
|
|
Rick_Bishop wrote: I'm sure Gerry appreciates your coming to his rescue My message was only for you ... I gave up "rescues" when I stopped being a social worker at age 42 (32 years ago) cheers, Bill
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
|
|
|
|
|
I'm a Paramedic/Firefighter for a total of 14 years for emergency services all over the U.S. Hats off to you for being a social worker! What a thankless and difficult job at times. I'll bet you've enjoyed a better quality of life since changing occupations. I know I have. Thanks for help!
|
|
|
|
|
I tell eveyone the same thing when I make an effort, and they don't.
Don't feel that I singled you out; but I will make an effort to avoid you in the future.
Cheers.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
It was admittedly a poorly worded question. Next time I'll try to convey the effort put forth to obtain an answer. But please don't answer any question that seems stupid. It's hard enough for me to decipher what's outdated information on the Internet, let alone trying to guess what you'll think is a stupid question.
|
|
|
|
|
There are no "stupid" questions.
I provide opportunities for a "dialog".
It's up to you what happens next in how you choose to "participate".
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
If you have used the version with {}, Visual Studio will be complaining that you have supplied an object initialiser, but haven't actually tried to initialise any properties inside it. In other words, the {} is redundant.
This space for rent
|
|
|
|
|
Yes, there is a significant difference.
Look at what Object () and Collection {} initializers are, and what they do: [^].
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
|
|
|
|
|
I was not aware that one is called an Object Initializer and the other is called a Collection initializer. Thank you for pointing that out. I will research that.
What prompted me to ask this question is that my code worked either way.
|
|
|
|
|
Just to add some clarification, since there seems to be so much consternation.
One of those is an explicit constructor call, MyClass(). The second is an initializer, which allows you to populate values as you see fit regardless of their "safety". It also requires a default constructor for the class, otherwise you're stuck calling the constructor then the initializer. This all means that if a constructor is defined with arguments, you can initialize in a safe way as defined by whoever created that class. For instance:
public class MyClass
{
public string Greeting { get; set; }
public bool IsGoodDayGreeting { get; set; }
public MyClass(){}
public MyClass(string greeting)
{
Greeting = greeting;
IsGoodDayGreeting = greeting.Equals("Good Morning") || greeting.Equals("Good Day");
}
}
Now that we've got the class, we have 3 ways to initialize it:
var greeting = new MyClass("Good Day");
var greeting3 = new MyClass { Greeting = "Good Morning" };
var greeting4 = new MyClass("Hello") { IsGoodDayGreeting = true };
As long as you bear the possible deviations in mind when breaking away from the constructor this is all fine and dandy, and a good dev will make sure that Object Initialization will not break an object's functionality, but if you rely on that without checking you are ultimately doomed to disappointment.
The last piece is constructor initialization. This only applies to items that implement IEnumerable, so it will work with Arrays, Lists, Dictionaries, etc.
var greetings = new List<MyClass>
{
new MyClass("Hello"),
new MyClass("Good Morning"),
greeting2,
greeting4
};
As expected, that results in a list populated with 2 new instances of MyClas and, assuming it's in scope with the above code, the previously defined greeting2 and greeting4.
Anyway, I hope this is what you needed.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Great answer! My class has no getters or setters and no constructor but I had forgotten that the compiler creates an empty constructor.
I was not aware also that obj() was called an object initializer and collection{} was called a collection initializer, so I was not finding answers online.
So now I understand why I can initialize the class with parenthesis - because of the empty constructor that's created by the compiler. I'm still kinda wondering why curly brackets worked too, though. This is just a collection of methods I'm using throughout my application.
|
|
|
|
|
That's not quite right.
var obj = new Thing();
var obj2 = new Thing { Name = "Thing" };
var obj3 = new Thing() { Name = "Thing" };
var objs = new List<Thing> { obj, obj2, obj3 };
All are valid C#. I personally favor constructors when I'm working with a class that I didn't write which takes parameters, less room for whoops.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
I have an API that I am trying to use that uses XML for it's requests. Each of these objects have multiple different requests (Add, Modify, and Delete), along with different versions that may exclude some fields. Is there a way to utilize serialization with different schema to account for these differences? For example, using the following Customer object:
public class Customer
{
public int ID;
public string EditSequence;
public string Name;
public bool IsActive;
public int? ParentID;
} On a Delete request, I have to only supply the ID and the EditSequence fields. If I include the other fields, I get an error. For an Add I need to include all of them. Also, for null fields, they can not be included at all (i.e. no <parent> element). I don't think this is possible with regular XML serialization and I'll probably have to code this myself. If so, I was thinking of using custom attributes and reflection. Is there perhaps a better way to accomplish what I am trying?
|
|
|
|
|
Please clarify what you are doing: are you making calls to an API passing run-time field values, or, are you calling an API passing some pointer to a serialized xml file, or, to an in-memory xml stream ?
How does serialization come into play here ?
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
|
|
|
|
|
The API that I am using takes an XML string. The XML string is based on what request I am trying to do. So, if I have an instance of a customer in my application that does not yet exist in the API software, I create an AddRq XML string, which has all of the fields for the customer:
<CustomerAddRq>
<CustomerAdd>
<Name>John Smith</Name>
<IsActive>1</IsActive>
...
</CustomerAdd>
<CustomerAddRq> Once I process this Add request, I get the ID associated with it, which I save in my custom object. If I then decide I want to update the customer record, I need to pass an slightly different XML string:
<CustomerModRq>
<CustomerMod>
<ID>456</ID>
<Name>John H. Smith</Name>
<IsActive>1</IsActive>
...
</CustomerMod>
</CustomerModRq> In my application, I still have just the one instance of this customer. Also, if I am wanting to delete this customer from the API software, I would pass this request:
<CustomerDelRq>
<CustomerDel>
<ID>456</ID>
</CustomerDel>
</CustomerDelRq> In each of these cases I have to be specific about which fields get included in the request or it will be rejected. If I were to include any other fields besides the ID in the delete request, the entire request is rejected and ignored. There's also some other factors based on the version of the API that might be in use. For example, they added a feature for tracking Currency in version 12, but if my customer is still using version 11, I need to never include the Currency field in my Add or Mod request or the entire request is rejected.
|
|
|
|
|
One way to do this would be to separate out your creation of the serialization from the Customer class, so you would have a DeleteCustomer class, for instance, that would accept an instance of your customer and which would return the appropriate XML. This helps to separate the concerns of your code.
This space for rent
|
|
|
|
|
Serialization has nothing to do with functionality. It is solely about data. So it doesn't matter how you modify/update/create that data.
hpjchobbes wrote: On a Delete request, I have to only supply the ID and the EditSequence fields
What you are referring to is generally about a 'difference'.
And it has nothing to do with the object itself.
The object represents a set of data and functionality associated with the data.
You are attempting to push functionality that involves a specific API and delivery of that data into the object itself. Bad idea.
What needs to happen is that the API layer (your code) needs to understand what it needs to deliver and then provide a way to do that. And not one that relies on the object to do it.
To provide a difference you MUST have two instances of the object. A before and an after. Then the API layer provides a way to either generally or specifically define the difference.
Be very careful in your design decision because a general approach ties one to the idea that ALL objects will be delivered using a difference. If there is even one exception then one must break the architecture to deal with it. Which is not the same an understanding that many objects, but not all, need to be handled with a difference.
One part of handling a difference also requires that one must be able to define the 'id'. That might not solely be one attribute. A general solution would require a way to recognize the specific attribute(s) that are the 'id'. That would either require metadata or hard coded by each object. One way, there ARE other ways, to provide the id is to require an interface on the the object that returns, as a string (generic solution) the id value.
|
|
|
|