my boss insisting on the following rule: all variables passed into constructor should be available through a read-only property.
I don't see a real reason why this should be true, because class should do that it's supposed to do and not to provide theirs structure to others. I understand that sometime it's useful, but it isn't general rule.
Are my thoughts correct? Am I missing something? Anyone can add more arguments or oppose to that?
Example of rule:
public class MyClass
{
public MyClass(ISomeProvider someProvider)
{
SomeProvider = someProvider;
}
public ISomeProvider SomeProvider { get; private set; }
public void DoSomeWork()
{
...
}
}
Thank you.
Personally I would say no... I never believe there is one rule that fits all. If the parameters are used internally to the class then there is no need to expose them.
If you passed a 'raw' string password into an encryption class you wouldn't expect the raw string to be accessible throughout the lifetime of the object, in fact doing so may present a security risk.
On the flip side though, sometimes you have to follow the standards set out by the team/manager. If you think the principle is wrong discuss this detailing the arguments for/against the idea.
It may be applied like a rule on some specific part of the some specific projects (should say, sounds very strange design, but..), but it's never, ever can be a generic rule in software design even in the domain of one single project.
The rule decided by your boss can help in debugging to know the properties of object. It's not a rule, you can treat it as design pattern created by your project manager.
public class MyClass
{
private ISomeProvider someProvider;
public ISomeProvider SomeProvider
{
get
{
//logic here
return this._someProvider;
}
}
public MyClass(ISomeProvider someProvider)
{
this._someProvider = someProvider;
}
public void DoSomeWork()
{
}
}
Related
Disclaimer: I would love to be using dependency injection on this
project and have a loosely coupled interface-based design across the board, but use of dependency-injection has been shot down in this project. Also SOLID design principles (and design patterns in general) are something foreign where I work and I'm new to many of them myself. So take that into
consideration when suggesting a better design to this problem.
Here is a simplified version of the code I'm working on, and as such it might seem contrived. If so I apologize. Consider the following classes:
// Foo is a class that wraps underlying functionality from another
// assembly to create a simplified API. Think of this as a service layer class,
// a facade-like wrapper. It contains a helper class that is specific to
// foo. Other AbstractFoo implementations have their own helpers.
public class Foo : AbstractFoo
{
private readonly DefaultHelper helper;
public override DefaultHelper Helper { get { return helper; } }
public Foo()
{
helper = new Helper("custom stuff");
}
public override void Operation1(string value)
{
Console.WriteLine("Operation1 using " + value);
}
public override void Operation2()
{
Console.WriteLine("Operation2");
}
}
// Helper derives from a default implementation and allows us to
// override it's methods to do things specific for the class that
// holds this helper. Sometimes we use a custom helper, sometimes
// we use the default one.
public class Helper : DefaultHelper
{
private readonly string customStuff;
public Helper(string value)
{
customStuff = value;
}
public override void DoSomethingHelpful()
{
Console.WriteLine("I was helpful using " + customStuff);
}
}
Say these two class are used as follows:
// foo referenced and used in one part of code
var foo = new Foo();
foo.Operation2(); // or foo.Operation1();
// some other point in the program where we don't have a reference to foo
// but do have a reference to the helper
helper.DoSomethingHelpful();
However I now find out that I also need to perform foo.Operation1 in some implementations of helper.DoSomethingHelpful();? Potential workarounds I thought of would be:
Have foo and helper have a bidirectional relationship. So that in DoSomethingHelpful we can call foo.Operation2
Have foo implement IHelp interface and move the "helper" code into foo
Use delegation and pass the method Operation2 as an Action<string> delegate into the constructor of Helper.
None of these approaches seem to be ideal (though I've pretty much determined I don't like option 1 and am worried about maintainability with option 3 if we find out later we need to pass in more delegates). This makes me wonder if there is a problem with the initial design of the Helper/Foo combo. Thoughts?
How about a casual ("uses") relationship:
public class Helper : DefaultHelper
{
private readonly string customStuff;
public Helper(string value)
{
customStuff = value;
}
public override void DoSomethingHelpful(AbstractFoo foo)
{
foo.Operation1();
Console.WriteLine("I was helpful using " + customStuff);
}
}
So you modify the abstract helper to expect a reference to the proper Foo implementation.
"None of these approaches seem to be ideal (though I've pretty much
determined I don't like option 1 and am worried about maintainability
with option 3 if we find out later we need to pass in more delegates).
This makes me wonder if there is a problem with the initial design of
the Helper/Foo combo."
You're exactly right - there IS a problem with the design of Helper and Foo. The basic Foo/Helper relationship as you initially described it is fine, and is a common pattern when you have to wrap other objects that you do not control. But then you say:
"What if I find out that I also need to perform foo.Operation1 in some
implementations of helper.DoSomethingHelpful();?"
This is where we have a problem. You started out describing a relationship where Foo is dependent on Helper; now you are describing a relationship where Helper is dependent on Foo. That immediately tells me that your dependency relationships are tangled up. Dependency relationships between objects should only go one way; in fact dependency injection relies on this.
I think you have what you need. Try not to design for the "just in case I need it later" and don't fix what is not broken. If in the future you need to use Operation1 from your helper, then add it as a dependency on the constructor (as you suggested), or just pass it to the method you are calling. It will depend on the scenario, and you will have it when you actually need something.
EDIT: changed the "Try not to design for the future" as it doesn't seem what I want to say.
EDIT again due changes in the question
You could so something like this:
helper.DoSomethingUsefulWith( foo );
so your helper method will receive the dependency it needs in order to work
I think all your solutions are good; they just offer different capabilities. These differences don't matter too much now but are likely to in the future.
You prefer the second one, and your instincts are the best guide here, you knowing more than the rest of us about your code's future. I like your second solution the best just because it gets rid of a class and is simpler. Due to it's simplicity, if you have to do something else later, you won't have to throw away a lot of work.
The first method lets you play games with different Helper (IHelper?) instances and subclasses. The last method adds a lot of flexibility to Helper. (Although it may add so much you don't need Helper, just the method you're passing to it.) You can switch to using them later if either seems to solve more of the future's unguessed problems.
So I've (mostly) wrapped my head around C#'s componentization paradigm and why that's a superior (more predictable, flexible) alternative to confusing and quasi-unpredictable multiple inheritance of c++.
However, I have a couple things that are trouble me.
So if I understand correctly the general approach to adding a component is:
Create an interface that has that component of name I<ClassName adjective>
public interface IHasGear { Gear gear { get; set; } }
public interface IBladeEquipped { Blade blade { get; set; } }
Create an extension class that calls appropriate methods in the interfaced classes.
public static class GearExtensions
{
public static void Stop(this IHasGear machine)
{
machine.gear.KineticStop();
}
public static void Accelerate(this IHasGear machine)
{
machine.gear.ApplyAngularAcceleration();
}
}
public static class BladeExtensions
{
public static void Cut(this IBladeEquipped machine)
{
machine.blade.Cut();
}
public static void ReSharpen(this IBladeEquippeded machine)
{
machine.blade.ReSharpen();
}
}
And then finally add the interface reference and instance of the referenced class to my class that uses the selected component.
public class MeatGrinder : IHasGear, IHasBlade
{
public Gear oldToothyOne { get; set; }
public Blade mrPointy { get; set; }
public MeatGrinder() { oldToothyOne = new Gear(); mrPointy = new Blade();}
}
Now my couple of questions:
Why ALWAYS force the instantiation of the var?
I understand that you might want this if there is inheritance, as you could implement the var with different children. But what about the simplest case of non-inheritance? Why not build in an automatic mechanism to auto-implement in the compiled code the base class(es) in the interfaces is (are) implemented if they are not explicitly implemented
Is there a way to template this process in a ubiquitous fashion?
Obviously this is a repetitive task, if you have several components. Given the ambiguity, is there a way to streamline the workload??
Is there a superior componentization(/inheritance) scheme to the method I describe?
Things to keep in mind:
There's only a few component classes.
I want to be able to use the component class functions as direct calls in the composited class.
There are multiple composited classes (component classes << composited classes)
The components are dissimilar and thus not appropriate for unification in one class.
Given the above considerations an approach that forces me to write individualized code for each composited class is not a desirable approach.
EDIT 1:
I shouldn't have been ambiguous. The reason why I'm not using direct inheritance here is because I have multiple "key" components with functionality that I want to be able to directly address ubiquitously and publicly... e.g. I want to be able to say:
Machine myMachine = new Machine();
myMachine.Accelerate();
myMachine.Cut();
myMachine.ReSharpen();
Hopefully that helps to clarify my question and why I'm adopting this scheme.
Also, I had a couple errors in my example code (a var was non-public and my naming was consistent... these have been corrected.
EDIT 2:
Things that don't make sense for me (to my understanding):
a) Abstract Classes
Why? No multiple inheritance
b) Implicit Operators, a la, hcb's suggestion:
http://www.codeproject.com/Articles/10072/Simulated-Multiple-Inheritance-Pattern-for-C
Why? This approach requires you to create operators for ever class utilizing the component classes, which would result in much more code in a scheme where the interface is commonly used. To me if you're going to go that route, just make traditional wrapper functions rather than get all fancy.
My need for a more elegant solution is driven by ubiquity and mass use of a couple common components that perform redundant functionality, but are dissimilar and thus inappropriate to lump in a single class (despite the convenience that would provide).
Edit 3:
Props to svick for showing me how to format my code nicely without edit diving! :)
Retitled the question to make it more clear, added more precise requirements for suggesting alternate solutions.
What you're doing is just an attempt to emulate multiple inheritance. I don't think it's “the general approach to adding a component”.
I don't think what you're doing is a good way of using extension methods, it looks more like an anti-pattern to me. Especially since you're doing it just to save a few keystrokes, it doesn't add you any other benefit.
I think the answer to your questions about why you can't use some simpler way to do that is that C# tries to be explicit and consistent.
Explicit in that it won't guess what you mean, it makes you spell it out. This is because its guess could be very easily wrong. And the rules how exactly does it guess would probably have to be very complicated and thus confusing. (“I made this little change and now my code behaves completely differently.”)
Another thing is consistency: if you usually implement interface one way, but sometimes you do it differently, it makes the language more complicated and more confusing. Of course, there are cases where inconsistencies like this are worth it.
Specifically, if the feature of automatic implementation of properties from interfaces would work, your code would compile, but wouldn't work correctly: IBladeEquipped defines the property blade, but your class contains the property mrPointy. The compiler would see that you don't implement the required property and implement it for you. And then your code would fail with a NullReferenceException, because blade will always be null. So I think your code presents a good argument against that feature.
Also, I think your example is actually quite good at explaining why you shouldn't write the code the way you want. If you want to resharpen the knife of a meat grinder, do that: grinder.blade.Resharpen(). Writing it differently would feel less natural and more confusing to me.
I'm not sure if this is what your looking for but i like to couple interfaces with abstract base classes to implement default methods and properties:
public interface IHasGear { Gear gear { get; set; } }
public abstract class BHasGear : IHasGear { public virtual Gear gear { get; set; } }
public class MeatGrinder : BHasGear
{
//no need to implement gear, the abstract class already implemented it
private Gear oldToothyOne { get; set; } }
}
I have the following interface:
public IStateMachineConfigurator
{
??? Configure(StateMachine machine);
}
In the implementation I am calling some of the StateMachine methods to configure it like this:
machine.Configure(States.State1)
.Allow(Triggers.Trigger1);
The question is, can I rely on the fact that the StateMachine object is a reference or should I use a return value or a return parameter like ref/out?
EDIT:
The state machine itself comes from a library and thus I cannot decide it's implementation.
If you wanna go with the builder pattern then your effectivly return the mutable state that is being passed in. This is perfectly fine, if you wanna go down that road. This is how the StringBuilder class operates and on a somewhat different note jQuery. It can be very nice for building objects in a compact and readable fashion. However, those objects should be designated as such. Builder objects and preferably not take on more than necessary.
Yes, you can rely on the fact that StateMachine is an object reference. Some people might choose to return a bool or perhaps an enum to give the programmer some kind of hint as to what happened in the Configure method (ie. success/fail/no change/etc.). Others might choose to throw an exception in the event something goes wrong.
All are perfectly valid, just be careful how deep you chain the method together, as something like:
machine.Configure().Allow().someMethod().someOtherMethod()
Gets difficult to debug and trace.
Instead of creating a Configurator, I would rather craete a Configuration object and pass it in the StateMachine constructor. This makes it cleare to the users of StateMachine class that they have to provide it with a valid configuration before using it.
class StateMachineConfiguration
{
public IEnumerable<State> States { get; private set; }
public IEnumerable<Trigger> Triggers { get; private set; }
}
class StateMachine
{
public StateMachine(StateMachineConfiguration config)
{
if(config == null)
throw new ArgumentNullException();
this.Configure(config.States);
this.Allow(config.Triggers);
}
}
When should I use the this-keyword for properties in code?
public class MyClass {
public string MyString { get; private set; }
public void MyMethod() {
OtherClass.DoStuff(MyString); // Or this.MyString?
}
}
I know that if the type and name of a property is the same you have to use this. to make it work.
public string Emailer Emailer { get { return _emailer; } }
What are the guidelines for using this. on Properties and even Methods in a class? I know it makes no difference in the compiled code. It's all about... hold your breath... best practices.
Do whatever you and your team find most readable. Some people like to be explicit; I only specify this when I actually have to. It will make no difference to the compiled code.
If a parameter name and an instance member have the same name, you will need to use this.
Like:
public class MyClass
{
private string something;
public void SomeMethod (string something)
{
this.something = something;
}
}
But I'd advice you to choose names in that fashion that you'll never need to use this. Doing otherwise is just asking for trouble - sooner or later you'll forget this somewhere and will have a hard time debugging your code.
Whether or not to use this is mostly an issue of preference and hence there is no right or wrong answer. It can become a bit of a religous war though with devs. I often find it's best to come to an agreement on the team one way or the other and use StyleCop to enforce the decision afterwards.
Personally I prefer brevity and only use this when it's actually necessary. But I'd choose code base consistency over my personal preferences here because it's a fairly minor issue.
There are a few cases where it's explicitly needed. Extension methods on this and in certain cases to disambiguate an identifier come to mind. I find these are fairly rare though.
I have a class with various public properties which I allow users to edit through a property grid. For persistence this class is also serialized/deserialized to/from an XML file through DataContractSerializer.
Sometimes I want to user to be able to save (serialize) changes they've made to an instance of the class. Yet at other times I don't want to allow the user to save their changes, and should instead see all the properties in the property grid as read only. I don't want to allow users to make changes that they'll never be able to save later. Similar to how MS Word will allow users to open documents that are currently opened by someone else but only as read only.
My class has a boolean property that determines if the class should be read-only, but is it possible to use this property to somehow dynamically add a read-only attributes to the class properties at run-time? If not what is an alternative solution? Should I wrap my class in a read-only wrapper class?
Immutability is an area where C# still has room to improve. While creating simple immutable types with readonly properties is possible, once you need more sophisticated control over when type are mutable you start running into obstacles.
There are three choices that you have, depending on how strongly you need to "enforce" read-only behavior:
Use a read-only flag in your type (like you're doing) and let the caller be responsible for not attempting to change properties on the type - if a write attempt is made, throw an exception.
Create a read-only interface and have your type implement it. This way you can pass the type via that interface to code that should only perform reads.
Create a wrapper class that aggregates your type and only exposes read operations.
The first option is often the easiest, in that it can require less refactoring of existing code, but offers the least opportunity for the author of a type to inform consumers when an instance is immutable versus when it is not. This option also offers the least support from the compiler in detecting inappropriate use - and relegates error detection to runtime.
The second option is convenient, since implementing an interface is possible without much refactoring effort. Unfortunately, callers can still cast to the underlying type and attempt to write against it. Often, this option is combined with a read-only flag to ensure the immutability is not violated.
The third option is the strongest, as far as enforcement goes, but it can result in duplication of code and is more of a refactoring effort. Often, it's useful to combine option 2 and 3, to make the relationship between the read-only wrapper and the mutable type polymorphic.
Personally, I tend to prefer the third option when writing new code where I expect to need to enforce immutability. I like the fact that it's impossible to "cast-away" the immutable wrapper, and it often allows you to avoid writing messy if-read-only-throw-exception checks into every setter.
If you are creating a library, it is possible to define a public interface with a private/internal class. Any method which needs to return an instance of your read-only class to an external consumer should instead return an instance of the read-only interface instead. Now, down-casting to a concrete type is impossible since the type isn't publicly exposed.
Utility Library
public interface IReadOnlyClass
{
string SomeProperty { get; }
int Foo();
}
public interface IMutableClass
{
string SomeProperty { set; }
void Foo( int arg );
}
Your Library
internal MyReadOnlyClass : IReadOnlyClass, IMutableClass
{
public string SomeProperty { get; set; }
public int Foo()
{
return 4; // chosen by fair dice roll
// guaranteed to be random
}
public void Foo( int arg )
{
this.SomeProperty = arg.ToString();
}
}
public SomeClass
{
private MyThing = new MyReadOnlyClass();
public IReadOnlyClass GetThing
{
get
{
return MyThing as IReadOnlyClass;
}
}
public IMutableClass GetATotallyDifferentThing
{
get
{
return MyThing as IMutableClass
}
}
}
Now, anyone who uses SomeClass will get back what looks like two different objects. Of course, they could use reflection to see the underlying types, which would tell them that this is really the same object with the same type. But the definition of that type is private in an external library. At this point, it is still technically possible to get at the definition, but it requires Heavy Wizardry to pull off.
Depending on your project, you could combine the above libraries into one. There is nothing preventing that; just don't include the above code in whatever DLL you want to restrict the permissions of.
Credit to XKCD for the comments.
Why not something like:
private int someValue;
public int SomeValue
{
get
{
return someValue;
}
set
{
if(ReadOnly)
throw new InvalidOperationException("Object is readonly");
someValue= value;
}
I would use a wrapper class that keeps everything read-only. This is for scalability, reliability and general readability.
I do not foresee any other methods of doing this that will provide the above three mentioned benefits as well as something more. Definitely use a wrapper class here in my opinion.
You can not get compile-time checks (like given with the keyword readonly) by changing a property to readonly at runtime. So there is no other way, as to check manually and throw an exception.
But propably it is better to re-design access to the class. For example create a "writer class", which checks if the underling "data class" can currently be written or not.
You can use PostSharp to create OnFieldAccessAspect that will not pass new value to any field when _readOnly will be set to true. With aspect code repetition is gone and there will be no field forgotten.
Would something like this help:
class Class1
{
private bool _isReadOnly;
private int _property1;
public int Property1
{
get
{
return _property1;
}
set
{
if (_isReadOnly)
throw new Exception("At the moment this is ready only property.");
_property1 = value;
}
}
}
You need to catch exceptions when setting properties.
I hope this is something you are looking for.