Develop Reference

C# passing objects to different methods [closed]

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 have a quick question. I have an object that I am trying to pass to a different method in a different class.
public virtual void Geocode(ICustomer customer)
{
RouteObjects.Customer roCustomer = customer as RouteObjects.Customer;
if (customer != null)
{
RouteObjectsRepository.Geocode(roCustomer);
GeoCodeUpdateEventPublisher.UpdateGeoCustomer(roCustomer);
}
}
I am trying to pass the roCustomer object to GeoCodueUpdateEventPublisher in method updategeocustomer. my updateGeoCustomer looks like this
public virtual void UpdateGeoCustomer(object roCustomer)
{
Publish(roCustomer);
}
I wanted to know if this is the proper way to pass this object? I am then going to call method publish and it will look something like this.
protected virtual void Publish(object roCustomer)
{
PublishMessage publishMessage = CreatePublishMessage(roCustomer);
if (publishMessage != null)
{
Subscribers.AsParallel().ForAll(s => s.Send(publishMessage));
}
}
I am just trying to verify if I am passing this object around correctly

There's nothing inherently "wrong" with passing it around as an "object" rather than the type that it is or that ICustomer interface, it really depends on the specific use case and coding style. If you need to access properties on it and you pass it around as object you'd need to cast it and then that'd be an unnecessary and bad way to go about things (i.e., if you pass it as "object" to that Update method and then it goes (MyObjectType)obj.Whatever = "Something"; then you're doing something questionable).

The correct way of doing it is to declare the receiving function using the correct type. UNLESS your function needs to work on a parameter of ANY type.

c# and functional purity [closed]

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
I've been having to use c# lately, which I don't have much experience in. a conundrum I keep finding myself in is, when building a class, having state be dependent on the state initialized before it
class foo{
public bar_ {get;}
public dum_ {get;}
public foo (){
bar_ = BuildBar();
dum_ = BuildDum(bar_);
}
}
its a bit redundant for BuildDum to carry a parameter if it's just going to use something already accessable from a member. on the other hand I like explicitly pointing out dependencies a function relies on
I guess I am asking: what is the best way to handle the situation?

Both ways are fine. The current version of BuildDum could be made static, in which case it's perfectly fine for the method to not access any member variables, because it cannot do it anyway:
private static Dum BuildDum(Bar b) {
...
}
If you make BuildDum that accesses bar_ directly, you should also make it access _dum, i.e. it should be a non-static void:
private void BuildDum() {
...
_dum = ...
}

When to use setter and getter if they are just used in one class [closed]

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
I have a class and use private vars in that class, is there any need then for setter or getter?
I think they are just needed if I want to access the vars from another class right?

You're sort of right.
If you need to expose any of your private fields to other classes, you'll want to generate a property with the appropriate access modifier (public, protected, internal, or protected internal).
If you don't need to expose your private fields, reading from/assigning to a field directly is usually fine.
But even so, having private properties encapsulating private fields might be useful in some cases, such as:
when you need to validate a value before assigning it to the field;
lazy loading a value before reading from it, etc.

How to define a private member behavior, as a method or property? C# [closed]

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
I have a object which is used in another context and I want to validate if a private member is null or empty (which is exposed by its property). It would be better to declare inside the class of the object to encapsulate the behavior instead of doing the validation at every moment where is used, but the question is if better to do it as a property or method?
public bool HasValue()
{
return String.IsNullOrEmpty(this.privateMember) == false;
}
or
public bool HasValue
{
get
{
return String.IsNullOrEmpty(this.privateMember) == false;
}
}
Example of usage:
if(myObject.HasValue()){
}
or
if(myObject.HasValue){
}
What is better? Any impact or it just visual?

Well that certainly feels more like a property to me than a method - and it's certainly in-keeping with things like Nullable<T>.HasValue.
Other differences to consider:
You can generally bind against properties but not methods; not sure you'd want to bind against this anyway
You can't use properties for method group conversions (unfortunately) to create delegates
Properties are automatically evaluated when debugging; methods aren't
There shouldn't be any performance impact.
As an aside, rather than comparing against false, I'd write the implementation as:
return !string.IsNullOrEmpty(privateMember);

It doesn't have many impact for the compiler its just visual but i prefer the second one i'm always doing hate the () :)

System.Nullable<T> uses the property HasValue, so I would use the same approach for consistency with the .NET Framework.

General c# best practices [closed]

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
Just a few questions regarding best practices in c#:
Any reason why I'd prefer to do:
var list = new List<string>();
object[] array = list.ToArray<object>();
comboBox.AddRange(array);
instead of:
var list = new List<string>();
comboBox.AddRange(list.ToArray<object>());
Also any reason why I'd prefer to do:
class myClass
{
private string _hello;
public string Hello
{
get {return _hello;}
set {_hello = value;}
}
}
instead of:
class myClass
{
public string Hello;
}

Your first example just creates an intermediate variable to hold the converted array - if you don't need the array later on then logically they're equivalent.
Your second question is a more significant difference. Properties have many advantages over fields, including potential logic in the get/set accessors, binding to UI controls (most controls can bind to properties but not fields.
In general any public data members should be implemented as properties instead of fields. Non-public data members can be implemented as either.
There are lots of answers on SO that answer your second question.