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
Short and sweet (hopefully), is there a specific reason not to use the this keyword when writing getters and setters in C#? I know the typical format, and the one I've always used, is:
public void SetDay(int _day) { day = _day; }
public int GetDay()
{
return day;
}
Recently though, I've been learning Java, and in several of the books I've been using I've seen it written instead like this:
public void SetDay(int _day) { this.day = _day; }
public int GetDay()
{
return this.day;
}
So basically, is there a reason to avoid doing it the same way in C#? Will it cause any problems or errors, or is it a valid approach and really just a matter of personal preference. I'm wondering because, while I know the this in C# is understood, explicitly using the this keyword seems like it would aid in eliminating a bit extra ambiguity, which personally is always a good thing.
Thank you!
There's not much to it really.
You can do it, and you can avoid it. I think it's quite obvious when you're in the getter/setter that you're talking about the object you're in, so I've never used it there.
Also, it seems like Resharper will suggest it's redundant, and gray it out.
If you find it to be of use for you (readability wise), by all means, use it. Otherwise, it'll save you five keystrokes (about a second?) every time you implement a getter by hand ... :)
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 3 years ago.
Improve this question
Intro
I am trying to build a system that will give information to the front-end which elements should and shouldn’t be shown.
But the problem i am running into is that i have to deal with massive amount of conditions, these could vary from rights to which modules are available and even which data is available.
So i was expecting that someone else would also have run in to this problem, but i couldn’t find anything.
What i have tried
I first start searching for design patterns that could possibly deal with this problem but i couldn’t find any that did. Then i went to source making and read all the descriptions of possible patterns but to me none of them seemed to be the solution to my problem.
Afterwards i just searched around if someone had encounter a similar problem and once again i did not seem to find any close comparisons to my problem.
So are their any suggestion how i could improve searching
Or did i overlook something?
I would suggest that you take a look to something like the Rules design pattern
Effectively, this would be a large set of predicates.
Steps needed to accomplise this:
1. Change boolean logic to predicates and extentions
2. Create interfaces that provide the proper logic and transformations
With the Rules Pattern there is an Evaluator class that loops through a collection of rules and executes them. It evaluates the result and decides what action to take. In the simplest case it just executes all the rules, but it is also possible to add some selection logic to each rule that allows the Evaluator class to decide whether or not to run the rule (such as the IsMatch() method on the IRule interface above).
You can put your if statements into method which return bool value. For example:
public void GetMeal(Behavior behavior)
{
if (isAnimal(behavior))
GetMilk();
else
ChangeBattery();
}
private bool isAnimal(Behavior behavior)
{
if (behavior.HasVoice
&& behavior.HasVoice
&& !behavior.HasBattery )
return true;
return false;
}
public class Behavior
{
public bool HasVoice { get; set; }
public bool HasName { get; set; }
public bool HasBattery { get; set; }
}
I would suggest replacing those statements with commands. Here is a link with more info. The code is not in C# tho but I think you can understand the main idea from it.
https://scrutinizer-ci.com/docs/refactorings/replace-conditional-dispatcher-with-command
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
Does anyone know how to convert the C# getter and setter to a java-like getter and setter pattern using the Rider IDE?
Convert this:
public Transform List
{
get { return list; }
set { list = value; }
}
to this
public Transform GetList() { return this.list; }
public SomeClass SetList(Transform list) { this.list = list; return SomeClass; }
This would be usedful for chaining setters in a fluent builder pattern.
A distinct non answer: stop wasting "double" your time!
C# isn't Java. Fighting a tool to fight the native idiomatic constructs of your target language, that is likely double pointless.
Source code is written to be read by humans. And good source code never surprises its readers. An experienced c# programmer will look at your Java like getters and setters and can only wonder: "why is he polluting these classes with those strange methods, instead of using c# property support".
Beyond that, you might want to read https://en.m.wikipedia.org/wiki/Uniform_access_principle to understand why the c# properties are actually a better approach than Java fields with getter/setter pairs!
Or as they said 2 thousand years ago: when you come to Rome, do like the Romans do! If you don't want to do like the Romans do, stay away from Rome, or c# in your specific case.
OP is probably coming from the java world. In the Menu(Intellij) Java IDE ->Code->Generate
In the generate menu, "Getter and Setter" is the 4th Option.
In the C# world(Rider), properties are used to expose selected fields.
Jetbrains Recommends generating Properties rather than the Java getter-setter way.
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 have just learned get set principles in C# and I wonder whether there is any interest of using the same principle for methods.
If I understand well, get and set are used for variables. But it could be possible to apply the same principle for methods. For instance:
private int _GiveMultiply()
{
int a = ...
int b = ...
return c = a*b;
}
public int GiveMultiply
{
get { return _GiveMultiply(); }
}
But is there any kind of interest to do such a thing ?
For example is there a risk to use a public function that can be prevented using such a process ?
The answer is: it depends. I'll try to help you to reformulate your question: does it make any sense to return a function rather than computed result from another fuction? Then I would say: definitely yes (let me know if you'd like to know ehy, I'll update this post). But the example you showed does not return a fuction, it just wraps it into yet another fuction, which is useless. The only exception is various kinds of abstract method patterns, where you might have public function with some predefined logic and call to the abstract/virtual fuctions; rarely they do have same name, then indeed wrapping sort of works.
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
This is basically a a design question:
I am rewriting an application in C# which is basically written in C++. C++ has this nice concept of Header files which will gold a lot of declared constant values for the consuming file.
However, we do not have Header files in C#. I may have two options
Create a class which will hold a lot of constant values for me(No so standard)
Store values in XML (Standard-But involves a lot of parsing hassle)
Which is a better solution? Is there any other solution that I may not know of?
Personally i'd use a static class and place all the values in there.
public static class Constants
{
public const int Ten = 10;
public const int Twenty = 20;
....
}
EDIT
As #JonSkeet suggested, it's better if you store these values in classes they pertain to, however, that might not always be possible.
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 4 years ago.
Improve this question
I have a class with two related functions (methods):
public class class1
{
public void SubscribeToListOfEvents()
{
// ....
}
public void UnSubscribeFromListOfEvents()
{
// ....
}
}
What's the best practice to use related functions in one class ?
Do you know of any implementations of related functions as one function ? Are they good ? In what situations are they good ? If so, can hyou give me an example?
Any available options of code above will be appreciated.
If the functions belong to the class, logically, then they are fine that way.
A class should be cohesive and methods that do an operation normally should have the mirror operation defined as well (Subscribe/Unsubscribe, Add/Remove etc...).
You have named them well, as they are very descriptive of what they do - how would you name a merged one? It is better to leave them separate, as this way they are self documenting and will not confuse users of the class.
With the example you provided, they are related - but only because they may work with the same set of data or objects.
Personally i would NEVER merge these into a single function. While it may be more typing, it is easier both to read and to maintain to keep them separate. When either of those two functions are being called it is obvious what is going to happen - if you were to merge them then it becomes not so obvious. This is a simple example though - if you were to merge two functions that were more complicated then things could get very murky, and you could end up having unintended side effects from calling the merged function.
Remember KISS - Keep It Simple, Stupid :) For every function, try and follow SRP - Single Responsibility Principle. While Wikipedia talks about SRP at the class/object level, there is no reason to not also apply it at the function level where practicable.
dont merge them, make an interface that will force you implement both methods
interface ISubscriber
{
void Subscribe();
void Unsubscribe();
}