Develop Reference

Is there a good practice of setting default values in an constructor? [closed]

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
Consider a simple class
public class MyClass
{
private int myProperty
...
public int MyProperty
{
get
{
return myProperty;
}
set
{
// some evaluation/condition
myProperty= value;
}
}
...
}
Now, if I want to create an empty constructor where I set default values for the class properties I could do this either this way:
public MyClass()
{
myProperty = 1;
...
}
or this way:
public MyClass()
{
MyProperty = 1;
...
}
Both examples seem valid, since I would never set a default value, that doesn't meet the requirements in the setter evaluation.
The question is, is there a best practice or doesn't it matter anyway?
What would be the advantage of one or the other be (as I can't find any)? Is there some reference, where this question is adressed?
So far I have come across code from many different developers that use either or both ways...

You can use both. But i prefer the first one. Why? Because the value that the property uses is directly assigned. For C# 6 above, you can use default value in a property directly without using constructor.
public class Person
{
public string FirstName { get; set; } = "<first_name>";
public string LastName { get; set; } = "<last_name">;
}

I personally like to set it as you done in first block.
For me it serve as additional fact of method is constructing object, not using alredy constructed. Also it makes me sure that properties is not called (they transform to set/get functions which results in couple of excess instruction).
But i believe that both variants are valid and maybe compiler optimizes properties to direct assignment.

For simple data first method is ok. But on more complex data, you could have a condition in the set (depending to another variable for example, set { if (Config.TestEnv) ...} so if you directly set the private value, you could be in trouble.

Is Enum Right For This? [closed]

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 5 years ago.
Improve this question
I'm working on a Model and am using enum for a list of named items.
class Verse
{
public int Number { get; set; }
public string Text { get; set; }
}
class Chapter
{
public int Number { get; set; }
public List<Verse> Verses { get; set; }
}
class Book
{
public string Name { get; set; }
public List<Chapter> Chapters { get; set; }
}
class Bible
{
public Versions Version { get; set; }
public List<Book> Books { get; set; }
}
enum Versions
{
asv1901,
bbe,
darby,
kjv,
nasb,
niv,
nkjv,
nlt,
rsv,
web,
ylt
}
That seemed like a logical way to do it, but I'm finding that working with enum is adding unnecessary difficulty.
foreach (var chapter in chapters)
{
var bibleitem = new Bible();
bibleitem.Version = (Versions)Enum.Parse(typeof(Versions), chapter.version);
}
Would it make more sense to just use string[] or something? I'm sure there is some added benefit, to enum, but I question my benefit.

The guidance from Microsoft is here:
https://msdn.microsoft.com/en-us/library/ms229058%28v=vs.100%29.aspx?f=255&MSPPError=-2147217396
In particular note: Do not use an enumeration for open sets
People write new Bibles all the time, so your set of enumerated values could change. You would be better off using string constants, for instance, where you could add more at will.
While we are at it, some additional critiques of your code.
class Verse
{
public int Number { get; set; }
public string Text { get; set; }
}
Why is this a class, and why are the properties settable? Do you envision having an existing Verse in hand, and wishing to change its number and text to something different? If not, then don't allow it. I would write this as
struct Verse
{
public int Number { get; private set; }
public string Text { get; private set; }
public Verse(int number, string text) : this()
{
this.Number = number;
this.Text = text;
}
}
Once it is created, it does not change. Also, this is a small immutable thing that is logically a value, so make it a struct.
class Chapter
{
public int Number { get; set; }
public List<Verse> Verses { get; set; }
}
Again, if you have an existing chapter, do you intend the set of verses to change? Because anyone can call Add on a list. Also, this constrains you to having the list available at all times, rather than computed lazily from a database. Make this IEnumerable<Verse>.
enum Versions
{
asv1901,
bbe,
This violates both naming guidelines and general legibility. Spell things out! AmericanStandardVersion1901 is far better than asv1901.

You should use enums when you have a named list of constants in your code and you know that this particular list is not gonna change over time (hence called names list of constants).
what benifits do you get?
READABILITY. Using enums increases the readability of your code. Consider the scenario where I have 2 employee types: Permanent and ContractBased. Now I can do this in my code like this:
if employee.Type == 1
// deal with permanent employee
else if employee.Type == 2
// deal with contract based employee here
such code is hard to read and maintain as no one could guess what employee.Type == 1 or what employee.Type == 2 means.
If I define an enum instead like this:
enum EmployeeType { Permanent=1, ContractBased=2 }
my code becomes like this:
if employee.Type == EmployeeType.Permanent
// deal with permanent employee
else if employee.Type == EmployeeType.ContractBased
// deal with contract based employee here
the readability of code gets maximized and also I have intellisense available.
The problem with strings:
1) you would end up having hard-coded string literals in your code
2) no intellisense
3) more memory consumption
how to deal with added complexity?
you should have an enum type variable for chapter.Version (which is right now missing) instead of int. that way you wouldnt need to do the parsing.

