Develop Reference

Dynamic object against Interface Method

I'm rewriting a desktop solution and I have the main root Form, that contains Properties that should be accessible by other elements of the application.
You could use an Interface method to get the property or your could get the Form as a dynamic object and query the property. Code example below.
Interface-based approach
public interface IUersInterfaceMainScreenGet
{
dynamic GetClientDetails();
}
The forms interface-implementation looks like this:
public dynamic GetClientDetails()
{
return currentClients;
}
Calling the Interface
var mainScreen = (InterfaceProject.IUersInterfaceMainScreenGet)System.Windows.Forms.Application.OpenForms["mainScreenForm"];
return mainScreen.GetLastBodyPluginFormName();
Dynamic-based appraoch
dynamic form = Application.OpenForms["MainScreenForm"];
form.currentClients
Both instance needs to get the current Active form, but Which once would be the best in practice to memory usage?
With the Interface the Property that I want to get can be private, but for Dynamic it needs to be public

Your question is quite hard to understand. However I have a guess on what you mean.
When you have your interface you can get the clients details via a method called GetClientDetails. On the form its implementation simply returns the private field (not property) currentClients.
Usually it´s a good idea to know the types you handle with, so using interfaces is a good idea as you have compile-time checks on what you can access and what not. In your case you kno that the object returned from Forms.Application.OpenForms["mainScreenForm"] has a method for accessing the client-details. When using only dynamic you have no knowledge at all on the contained object, you could do everything with it - whereas the most will fail at runtime. But why do you want to throw away knowledge that you already have?
So my basic suggestion is: allways use strongly-typed interfaces. Only in a few seldom circumstances you may actually need dynamic.
Concerning the memory-footprint there is no difference between both solutions. What counts is the memory of your actual instance, which is the same, no matter on how you access the data. So you need a field in both cases. The only difference is how you access that field, one time you this happens directly (dynamic) and on the interface you access it by calling the method.
So there is no difference on the following two statements concerning memory-footprint:
var form = (IUersInterfaceMainScreenGet)Application.OpenForms["mainScreenForm"];
return form.GetClientDetails();
And
dynamic form = Application.OpenForms["MainScreenForm"];
return form.currentClients

Mocking a private field

I know a similar question has been asked but I have not found a clear solution. I'm trying to mock a private field from a large class. The private field gets instantiated in some earlier method and I'm trying to unit test a latter method which references the field.
So I have an earlier method in my class:
public bool validateAll(ref DataEntry[] oEntries, string sMediaPlanId, ITemplateGenerator oTempGen)
{
...
// private field that I am trying to mock
this._sMediaPlanObjective = (MPWrapper.Instance).getMediaPlanObjective(sMediaPlanId);
...
}
And I'm trying to Unit test a method that references the private field:
public bool validateFlightObjective(ref MPDataEntry oEntry)
{
...
string entryFlightObjective = oEntry.getFlightObjective();
string mediaPlanObjective = this._sMediaPlanObjective;
if (entryFlightObjective != mediaPlanObjective)
{
return false;
}
...
return true;
}
Given that I have a large class and this is just one method I want to test, is there a possible way to just mock this private field? Am I missing something basic or should I consider some other approach?

You can't mock anything that's private, static, or essentially - non overridable (this comes as a free mocking libraries limitation).
What you usually do in such situations (when it appears that private member has to be tested), is extracting your private member to a separate class and inject it to tested class as a dependency.
In your case, you actually need to extract code that creates _sMediaPlanObjective, which is this line:
this._sMediaPlanObjective =
(MPWrapper.Instance).getMediaPlanObjective(sMediaPlanId);
Object that provides getMediaPlanObjective method should be injected to your tested class. If you do so, you can simply mock that object and tell it to return mocked version of _sMediaPlanObjective.

You can use JustMock framework.
For example:
double value = 0;
var fakeFilterSetHelper = Mock.Create<FilterSetHelper>(Behavior.CallOriginal);
Mock.NonPublic.Arrange<double>(fakeFilterSetHelper, memberName: "GetPriceRangeFromSession").Returns(value);

There is no reason to have any kind of tests on private fields.
using an object you can reference to the public methods as the object API.
the object itself can have it's changing state according to the operation you perform on it - but it will be reflected in other public methods / access to DAL (DB / Registry / File/ any other resource that is not in memory)
So in your case you can have a unit tests like that:
call the method that initializes the private field as you expect it to and -
Call validateFlightObjective with a parameter that you know that have to return false according to the _sMediaPlanObjective "wanted to be state", and verify that the result is false.
Call validateFlightObjective with a parameter that you know that have to return true according to the _sMediaPlanObjective "wanted to be state", and verify that the result is true.
If you see that it is hard to test this object, then that might be a "smell" - maybe you have more than one responsibility there and you should start refactoring and split the class to smaller classes which will be easier to test
That it a bit long but i hope it was helpful

Properties with empty accessors

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.

Do you use Data Members or Public Properties from within the Class itself?

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.

Validate constructor data

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).