Reputation: 612
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.
Upvotes: 2
Views: 114
Reputation: 20745
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()
{
}
}
Upvotes: 1
Reputation: 34489
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.
Upvotes: 7
Reputation: 62248
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.
Upvotes: 1