but I'm finding that working with enum is adding unnecessary difficulty.
it depends on your needs. if your set will not change enum is the best way to go as it adds a more control with a verbose description and limited set that cannot be bypassed when you work with many developers on the same project.
But
if your set can change during the development of the solution and you can't preview the set than a string would be the better way to go

Enums usually work best when:
No one adds or removes records to it anytime soon (hopefully never).
You don't need to use the real value behind your enum records.
You don't need to use the name of your records.
Enum.Parse can be used to get the enum record from a string, but as you noticed it's pretty ugly and I discourage you from using it. If you have the integral enum value you can simply perform a cast like this:
Versions version = (Versions)0;
But note that an enum is not guranteed to be of type int, it could also be any other integral value. int just happens to be the default. I do however also discourage you from relying on the enum's real integral value because something like this is also possible:
public enum Versions
{
One = 1,
Two = 2,
Three = 3
}
public void Do()
{
Versions version = (Version)-9;
// version is now Versions.One.
// Its value however is -9, what kind of version should -9 be?
}
The code above runs without errors because the runtime doesn't perform any checks on the value you are using for the cast.
The answer to your question depends on the nature of Versions. If you believe it will not be changed in the future then it is a good canditate for an enum in most cases. But you should use the enum everywhere across your application. I see in your sample that you are using the version as a string and therefore need to perform an ugly Enum.Parse. Consistency is an important factor when using enums, well it always is but it doesn't hurt to point it out again.
If you think your records are of a more dynamic nature you are probably best suited with strings. In that case you should use strings consistently. (Just wanted to point it out once again)

using the enum provides methods for comparing instances of this class, converting the value of an instance to its string representation, converting the string representation of a number to an instance of this class, and creating an instance of a specified enumeration and value.
Correcty using im class.
Exp.
public enum Versions
{
asv1901,
bbe,
darby,
kjv,
nasb,
niv,
nkjv,
nlt,
rsv,
web,
ylt
}
Next, implement
foreach (var chapter in chapters)
{
var bibleitem = new Bible();
bibleitem.Version = (Versions) "Your class enum"(typeof(Versions), chapter.version);
}
Enum and more used for good programming practices, clean code
Referency using enum: Enum Class Microsoft

C# questions private variables [duplicate]

This question already has answers here:
Should I use public properties and private fields or public fields for data?
(13 answers)
Closed 7 years ago.
Just want to make sure.
public class Product
{
private decimal unitPrice;
public int Id { get; set; }
public string Code { get; set; }
public string Name { get; set; }
//private string code;
public decimal Unitprice
{
get
{
return unitPrice;
}
set
{
if (value >=0)
unitPrice = value;
}
}
}
Why we would have to make private variable to unitPrice to return the value to UnitPrice, does it written for some reasons ?

You dont make it private just to return the value for it. private is one of the access modifier here. They are used to limit the scope of the access/usage of that particular variable in your code.
private here means that unitPrice is currently accessible or can be used by this particular class only. No other outside assembly can use this variable.
If you want to access a variable outside in other areas, you can opt to make it public.
Hope this clears it.

From design perspective the unit price property is exactly the same as the other properties but because there is a constraint on it.
if (value >=0)
only positive prices are valid, you have no other option than to foresee a private variable whereon the property is based.
In earlier versions of .NET we could not do something like this :
public int Id { get; set; }
And had to write it out in full all the time. The notation above is more handy and it makes the code clearer too. It used to be like this :
private int _id;
public int Id{
get{ return _id;}
set{ _id = value;}
}

Yes, get and set properties are useful when you want to have some control over variable. Consider the following case.
If you specify the variable as private you want no one to be able to access your variable.
But if you want others to be able to access your private variable but you dont want others to change it. In this case you can use Properties
public class Product
{
private decimal price;
public decimal Price{get{ return price;}}
}
now others have access to the price but they cant change it
In your case you are allowing others both to get and set your unitprice, which is equal to giving unitprice public access. However you are allowing on one condition that the unitprice should be set to 0. So C# properties are perfect match for this scenario.
Hope this helps!!

