A sample class in "C# Class Desing Handbook" (pg 137) does not call the classes validation method for a specific field from inside the classes only constructor. So basically the sample class allows you to create an object with bad data and only throws an error for that data when you call the field's property which does validation on it then. So you now have a bad object and don't it know until after the fact.
I never understood why they don't just call the property from the constructor thus throwing an error immediately if bad data is found during initialization? I've emailed them to no avail...
I tend to use the following format by calling my properties from my constructors - is this proper structure to validate initialization data? ty
class Foo
{
private string _emailAddress;
public Foo(string emailAddress)
{
EmailAddress = emailAddress;
}
public string EmailAddress
{
get { return _emailAddress; }
set
{
if (!ValidEmail(value))
throw new ArgumentException
(string.Format
("Email address {0} is in wrong format",
value));
_emailAddress = value;
}
}
private static bool ValidEmail(string emailAddress)
{
return Regex.IsMatch
(emailAddress, #"\b[A-Z0-9._%+-]+" +
#"#[A-Z0-9.-]+\.[A-Z]{2,4}\b",
RegexOptions.IgnoreCase);
}
}
Well, for one, you are likely to get the dreaded NullReferenceException, since you are not checking if emailAddress is null at any level. That particular check should be done in the constructor itself, and if emailAddress IS null, throw an ArgumentNullException. As for the rest, I don't see any particular problems with it as it is written in your sample. However, there are some issues that may arise if you make the property virtual, and derive children from this class. Execution order of field initialization, base and derived class consturctors then becomes an issue, and you have to be careful.
Yes, if your general approach is:
Ensure that you can only get an instance of a valid object
then I love it.
Constructors should be used to create objects that are immediately valid, not to create just a 'container', for things to be put in.
It makes no sense to me not to validate data in the constructor. As you point out, the object can end up in an invalid state. Given this design, you would not even realize that you had bad data when calling the getter.
For anything of moderate complexity or higher, I tend to use a Broken Rules approach rather than immediately throwing an Exception. In that approach, I define a BrokenRules object that contains information about the class and property that is invalid, and the reason that it is invalid. Then, in a common base class, I define a List to hold a list of everything "wrong" about the object. A property (again in the base class) IsValid indicates whether there are presently any broken rules.
The advantage of this is that there could potentially be several things wrong with the object state. If a user is being asked to correct the problems (i.e. this object is set from a UI), providing a list of all problems lets the user correct them in one go, rather than fixing one error just to be told there is another one. And another one. Etc.
I see nothing wrong with this approach. You can call methods on this within the constructor, and property setters/getters are just syntactic sugar for method calls.
the validation is happening when the Email address is set. This is where you want it because the email address could potentially be set again later.
If you also called validation in the constructor, you'd be making an extra, redundant validation call (once when constructed, another when the email address is set in the constructor).
Related
I have a member that returns a string from a resource file, and I want to unit test this, as there's quite a few and they could be changed by mistake. I understand that this is achievable using reflection but I've been asked to do it in a way that doesn't use reflection.
The members look something like this;
protected override string StringOne
{
get
{
return Resources.String;
}
}
I understand that setting up the return for the member can be done as;
mock.Protected()
.Setup<string>("StringOne")
.Returns("Returned string.");
and .verifiable() can be added to the end of this. But I can't find how to verify that a string is being returned. Or am I right in thinking that the by setting this up with .verifiable(), that the .returns("") value is the expected, and calling
mock.Verify();
will verifying that the member has returned the correct string or simply that the member was called at some point during the test?
The problem that you are encountering here is that you are trying to test something that isn't available from outside of the class. Tests should only test the public interface of your class so that the internals of the class can change as long as the public behaviour remains the same.
In this instance, I think that you have two options:
One is to move this code into another class with these properties being public, that way your test can just call the new public properties and check the return and the classes that need to use the value of the property can call your new class. Inheritance is generally not a great way of sharing code anyway (a blog post explaining this concept: http://www.blinkingcaret.com/2016/04/13/composition-superior-inheritance/)
The other is to test where these properties end up being used. For example, if you have some method that passes the value of StringOne into another mocked class, you can check that the correct value is passed through or if it ends up being used in a file path, you should test that the file path ends up being correct etc
Though I'm of course familiar with auto-properties, I just ran across this at work, which seems to be a distinctly different beast:
public SomeType SomeProp
{
get
{
return someField;
}
set
{
}
}
I was surprised it even compiled, and I imagine it must be a bug: the property seems to allow setting, but doing so does absolutely nothing.
Is there a use for this construct? Is it like those "Close Door" buttons in elevators that don't do anything, but make the user feel good?
Why would you expect it not to compile? The setter is just a void method with a single parameter, effectively. You can write broken methods perfectly easily without expecting the compiler to notice - and the same is true of properties.
I can't easily imagine any case where this would be deliberate, however, other than for "partial" implementations - e.g. to demonstrate language features, or if you're testing something that does set a property, but you don't care what the test sets it to. (I'd personally still usually at least record that the property had been set.)
You often see this when a result needs to be serialized in a web service or using an XML or binary serializer.
It's lazy and sloppy, but it happens often. This leaves the object with the "appearance" that the property is settable. If it's done to implement an interface and allow compilation, then the developer who did it needs to be beaten liberally about the head and shoulders with a blunt object, as he just broke the interface. If there is a valid reason that it can't be implemented, then the developer needs to kick it back up to the architect for review. You don't just leave empty stubbed methods behind when implementing an interface. If you don't have a technique defined for implementation at the moment, then at least throw a new NotImplementedException so the unit tests will catch it.
As far as serialization: ReadOnly properties don't get included in regular serialization, and that can leave the property unavailable to a web service client. (ref: Read-Only Properties Cannot Be Exposed by XML Web Services.) This is one of the reasons we should all be moving to WCF and DataContracts. If you accept this class as an input type for a method through WCF, then again retrieve the blunt object.
This doesn't seem useful by itself but consider an interface that required classes to have a SomeProp and you need to implement this interface in your class but have SomeProp only readable and not writeable.
public interface IQuestion
{
public int AnwserToLife { get; set; } //leave out 'set' for read-only
}
public class HitchHiker : IQuestion
{
public int AnwserToLife
{
get
{
return 42;
}
set
{
//never changes
}
}
}
There are a few use cases, where this would be a necessary workaround, some of which I have already encountered "in the wild".
E.g.: The property is a remains from old times, no longer of use, but some other part of the app has never been updated (Source lost? Third party?) and insists on setting the property. I have seen that in old code, that required plugins to set a isDirty property after updating some dataset, when the implementation changed to observe the dataset on itself, the isDirty property became useless, but couldn't be put away, because other code still wants to set it.
I would recommend avoiding this kind of programming. It compiles, because there is no reason it shouldn't, but if the interface requires you to implement a setter method, then there are two options:
Either the setter is redundant and the property should be made read-only, or
There exists a part of your code which will set this value and falsely assume that it worked.
Some methods will perform an operation on an object's property (can't think of an example), but some methods will not actually affect an object's property but just return a value (DateTime.Add() for example).
I know it's a simple question but I don't know how to refer to the two types of methods.
Can't think of the first, but the second could possibly be termed side-effect free, as in, it doesn't mutate state. It isn't so much how you'd refer to it, more a description of its behaviour.
You tend to hear "side-effect" used in concurrent languages, Axum had this concept baked in.
For example, this method is side-effect free:
public string GetName()
{
return "Adam";
}
Whereas this method isn't:
public int GetTotal(int optionalValue = 0)
{
_total += optionalValue;
return _total;
}
It may mutate state (in this case _total) as part of the method call. The next time you call it, _total may or may not be the same as last time as a result of the method call itself.
Unless you are thinking of property setters...
public string Name
{
set { _name = value; }
}
...I don't think there is any common term for describing methods. Most methods in objects will use internal state in some way - read or write.
You can just simply said
Instance Method
Static Method
Property Access Methods and Derived Property Methods are what I've used in the past to differentiate.
For example a property access method may well do the following for an imaginary property that isn't stored as a DateTime.
DateTime GetOrderDateTime()
{
return OrderDate.ConvertToDateTime();
}
a derived property method would be:
DateTime GetNextOrderDate()
{
return GetOrderDate.AddOneMonth(...);
}
I'm deliberately avoiding the discussion about what should be properties and what should be methods on the understanding that this is well defined in the context posted by the OP.
Modifying properties within these methods, as Adam says is a good way to introduce side effects - best to stick with good names (e.g. ModifyTotal) and conventions that Get methods and property gets should never (normally) modify properties.
If I have a simple class setup like this:
class MyClass
{
private string _myName = string.Empty;
public string MyName
{
get
{
return _myName;
}
}
public void DoSomething()
{
// Get the name...
string name = string.Empty;
name = _myName;
// OR
name = MyName;
// ...and do something with it...
}
}
Which should I use, the public property, or the data member?
Obviously, in this example it doesn't make a difference, since they both just reference the same variable. But what about real world uses of Public Properties?
In general, do Public Properties perform very little, in which case it is OK to call them? Or do people put a lot of functionality into their Public Properties that should not be called by internal class references?
I saw something in another post about NOT putting lots of functionality into Properties, since examining them in the Debugger can perform unexpected results. Is that true?
Use the property - any logic that may be encapsulated within the setters and getters ought to apply, even within the class itself. If there is no logic within the getters and setters it is still not safe to use the fields themselves because if at any point you wish to add logic around the access to those fields you will have to refactor much more.
I believe that you should reference the property as a general practice. While in this particular example it really doesn't make much of a difference, the get/set accessors offer the ability to do a bit more work when grabbing a property. For example, many of our property "get" accessors perform some lookup within a more complex data structure or set default values if nothing has been defined. So that the rest of the class can take advantage of this logic, we make a habit of using the properties. Just so we don't have to think too hard about it, we try to generalize the practice.
There may be instances in which we want to directly access the underlying data member, but then that is a conscious decision with a specific reason and it tends to be the exception.
I prefer properties because they easily handle read-only situations and it's easy to wrap them with any basic validation you might need to do.
If I'm just returning the value of the internal variable, I make the variable public - there's no harm to doing so. I've always used Public Properties when I want to do something in response to either a viewing or a changing of the value - ie, write it to a database, set something else too (as in the second part of your example).
The question you have to ask is whether you want what happens inside your class to trigger these events. If you do, the same way an external caller would, then access the values via the property. If you just want to read the value, use the internal variable.
To answer your question, there's no harm to doing it either way - just consideration of the potential side-effects.
If you have a Property that gets and sets to an instance variable then normally you always use the Property from outside that class to access it.
My question is should you also always do so within the class? I've always used the Property if there is one, even within the class, but would like to hear some arguments for and against as to which is the most correct and why.
Or is it just a matter of coding standards being used on the project?
One of the stronger argument for accessing local (class scope) variables through properties is that you add a level of abstraction in your class. If you change any logic concerning how that field is stored then the rest of your code will be left unaffected.
For example you might change that from a local variable to a property of a child object, to a database call, to a webservice call, to a static property on a class and so on. When making the change it gives you a single point of change, the property, and you do not have to update the rest of your class since they all use the property.
Also using the property enables you to apply business rules on the value of the property instead of having to enforce the same rule at each location where you'd directly access the field. Again, encapsulation
With the introduction of automatic properties there's even less reason to explicitly have a local variable, unless you need to apply business rules on the get/set
It depends on whether you want to apply any logic implemented within the property setter, and so you really have to decide on a case by case basis.
When you go directly to the private field, you know that the field is being set to exactly what you say.
When you go through the Property, the value gets set according to the setter logic, so you get any business rules or validation you want over values assigned to that field.
Pretty hard to come up with a rule about when doing either is 'correct', about the only one I'd say I follow is that in constructor initialisation I'd pretty much never use the Property.
Yes I think you should use properties internally in your classes whenever possible. Properties are more flexible and allows you to add logic for validating it's value at a central place.
You can also delay the initialization of the the field to whenever the property is used instead of being forced to do it in the constructor (or everywhere the field is used). Example:
class Test {
private int _checksum = -1;
private int Checksum {
get {
if (_checksum == -1)
_checksum = calculateChecksum();
return checksum;
}
}
}
I think it's purely preference.
Though, I find myself using the properties a lot more in C# 3.0 with the auto-property support:
class Foo {
public string Value { get; set; }
public void Write() {
Console.Write(Value);
}
}
Generally depending on the project coding standards I use a "_" or "m" preceding the name for my private class attributes. (Like below)
private int mVariable;
private int _Variable;
With those in front of the variable I recognize right away that I'm dealing with an internal variable for the class. Then when it comes to debugging later myself or someone else can immediately recognize that the code is dealing with an internal private variable and make an adjustment. So it comes down to readability for me.
Always Use Properties, Here are some of the reasons
Easy to Use. In visual Studio you can use "Prop Tab Tab". You will get the property snippet
Properties are language elements that are accessed as though they are data members
.Net framework classes uses it, the data binding code classes in the .NET Framework support properties,
Properties have all the language features of methods. Properties can be virtual