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 7 years ago.
Improve this question
I am confused on how to create class can you please help me??
class AutomotiveManager
{
private bool isBeingTested
{
set
{
isBeingTested= false;
}
}
private dialogResult MessageBoxResult
{
///need help over here
}
}
It seems that there are a few different issues here.
The difference between properties and attributes
The meaning of the = in the attributes
The error (which error?) you get for the declaration of the messageBoxResult
Private Attributes are just private Attributes.
So the implementation of a private attribute like the isBeingTested would be
private bool isBeingTested;
The = in the attributes means the default value. So that would be the value you assign in the constructor or at the declaration of the attribute. For the isBeingTested you could add that to the declaration like this:
private bool isBeingTested = false;
But since in C# the default value for a boolean is false anyway you don't even need to specify it. The way you programmed it you will en up in an infinite loop the moment you try to use the setter for isBeingTested
The «Property» presumably indicates that you are meant to create a Property rather then an Attribute, and I guess the {get;} indicates that you only need to implement a getter, not a setter for this property. (I'm guessing here since none of that is defined in UML)
The error you are getting is probably because the compiler doesn't know the type dialogResult. It may know the type DialogResult (notice the uppercase) if you add System.Windows.Forms as a reference to your project, and add a using statement like this
using System.Windows.Forms;
PS. You also failed to implement the static keyword on the class.
To convert your UML class diagram into a C# class, you'll need to understand what each of the symbols represent in your UML class diagram. This image from tutorialspoint.com is useful:
From there, it's a matter of writing the equivalent C# code based on the symbols provided in your example.
Related
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
If a class (or a structure) has a field and we replace it with an auto property of the same type, will client code always stay the same, taking into account that we don't use reflection or any other type of direct or indirect meta-programming? For example
int Integer;
public void Test() {
Console.WriteLine(Integer);
}
If I change int Integer to int Integer { get; set; }, the code that uses it stays unchanged. Is there any case when I need to change calling code?
The same question about readonly fields and get-only properties.
EDIT: I clarified my question. Also, taking into account existing answers, instead of auto property, question will be about ref property:
Is it possible to replace this
int Integer;
with
int _integer;
ref int Integer => ref _integer
Without any changes of calling code?
I want to find a case when I need to change client source code if I
replace a field with a property or opposite. I want to know how safe
this replacement is
Fields (C# Programming Guide)
Generally, you should use fields only for variables that have private
or protected accessibility. Data that your class exposes to client
code should be provided through methods, properties and indexers. By
using these constructs for indirect access to internal fields, you can
guard against invalid input values. A private field that stores the
data exposed by a public property is called a backing store or backing
field.
So there you have the official word on field and property usage
I mean, if we replace a field with auto property or opposite, do we
need to change client code in some cases
Yes, you are likely to break things in the following cases,
If you are exposing fields that are being passed by ref
If this class is being inherited and in cases where fields or properties are getting re-implemented or overridden
A derived classes implement Interfaces that require properties etc.
Also there could be cases where they are used in Expressions and it expects field or a property (I think).
In short, if large code bases relied on fields/properties and you change them this is likely to cause breakable changes for any of the above.
Though in summary, if you lived by the Microsoft recommendations above, you should have less of a problem, and if you do it points to the fact this should probably be refactored as a new version anyway (with breakable changes, and more expected usage).
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 4 years ago.
Improve this question
I am developing an ASP/c# webform where I am using JQuery as well. I came into a scenario where I need to call. C# function from JQuery. In order to that, I found that function in c# has to be a static method (web method).
The problem is that I need to access all variables, arrays, etc which I used to populat some data and these are not stated c variables. Also, from the web method I need to re-use some the functions which are not static. I ended up gradually just changing all methods and variables to static.
I would like to know if the approach I am taking is correct, and whether there is any pitfall of using static variables/methods and what in simple words makes a difference between static/none-static.
Static variables can be called directly by using class names such as
public class IhaveStatic
{
public static string Hello = "Hello I am A";
}
When you use static this means this will be in memory for life time of your process.
now consider another class as
public class IhaveNoStatic
{
public string Hello = "Hello I am B"
}
public class C
{
Console.WriteLine(IhaveStatic.Hello); // Correct
IhaveNoStatic obj = new IhaveNoStatic();
Console.WriteLine(obj); // Correct
Console.WriteLine(IhaveNoStatic.Hello); // Compile time error
}
as you can see that you need to create object of that class "IhaveNoStatic" to access non-static variable. So, this will be in memory until there is an instance of that class exist.
So, basically it's on your requirement but it is good to use less static variable in your programs.
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 5 years ago.
Improve this question
It seemed like this was possible, but I can't find a reference on how to accomplish it, though I've seen a few things that are closely related. I have a particular type of class that requires a public or private default ctor. The reason is stylistic; it is a domain aggregate and the only case where a default ctor should be used is during event store replay. There are obvious ways to work around this, but I'm trying to lock this particular type down. At any rate, what I'm hoping to do is create an attribute that can be applied at the class level that would enforce the existence of a default ctor. If one isn't found, it won't compile... or at the very least, give it the big nasty blue underline like [Obsolete()] does. I figured this was potentially doable with Roslyn. Any direction would help. The solution would ideally travel with the project rather than being something that needs to be installed on visual studio.
Just a simple idea, for a public default constructor you could make use of the where T : new() constraint - even though attributes cannot be generic you can supply typeof(HasDefaultConstructor<MyClass>) as an argument to an attribute:
public static class HasDefaultConstructor<T> where T : new() { }
public class CheckAttribute : Attribute
{
public CheckAttribute(Type type) { }
}
[Check(typeof(HasDefaultConstructor<MyClass>))]
public class MyClass
{
public MyClass() { }
}
But it feels a bit hacky having to supply the type you're applying the attribute to, and doesn't work for the non-public constructors, but it does fail at compile-time without needing any addons.
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 9 years ago.
Improve this question
I have a problem with a example of my book. From what i have read non static methods cant be used without instance a object of the class. So is this ok ?
public partial class TempAgencyForm : Form
{
public TempAgencyForm()
{
InitializeComponent();
}
private void btnCalculate_Click(object sender, EventArgs e)
{
...
setVisibility(false);
}
private void setVisibility(bool visibilityValue)
{
...
}
}
Yes, it is fine. One non-static method can call another non-static method.
The call:
setVisibility(false);
can also be written:
this.setVisibility(false);
but the this qualifier is redundant.
However, if you had tried to call a non-static method without instance qualification from inside a static member, that would have been a problem (compile-time error).
I assume you are talking about calling setVisibility(false);. Yes it is fine, neither it or the method calling it are static.
This will all happen within an instance of TempAgencyForm
Yes this is okay, because it's called from within another member.
You're correct, since setVisibility() is not static, it always has to be called in the context of some object of the parent class (TempAgencyForm in this example).
However, btnCalculate_Click() is another member of TempAgencyForm, as such you're able to access the current/local object using the this keyword (this.setVisibility()), which is optional if there's no disambiguity.
static or non static doesnt matter here, you are calling a member function declared within the same object. so short answer is "fine"
how you call TempAgencyForm members may be what you are referring to
in this case (as you have defined) instantiations is required
TempAgencyForm taf = new TempAgencyForm()
taf.setVisibility(false);
however if you have your class definition itself as static, i.e.
public static partial class TempAgencyForm
then,
TempAgencyForm.setVisibility(false);
is suffice (without instantiating the object) as the object is already loaded on stack at the time of application start
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.