I was wondering, what is good practice:
private int value;
public int Value { get { return this.value; } }
private int DoSomething()
{
return this.Value + 1;
//OR
return this.value + 1;
}
So, the question is about how you should treat your class variables. Should you access them through your properties or just direct?
In this case, it doesn't matter so much, but in cases where you're using lazy loaded variables it would matter and you'd access through your property. For instance:
private Myobject _value;
public Myobject Value
{
get
{
if (_value == null) _value = new MyObject();
return _value;
}
}
private MyObject DoSomething();
{
//If you access _value here, it might be null...
//so you should access it through the property:
return Value;
}
In a case where your method would fail by calling the field directly, you either handle it properly, or you access it by the cleaner method - via your property.
It all comes down to the architecture of your application and for that you have to ask the question: What makes the most sense from a maintenance perspective?
I would have to say that if the field is initialized properly and it doesn't cause you a headache to access it directly, then access it directly. If it causes extra work (and thus extra maintenance), then reference the property.
Like with anything else, weigh up the pros and cons. Use your own common sense - standards wars are a ridiculous distraction. Unless they provide you with arguments you haven't already thought of yourself, don't waste your breath fighting with them. If you have a valid reason to choose whichever path you choose, then that path is the right one - it comes down to the designer's prerogative.
My thoughts on pros and cons are this:
Going with property:
I can change the implementation of how that value is returned without needing to refactor my whole class.
I can lazy load the value which means that if I never access it, it never wastes resources.
I can hide all the implementation details of how the value is returned in a single place without having to handle it all over my code.
Going with the field:
I don't have the potential performance overhead of having to step through the property code each time I access the value.
I need to make sure the value is initialized properly on every call, or handle cases where it is not.
I can affect the value even though my property may only provide a read-only interface to my value.
So I guess my approach would be to use the property unless I needed to write to the value directly, in which case, I'd go with the field - as my property is read-only and thus can't be written to.
That's just me though - your property may be read/write and you may decide from a design standpoint that accessing the field directly is okay - and that is okay too.
The trick is always do things for a reason, don't do things blindly just because.
I'd go for direct access. It's all "keeping it within the family", so to speak.
This is something that standards wars have been fought over. Usually it won't make a big difference and I settled on just accessing the variable directly from inside the class with the exception of getters and setters which do something beyond just getting or setting the value.
The catch is that you have to know what the getter and setting are doing, or you have to always limit them to the simple operation with no additional functionality.
The properties are introduced to "hide" eventually more complex structure than returning a single value from a field.
I would advise that you use the property than the field in all your code, so if the property code changes later on to something more complex, you do not need to refactor the rest of the class.
I vote for return this.value + 1.
The argument against this (ie going via the property) is that you might want to add extra code to your property method later, so there'd be less changes if you did that. But I'm of the mind that properties should just do as advertised and no more; that is, they should do just enough to return that value.
In some situations it's a good idea. In the case of the iPhone, for example, given the low amount of memory, you might receive "memory warnings" from the OS. As per those warnings, you are asked to release memory to avoid being shut down. Usually, this memory comes from resources like images, sounds or big data chunks that you don't need continuously on memory.
In that case, I sometimes access some private ivars through Objective-C private accessors, which usually check if the ivar is "nil" (NULL), and will load the data back in memory, in a "lazy loading", ad-hoc way. For this I find private properties really useful. Otherwise, I use direct ivar access.
As always, I don't think there's a definitive answer to this question: "it depends".
If your class can't trust its own methods to access its own private variables, who can it trust?
I don't think it's a black and white question. A few things spring to mind:
Firstly, if the property has no behaviour (i.e. get/set just pass through to getting and returning a field), then make the field into an auto-property and remove the dilemma. Fewer lines of code, no confusion.
Secondly, if the property has side-effects (lazy loading, change notification, stats gathering etc.) then you must considered whether it is it appropriate to trigger that behaviour via private updates. If it is appropriate, just use the property. If it's not appropriate then don't (or change the design to make it more obvious).
Also, where appropriate you can always introduce a wrapper type to remove the confusion if it's very important.
E.g. say you had an Angle property that is protected by an argument check.
public class ManThatCanRotate
{
public int Angle
{
get { return m_angle; }
set { if(value >= 0 && value < 360) m_angle = value; }
}
public void RotateLikeSomeKindOfLunatic()
{
// imagine this has been called 359 times already.
m_angle++; // ruh-roh
}
}
Bad things(tm) will happen if you set m_angle directly as above; the angle will become invalid. You can simply refactor the angle into its own type so that it is impossible to make invalid, thus removing the problem.
Related
Using code analysis on my program I often get this warning:
CA1051 : Microsoft.Design : Because field 'Form1.Testcode' is visible outside of its declaring type, change its accessibility to private and add a property, with the same accessibility as the field has currently, to provide access to it.
So it tells me to either change the code from this: Public Testcode As String
To this: Public Property Testcode As String
Or to this:
Private _testcode
Public Property Testcode As Object
Get
Return _testcode
End Get
Set(value As Object)
_testcode = value
End Set
End Property
So my question is, what is the difference between the 2 code suggestions.
Is one faster than the other or does it prevent bugs or anything else? I've been using the first code since ever and never had issues with it neither feeling lags or something else.
Saying I want my program to be as fast as possible should I change the Code that I have to the Property code and if yes, which to choose?
The point of properties is that they behave like fields from the outside but like methods from the inside. In fact, once your code is compiled, the getter and setter of your property actually are methods. Java doesn't support properties but even there the convention is to declare a field private and then declare two methods for getting and setting the field value.
Always use properties to expose data publicly. If nothing else, it means that you can bind objects of that type because properties support data-binding while fields do not. It also makes it far less likely that you will need to change the type interface if you need to change the implementation later.
As for how to implement the property, always use an auto-property, i.e. the one-line option, unless you need to add extra code to do things like validation or raise an event. If you write an auto-property, the private field is still created behind the scenes - you can even access it in code - and the compiler still creates the getter and setter methods. In short, prefer this:
Public Property Data As SomeType
to this:
Private _data As SomeType
Public Property Data As SomeType
Get
Return _data
End Get
Set
_data = value
End Set
End Property
An example of a situation that would require the full property is below:
Private _number As Integer
Property Number As Integer
Get
Return _number
End Get
Set
'Validation
If Value < 0 Then
Throw New ArgumentOutOfRangeException("value", $"'Number' must not be less than zero.")
End If
If _number <> Value Then
_number = Value
'Change notification.
OnNumberChanged(EventArgs.Empty)
End If
End Set
End Property
Public Event NumberChanged As EventHandler
Protected Overridable Sub OnNumberChanged(e As EventArgs)
RaiseEvent NumberChanged(Me, e)
End Sub
Is one faster than the other? No.
Does it prevent bugs or anything else? Yep.
In VB, Public Testcode As String and Public Property Testcode As String look pretty much the same. But let's put the syntax aside, we are speaking about member variables and properties here.
Member variables are variables you have to use in your classes when they have to "live" as long as the class instance does. It is basically the same as every other variable but without defined context (say the end of a method for example). You'd use them typically to hold kind of a state like whether the user had confirmed a message or anything like that. If this kind of information is important for the logic of your class but not for others, you have a perfect candidate for a member variable.
Properties are not very different here and can technically be used the same. However they are part of an external interface. If you have to hold information that is important to your class and to other classes (using your class) as well, you have a perfect candidate for a property. This could be the border color of a button for example. Other classes might set the color by a given design and the button itself needs it to render the border accordingly, of course. Public methods and properties build the interface other parties can interact with. There are some useful answers here on StackOverflow, I'll link them below instead of copying their content.
Why should we care?
So we're basically talking about encapsulation and information hiding. But let's look at that in a more practical example.
Look at your desktop PC. Turn it around and take a look at all the connectors it exposes. This is the public interface of the machine. That's what you as a consumer of the machine can interact with. You see USB ports, HDMI connectors and so on. You don't need to know the internals of the machine to understand where you can connect a mouse to or how you can attach your HDMI-to-DisplayPort adapter. In fact, it would be very confusing if every internal connector would be available to you on the backside of your PC. It would add so much unneeded clutter and it would make things dangerous, too. Because you'd have no chance to know what all these pins and connectors are made for. The hardware manufacturers could not rely on expected conditions because anyone might have messed things up unknowingly from the outside.
Everything you as a consumer can interact with is made public with the interface of standard connectors. Everything the machine needs to work internally is kept away from you to avoid confusion about things you don't need to know about and make sure noone messes with the internal state the machine has to rely on.
So you could say "lets do everything public because I have no secrets" but in fact that would make the class very hard to understand from the outside. It would make it easy to break things unknowingly by setting members from external code which your class handles internally and has to rely on.
Another aspect we as software developers have to keep in mind: Maintainability. If you have a lot of public members, you are pretty locked when doing refactoring because you'll never know how anyone out there is using them. Keeping a clean interface to the outside is important to be able to change things internally later on.
See:
Internal applications - why not make everything public?
Why shouldn't I be using public variables in my Java class?
See Auto-Implemented Properties:
When you write code for an auto-implemented property, the Visual Basic
compiler automatically creates a private field to store the property
variable in addition to creating the associated Get and Set
procedures.
So using the shorthand notation:
Public Property Testcode As String
Results in the same code as the longer verbose property, WHEN YOU COMPILE.
There is no difference in the end.
I have the following desing in DDD
Post Aggregate with
Body: HTML of the post
Banner entity with
Html: HTML of the banner
The Banner entity belongs to Post aggregate, so I want to create a method BodyWithBanners in the Post aggregate.
The point of this method will be to search into the HTML of the Post.Body and insert the HTML of the Banner.
So far, so good.
However I have intention of reuse this functionallity in abstract: "Insert some HTML inside another HTML". So I'm creating a diffent class for doing that: BannerReplacer
Here comes the problem, how should I invoke this new class?
Just create an instance inside the Post.BodyWithBanners method (breaking Dependency Injection)
Passing the BannerReplacer in the constructor of the Post aggregate (This can be a nightmare for creating Post instances)
Passing the BannerReplacer to the BodyWithBanners method (which implies the client using Post must handle the BannerReplacer)
I have chosen for now the first option, but I don't feel really confortable with it, I believe there must be a better way of doing this.
I have chosen for now the first option, but I don't feel really comfortable with it, I believe there must be a better way of doing this.
Much of the time, the first option is fine -- so you should practice being comfortable with it. That mostly means thinking more about what dependency injection is for, and having a clear picture in your mind for whether or not those forces are at play here.
If Banner is an entity, in the domain-driven-design sense, then it is probably something analogous to an in memory state machine. It's got a data structure that it manages, and some functions for changing that data structure, or answering interesting questions about that data structure, but it doesn't have I/O, database, network etc concerns.
That in turn suggests that you can run it the same way in all contexts - you don't need a bunch of substitute implementations to make it testable. You just instantiate one and call its methods.
If it runs the same way in all contexts, then it doesn't need configurable behavior. If you don't need to be able to configure the behavior, then you don't need dependency injection (because all copies of this entity will use (copies of) the same dependencies.
When you do have a configurable behavior, then the analysis is going to need to look at scope. If you need to be able to change that behavior from one invocation to the next, then the caller is going to need to know about it. If the behavior changes less frequently than that, then you can start looking into whether "constructor injection" makes sense.
You know that you intend to use a single BannerReplacer for a given method invocation, so you can immediately start with a method that looks like:
class Banner {
void doTheThing(arg, bannerReplacer) {
/* do the bannerReplacer thing */
}
}
Note that this signature has no dependency at all on the lifetime of the bannerReplacer. More particularly, the BannerReplacer might have a longer lifetime than Banner, or a shorter one. We only care that the lifetime is longer than the doTheThing method.
class Banner {
void doTheThing(arg) {
this.doTheThing(arg, new BannerReplacer())
}
// ...
}
Here, the caller doesn't need to know about BannerReplacer at all; we'll use a new copy of the default implementation every time. Caller's that care which implementation is used can pass in their own.
class Banner {
bannerReplacer = new BannerReplacer()
void doTheThing(arg) {
this.doTheThing(arg, this.bannerReplacer)
}
// ...
}
Same idea as before; we're just using an instance of the BannerReplacer with a longer lifetime.
class Banner {
Banner() {
this(new BannerReplacer())
}
Banner(bannerReplacer) {
this.bannerReplacer = bannerReplacer;
}
void doTheThing(arg) {
this.doTheThing(arg, this.bannerReplacer)
}
// ...
}
Same idea as before, but now we are allowing the "injection" of a default implementation that can outlive the given instance of Banner.
In the long term, the comfort comes from doing the analysis to understand the requirements of the current problem, so that you can choose the appropriate tool.
We are currently designing an API for storing settings and we are considering having these two types of methods:
public Object getSetting(String key) {
// return null if key does not exist
}
public Object getSettingExc(String key) {
// throw a runtime exception if key does not exist
}
Somehow I feel that this just isn't right, but I can't think of any disadvantages except for doubling the number of functions in the API and perhaps decreased code readability (if I know the setting MUST exist, I think I should throw an exception explicitly rather than relying on the get method).
What are your opinions on this?
Exceptions are for exceptional occurrences, when the code cannot continue to function according to its advertised function.
Requesting a setting that isn't set is hardly exception-worthy. If "you" (i.e. the calling code) "know" that setting "must" exist, call getSetting(), check the return value for null, and then throw an exception yourself out of the knowledge that it should have been there. Add a meaningful message about what setting in which context wasn't found. (This is something only the caller knows.)
Don't delegate the throwing of the exception to code that doesn't know the context of the query or that the setting should be there, and needs to be told explicitly (by getting called under a different name). Also, getSettingExc() will most likely be only a null-check-and-throw wrapper around getSetting() anyway, so why not do it at a point where you can make the exception message so much more helpful?
IMHO. (And this is the point where I realize I should have voted-to-close instead of writing an answer...)
This is introducing a weird kind of coupling between the object structure and the potential error conditions. Regarding your comment:
I'm just trying to gather arguments to persuade other guys in my team.
The onus should be on the proponent of this design to justify it, not on you to justify against it. Nobody else uses this in any design I've ever seen.
This does however remind me of another design that maybe is what your team intended? Consider these two methods:
public Object getSetting(String key) {
// return the setting or throw an exception
}
public Object getSettingOrDefault(String key) {
// return the setting or a pre-determined default
}
This aligns the methods more with the functionality than with the error conditions. getSetting() can advertise that it might throw an exception, whereas getSettingOrDefault() can advertise that it will default to a specific value if none can be found in the settings.
If Java has optional parameters or something akin to that, getSettingOrDefault() might even accept as an argument a default to use in the event of no such setting. That might get a little kludgy for consuming code though, just sort of thinking out loud on that one.
Either way, the API should reflect the functionality and not the error conditions. Ideally there should be only one method, but if there's a noticeable need to differentiate between a method that throws and a method that doesn't (and I could certainly see that being the case in a language with checked exceptions), those two should align with the functionality rather than with the exception.
IMHO having two methods to do precisely the same operation indicates that you as the API designer did not complete the job of 'designing' your API. Choose one way or another, publicize it via the API (javadocs) and then the consumers will be consistent in their usage (one way or the other).
Is there a language which has a feature that can prevent a class accessing any other class, unless an instance or reference is contained?
isolated class Example {
public Integer i;
public void doSomething()
{
i = 5; // This is ok because i belongs to this class
/*
* This is forbidden because this class can only
* access anything contained within, nothing outside
*/
System.out.println("This does not work.");
}
}
[edit]An example use case might be a plugin system. I could define a plugin object with references to certain objects that class can manipulate, but nothing else is permissible. It could potentially make security concerns much easier.[/edit]
I'm not aware of any class-based access modifiers with such intent, but I believe access modifiers to be misguided anyway.
Capability-based security or, more specifically, the object-capability model seems to be what you want.
http://en.wikipedia.org/wiki/Object-capability_model
The basic idea is that in order to do anything with an object, you need to hold a reference to it. Withhold the reference and no access is possible.
Global things (such as System.out.println) and a few other things are problematic features of a language, because anyone can access them without a reference.
Languages such as E, or tools like google caja (for Javascript) allow proper object-capability models. Here an example in JS:
function Example(someObj) {
this.someObj = someObj;
this.doStuff() = function() {
this.someObj.foo(); //allowed, we have been given a reference to it
alert("foobar"); //caja may deny/proxy access to global "alert"
}
}
Any language where you must include headers would probably count: Just don't include any headers.
However, I would wager that there's no language that explicitly forbids external access. What's the point? You can't do anything if you can't access the outside world. And, why would the reference to Integer be okay, but System.out.println not be?
If you clarify the potential use-case, we can probably help you better...
Edit for your Edit:
I thought you might be going there.
If this is for security, it's flawed from the start. Let's examine:
class EvilCode {
void DoNiceThings() {
HardDrive.Format();
}
}
What incentive do I have to voluntarily place a keyword on my class? I'm certainly not going to because I'm nice, since I'm not!
One thing to consider is that any time you're loading native code that's not your own (native, in this case, means not scripted), you're potentially allowing a bad guy to run his code. No language features are going to protect you from that.
The proper answer depends on your target language. Java has Security descriptors, .NET lets you create AppDomains with restricted permissions, etc. Unfortunately, I'm not an expert in these fields.
Is there an elegant/convinient way (without creating many "empty" classes or at least they should be not annoying) to have fluent interfcaes that maintain order on compilation level.
Fluent interfaces:
http://en.wikipedia.org/wiki/Fluent_interface
with an idea to permit this compilation
var fluentConfig = new ConfigurationFluent().SetColor("blue")
.SetHeight(1)
.SetLength(2)
.SetDepth(3);
and decline this
var fluentConfig = new ConfigurationFluent().SetLength(2)
.SetColor("blue")
.SetHeight(1)
.SetDepth(3);
Each step in the chain needs to return an interface or class that only includes the methods that are valid to use after the current step. In other words, if SetColor must come first, ConfigurationFluent should only have a SetColor method. SetColor would then return an object that only has a SetHeight method, and so forth.
In reality, the return values could all be the same instance of ConfigurationFluent but cast to different interfaces explicitly implemented by that class.
I've got a set of three ways of doing this in C++ using essentially a compile time FSM to validate the actions. You can find the code on github.
The short answer is no, there is no elegant or convenient way to enforce an order of constructing a class that properly impelemnts the "Fluent Interface" as you've linked.
The longer answer starts with playing devil's advocate. If I had dependent properties (i.e. properties that required other properties to be set first), then I could implement them something like this:
method SetLength(int millimeters)
if color is null throw new ValidationException
length = millimeters
return this
end
(NOTE: the above does not map to any real language, it is just psuedocode)
So now I have exceptions to worry about. If I don't obey the rules, the fluent object will throw an exception. Now let's say I have a declaration like yours:
var config = new Fluent().SetLength(2).SetHeight(1).SetDepth(3).SetColor("blue");
When I catch the ValidationException because length depends on the color being set first, how am I as the user supposed to know what the correct order is? Even if I had each SetX method on a different line, the stacktrace will just give me the line where the config variable was declared in most languages. Furthermore, how am I supposed to keep the rules of this object straight in my head compared to other objects? It is a cocophony of conflicting ideals.
Such precedence checks violate the spirit of the "Fluent Interface" approach. That approach was designed for conveniently configure complex objects. You take the convenience out when you attempt to enforce order.
To properly and elegantly implement the fluent interface there are a couple of guidelines that are best observed to make consumers of your class thank you:
Provide meaningful default values: minimizes need to change values, and minimizes chances of creating an invalid object.
Do not perform configuration validation until explicitly asked to do so. That event can be when we use the configuration to create a new fully configured object, or when the consumer explicitly calls a Validate() method.
In any exceptions thrown, make sure the error message is clear and points out any inconsistencies.
maybe the compiler could check that methods are called in the same order as they are defined.
this could be a new feature for compilers.
Or maybe by means of annotations, something like:
class ConfigurationFluent {
#Called-before SetHeight
SetColor(..) {}
#Called-After SetColor
SetHeight(..) {}
#Called-After SetHeight
SetLength(..){ }
#Called-After SetLength
SetDepth(..) {}
}
You can implement a state machine of valid sequence of operations and on each method call the state machine and verify if the sequence of operation is allowed or throw an exception if not.
I will not suggest this approach for Configurations though, it can get very messy and not readable