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 = ...
}
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 2 years ago.
Improve this question
I have read something's, about static classes, mostly about that static classes are "evil" in Java, and I was wondering what does the Static calss actually do?
What are the applications to it Unity C#, and C# in general?
"The static modifier makes an item non-instantiable, it means the static item cannot be instantiated. If the static modifier is applied to a class then that class cannot be instantiated using the new keyword. If the static modifier is applied to a variable, method or property of class then they can be accessed without creating an object of the class, just use className.propertyName, className.methodName."
Static class basically means that there is just one instance of the object.
It can be good or bad, depends on what you need, for example if you have an int to store the player money you can use static int money and then get or set the variable
from anywhere, but if you want to create something multiple time (like enemies etc') you cann't use it.
Here is a link to read more about the Static class
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.
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
I want to create private list, while making it public as readonly\unwriteable, unable to add\remove\insert cells\nodes to the list.
My current solution is:
public IEnumerable<DataToken> DataTokens {
get {
return from v in _datatokens select v;
}
}
private List<DataToken> _datatokens;
I know the property's name is fine, but what about the variable's name? I can't name it dataTokens because it's parameter's name's format. Currently I call it _datatokens that is really bad name.
Is there a better alternative? I couldn't find anything about it at msdn.
Since identifiers are case-sensitive in C#, there is nothing against datatokens as a variable name.
There is a guideline available on MSDN that would suggests it to be dataTokens (camel-cased).
By the way, you should use ReadOnlyCollection<T> as return type to make it read-only to the outside world, so I would suggest to split this one up in two properties with different access modifiers.
C# also supports auto-properties, so you can save yourself the trouble of solving this conundrum and simply declare your property thus;
public IEnumerable<DataToken> DataTokens { get; private set; }
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.
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.