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.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I was looking at the TextReader class, but I only see method prototypes, I can't see the definitions anywhere. I'm interested in how things work under the hood and I tried looking for the definition of public void Dispose(); but trying to peek or go to definition in VS2019 just returns me here. Where are they stored?
How is it possible to prototype like this? I tried doing it and it wouldn't allow me. This particular method is not virtual.
I'm guessing by "method prototypes" you mean the headers of the methods, i.e. these things:
public virtual Task<String> ReadLineAsync()
The body of the method (or in your words, "definition") is not shown in Visual Studio. One place you can find them, is https://referencesource.microsoft.com/. For example, here is the source for TextReader.
Note that TextReader is an abstract class. Some of the methods in an abstract class can have no bodies by design (though this is not the case with TextReader). For an interface, all methods have no bodies*. If you want to see the implementations of those abstract methods, you need to go to a concrete implementation. For TextReader, this could be StreamReader.
You can create these so called "prototypes" by creating an interface (though it's not the same kind of thing as the one you see in TextReader):
interface IFoo {
int Method1(string param);
string Method2(string p1, string p2);
...
}
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 want to pass a parameter into a method only for the purposes of logging. The parameter is a type of an event that I'm about to process. I can see two approaches to this, and I'm wondering if either of them is more correct?
private void LogEventProcessing<T>()
{
_logger.Information($"Started processing of {typeof(T).Name} event");
}
private void LogEventProcessing(Type type)
{
_logger.Information($"Started processing of {type.Name} event");
}
Using Type parameters is cleaner, there's close Flags being placed on this question that I don't agree with, the reason being that the first is the better choice in the scenario described.
You can use Type Constraints to constrain the Type of the parameter being inserted by the client.
private void LogEventProcessing<T>() where T : Event
{
_logger.Information($"Started processing of {typeof(T).Name} event");
}
The above method will now only accept classes that inherit from the type Event, it's cleaner, and makes the expectation clear to the client what you're expecting here.
I don't like either of these options. As a client you either have to use reflection to call the generic version or you have to call GetType() on the event before passing it to a logging function. That just seems like your client is too closely coupled with what the logging function is doing. What happens if it wants to log more information about the event? Do you create a new method and pass just that information? Or do you go back to every reference to this method and add a new parameter?
Yuck, either way, yuck. My advice: Don't do either. Pass the event and then get whatever you need from it in the method itself.
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 = ...
}
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 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.