The public property UnitPrice is exposed to other classes to be read or modified. But being a property allows your class a degree of control over the value - you can validate any change for instance. Also, internally you can completely change how the value is obtained and modified without changing the contract of the class. So in other words, you would be able to make such changes without affect any consumers.
The backing field unitPrice is purely an implementation detail, it is internal state that is encapsulated by the class. Exposing this field means you lose any and all chance to modify the derivation of the value and you have no entry point for validating changes to the value. Properties may seem pointless abstraction at first but they will help make your code more maintainable as changes can be more easily confined to single classes.
The get and set blocks are purely syntactic sugar and under the covers the compiler creates two methods called get_UnitPrice() and set_UnitPrice(x) that are used for read/write operations on the property. You could just use similar methods but properties are more readable and designed to be a low cost way of interacting with class state and methods are for providing behaviour.

Honestly, what's the difference between public variable and public property accessor? [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
What is the difference between a field and a property in C#
Should I use public properties and private fields or public fields for data?
What is the difference between:
public string varA;
and
public string varA { get; set; }

The public property accessor gives you more flexibility in the future.
If you want to add validation to setting the value, you simply write a non-default setter. None of your other code would have to be modified.
There could also be reasons you'd want to replace the default getter with code. That can be a real pain with a public variable.

In addition to the other answers, you can also use a property to make the value read-only or even set-only:
public int Item { get; private set; } // read-only outside the class. Can only be set privately.
I have also run into situations where I later decide I want to proxy an object, or add AOP, which basically requires properties.

Public property accesses fields and internal class code through exposed getter and setter methods. A public field acesses the field directly.
Using propertys offers the potential to provide a layer of abstraction and design (ability to make set accessor protected, private).
When a property is specified and no body present an underlying private field is created by the compiler that is used to store the value against. Essentially:
private int item = 0;
public int Item {
get { return item; }
set {item = value; }
}
In general I tend to use properties for public exposed variables and fields for private. I might consider using a field if that field was accessed many times and speed was a crucial design requirement.

C# type design Question [closed]

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
This might sound a little stupid but I am still curious about what the community thinks.
So I have a WebService returning a UpdateInfo class.
Now consider the following definitions
public enum TTCFileType
{
API = 0,
BOOKMARK,
TICKMARK
}
public class FileUpdateInfo
{
public string FileName;
public string FileDownLoadURI;
public TTCFileType FileType;
}
public class UpdateInfo
{
public FileUpdateInfo fuInfo;
//Other
}
Here is the issue, if the TTCFileType has the value TICKMARK then I need another enum viz Tickmark Type( the biz logic demands this information). I am wondering what is the best way to represent that. I dont want a method signature where I have something Like
UpdateMethod( UpdateInfo ui, TickMarkType tt)
where I examine tt if ui.fuInfo.FileType == TTCFileType.TICKMARK
I guess I am trying to find an semi elegant way at least to represent the conditional requirement for getting the second piece of information out ( in many ways this so reminds of VARIANTS , if var.VT == VT_[thingy] then use vt.[thingy] and yes I know how c# developers feel about unions :-)
Anyway curious if there is a nifty way to do this
Thanks

Just include TickMarkType field to FileUpdateInfo class?

I'd be tempted to go with something like:
public enum TTCFileType
{
API = 0,
BOOKMARK,
TICKMARK_TYPE1 = 100,
TICKMARK_TYPE2 = 101,
TICKMARK_TYPE3 = 102
}
and so on. Depending on how many there are and how manageable it would feel within the wider context of your code.

Ideally, you need two additional structure(s)
public enum TickmarkType
{
TYPE1=0,
TYPE2
}
public class TickMarkFileUpdateInfo : FileUpdateInfo
{
public TickmarkType type;
}
And then read about polymorphism in web services

Store the enum value as an int. Add some offset to the value for your second enum (e.g., 1000) so that if the value is from the first enum it's 0..2 and if it's from the second enum it's 1000.1010 or whatever. Then you can set 2 properties, one that returns a nullable TTCFileType and the other that returns a nullable TickType, to read and write the values into the int field.

It seems like you're trying to use only data structures, when using OO features (such as inheritance) might help you. Maybe this example code gives you some ideas:
public class Update
{
// ... ?
}
public class FileUpdate : Update
{
public virtual string Name { get; set; }
public virtual string DownloadUri { get; set; }
public virtual bool IsTickMarked { get; set; }
}
public class ApiFileUpdate : FileUpdate
{
// ...
}
public class BookmarkFileUpdate : FileUpdate
{
// ...
}
You can still serialize these, given the proper serialization attributes.
In fact, you can define (potentially virtual) methods on these various classes, and actually use them to implement your program.
Overly segregating your data and code is known as the Anemic Domain Model Anti-Pattern.