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 1 year ago.
Improve this question
Suppose that we have two classes, A and B, and two events OnPress and OnPressed. When I invoke OnPress both classes are a must-have, so I have an EventArgs that have a ref to both classes, but in OnPressed context only makes sense to have the ref to the class B.
My doubt is, is better to have separated event args as:
public class PressEventArgs : EventArgs
{
public A a;
public B b;
}
public class PressedEventArgs : EventArgs
{
public B b;
}
And pass the right context to each event OR pass the PressEventArgs to both events only leaving the A class ref null?
If different events have different arguments, then you should have different classes representing them.
Using the same class makes no sense. It violates several principles of software development.
If you had to pass a single number, you would never contemplate if passing a 2d coordinate and leaving the y-value zero would be a good fit. It isn't. You pass what you need to pass, not more, not less.
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 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 3 years ago.
Improve this question
I want to change a function behavior depending how we call the function.
Example:
class A {
public B instance;
public void HWorld(){
Console.WriteLine("Hello from A! \n");
}
}
class B { // No modification allowed.
public void HWorld(){
Console.WriteLine("Hello from B! \n");
}
}
static void Main()
{
B b= new B();
A a= new A();
a.instance = b;
b.HWorld(); // PRINT Hello from B!
a.instance.HWorld(); //PRINT Hello from A!
}
So my question is: Is there a way (with Event Handler maybe?) to redirect the call B Hworld() to A Hworld() when called as an instance of a specific class?
Other information: I know *it's an XY probleme *: there is a better way to design what I want to do. But I still want to know if it's possible, and how to do it (I don't mind if it require destroying c# compiler).
This is a minimal example: As it doesn't represent the reality, and it's more a theorical question, please avoid: "You can call a.HWorld()".
EDIT
(after on hold)
The question I asked was clear. It was an XY probleme, but I was asking for this X question and the topic was closed for Y being unclear (of course, it was not my question). I don't want to debate anymore if there is other way to go around. I'll do an other post for question Y.
If the method is also marked virtual, you can make a new class that inherits from B, overrides the method, and get the behavior you want.
If it's not marked virtual, you will not be able to do this.
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 class with only static methods. Should the class itself be made static too? Does it matter?
Does it matter?
Making a class static ensures that it can never be instantiated by generating a compiler error should the user attempt to do so. If the class, consisting of only static members, is simply not intended to be instantiated, there is no reason not to make it static. You can choose not to do so, but instances of such a class aren't going to be very useful, and users creating these instances are going to be left quite confused.
On the other hand, if you intend for instances of this class to be created but you expect derived classes to implement their own instance members, chances are that this class should be abstract, rather than static (and perhaps those instance members should be stated upfront via abstract definitions or an interface).
In general: Yes.
You can prevent the programmer to create object instances of a certain class by making the class static. If this is what you intend, then do it. This prevents mistakes, by showing (other collegues, etc.) that the class is not intended to be instantiated.
public static class A
{
// Some static member
}
A a = new A(); // Compilation error
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 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.