Whenever a tutorial first introduces accessors, they always start off with a public variable initialized in the class or object. There is then a method to print that public value. Then they make it private to show that it is hidden to outside users.
For example:
int _dayOfWeek;
public int dayOfWeek
{
get
{
return _dayOfWeek;
}
set
{
if (value > 0 && value < 8) _dayOfWeek = value;
}
}
What's stopping hackers from just using these accessors to get and change your values?
Encapsulation doesn't help against hackers. It helps against mistaken use of your code. See the wiki article for more information on the uses of encapsulation.
By making your private data accessible to programmers who use your code it is very hard to make sure that they use it properly. If you control all access to your data then you can ensure that it is indeed used as you intended it to be used.
Providing accessors to your private data is usually a code smell that indicates improper encapsulation. It is only slightly better than exposing your data. You want to expose to the users functionality and not raw data.
Related
I am designing a process that should be run daily at work, and I've written a class to do the work. It looks something like this:
class LeadReport {
public $posts = array();
public $fields = array();
protected _getPost() {
// get posts of a certain type
// set them to the property $this->posts
}
protected _getFields() {
// use $this->posts to get fields
// set $this->fields
}
protected _writeCsv() {
// use the properties to write a csv
}
protected _sendMail() {
// attach a csv and send it
}
public function main() {
$this->out('Lead Report');
$this->out("Getting Yesterday's Posts...");
$this->_getPosts();
$this->out("Done.");
$this->out("Next, Parsing the Fields...");
$this->_getFields();
$this->out("Done.");
$this->out("Next, Writing the CSVs...");
$this->_writeCsv();
$this->out("Done.");
$this->out("Finally, Sending Mail");
$this->_sendMail();
$this->out('Bye!');
}
}
After showing this code to one of my colleagues, he commented that the _get() methods should have return values, and that the _write() and _sendMail() methods should use those values as parameters.
So, two questions:
1) Which is "correct" in this case (properties or return values)?
2) Is there a general rule or principle that governs when to use properties over when to use return values in object oriented programming?
I think maybe the source of your question comes from the fact that you are not entirely convinced that using properties is better than having public fields. For example here, common practice says that should not have posts and fields as public. You should use the getField method or a Field protected property to regulate access to those fields. Having a protected getField and a public fields doesn't really make sense.
In this case your colleague may be pointing at two things. The fact that you need to use Properties and not public fields and also the fact that it is probably better to pass the post into the method and not have the method access a property if you can. That way you don't have to set a property before calling the method. Think of it as a way of documenting what the method needs for it to operate. In this way another developer doesn't need to know which properties need to be set for the method to work. Everything the method needs should be passed in.
Regarding why we need properties in the first place? why shouldn't you use public fields. Isn't it more convenient? It sure is. The reason we use properties and not public fields is that just like most other concepts in OOP, you want your object to hide its details from the outside world and just project well defined interfaces of its state. Why? Ultimately to hide implementation details and keep internal change to ripple out(Encapsulation). Also, accessing properties has the added benefit of debugging. You can simply set a breakpoint in a property to see when a variable is changed or simply do a check if the variable is of certain value. Instead of littering your code with said check all over the place. There are many more goodies that come with this, returning readonly values, access control, etc.
To sum up, fields are though of as internal state. Properties(actual get/set methods) are though of as methods that interact with internal state. Having an outside object interact with interfaces is smiley face. Having outside class interact with internal state directly is frowny face.
This may not be the best kind of question suited to stackoverflow, but I'm only after an answer that best describes why programmers sometimes don't use setters/getters for properties, e.g. in the case of property injection (DI).
Consider this example...
class Test
{
public propertyA;
protected propertyB;
public function setPropertyB(val)
{
// do some logic to validate 'val'
this.propertyB = val;
}
public function getPropertyB()
{
return this.propertyB;
}
}
Why would you choose the style of directly setting propertyA:
var Test = new Test();
Test.propertyA = 1;
Over the setter option for propertyB:
var Test = new Test();
Test.setPropertyB(1);
I always use the setter/getter approach, but I have seen some pretty established frameworks using the propertyA approach interspersed with the propertyB approach. What benefits do we have using this method?
Why you might not care about encapsulation:
You might be throwing away the project 15 minutes later.
You might have found getters/setters to be bottlenecks for your CPU-bound code, causing you to optimize for performance instead of design.
The instance field might be immutable and read-only, so there might be no danger in exposing it.
You're too lazy to write getters/setters.
You should use getters and setters because they allow you to control the interface to your objects.
For example, let's say I have a bank account class in a Java application:
class BankAccount {
private int balance;
BankAccount() {
balance = 0;
}
public void deposit(int amount) {
balance = balance + amount;
}
public void withdraw(int amount) {
balance = balance - amount;
}
}
When my software needs to alter a bank account's balance through deposits and withdrawals, it calls the appropriate methods.
Now, along comes some sneaky individual who manages to figure out that they can increase their bank balance by telling their internet banking software to withdraw negative amounts of money. I can fix this bug by adding a precondition to the withdraw method, and the bug goes away.
If the balance field was instead public, and a whole bunch of classes were just manipulating it's value arbitrarily, those classes would now need to be changed. If some of those external classes were written by third parties, then we're looking at a whole lot of pain to get the bug fixed.
Why would you use public fields? In the general case, you probably shouldn't. Some languages allow you to have a field scoped as public, then if you need to add a getter/setter later on you can do so without changing your object's interface (I believe C# does this, but correct me if I'm wrong).
Today I read a book and the author wrote that in a well-designed class the only way to access attributes is through one of that class methods. Is it a widely accepted thought? Why is it so important to encapsulate the attributes? What could be the consequences of not doing it? I read somewhere earlier that this improves security or something like that. Any example in PHP or Java would be very helpful.
Is it a widely accepted thought?
In the object-oriented world, yes.
Why is it so important to encapsulate the attributes? What could be the consequences of not doing it?
Objects are intended to be cohesive entities containing data and behavior that other objects can access in a controlled way through a public interface. If an class does not encapsulate its data and behavior, it no longer has control over the data being accessed and cannot fulfill its contracts with other objects implied by the public interface.
One of the big problems with this is that if a class has to change internally, the public interface shouldn't have to change. That way it doesn't break any code and other classes can continue using it as before.
Any example in PHP or Java would be very helpful.
Here's a Java example:
public class MyClass {
// Should not be < 0
public int importantValue;
...
public void setImportantValue(int newValue) {
if (newValue < 0) {
throw new IllegalArgumentException("value cannot be < 0");
}
}
...
}
The problem here is that because I haven't encapsulated importantValue by making it private rather than public, anyone can come along and circumvent the check I put in the setter to prevent the object from having an invalid state. importantValue should never be less than 0, but the lack of encapsulation makes it impossible to prevent it from being so.
What could be the consequences of not
doing it?
The whole idea behind encapsulation is that all knowledge of anything related to the class (other than its interface) is within the class itself. For example, allowing direct access to attributes puts the onus of making sure any assignments are valid on the code doing the assigning. If the definition of what's valid changes, you have to go through and audit everything using the class to make sure they conform. Encapsulating the rule in a "setter" method means you only have to change it in one place, and any caller trying anything funny can get an exception thrown at it in return. There are lots of other things you might want to do when an attribute changes, and a setter is the place to do it.
Whether or not allowing direct access for attributes that don't have any rules to bind them (e.g., anything that fits in an integer is okay) is good practice is debatable. I suppose that using getters and setters is a good idea for the sake of consistency, i.e., you always know that you can call setFoo() to alter the foo attribute without having to look up whether or not you can do it directly. They also allow you to future-proof your class so that if you have additional code to execute, the place to put it is already there.
Personally, I think having to use getters and setters is clumsy-looking. I'd much rather write x.foo = 34 than x.setFoo(34) and look forward to the day when some language comes up with the equivalent of database triggers for members that allow you to define code that fires before, after or instead of a assignments.
Opinions on how "good OOD" is achieved are dime a dozen, and also very experienced programmers and designers tend to disagree about design choices and philosophies. This could be a flame-war starter, if you ask people across a wide varieties of language background and paradigms.
And yes, in theory are theory and practice the same, so language choice shouldn't influence high level design very much. But in practice they do, and good and bad things happen because of that.
Let me add this:
It depends. Encapsulation (in a supporting language) gives you some control over how you classes are used, so you can tell people: this is the API, and you have to use this. In other languages (e.g. python) the difference between official API and informal (subject to change) interfaces is by naming convention only (after all, we're all consenting adults here)
Encapsulation is not a security feature.
Another thought to ponder
Encapsulation with accessors also provides much better maintainability in the future. In Feanor's answer above, it works great to enforce security checks (assuming your instvar is private), but it can have much further reaching benifits.
Consider the following scenario:
1) you complete your application, and distribute it to some set of users (internal, external, whatever).
2) BigCustomerA approaches your team and wants an audit trail added to the product.
If everyone is using the accessor methods in their code, this becomes almost trivial to implement. Something like so:
MyAPI Version 1.0
public class MyClass {
private int importantValue;
...
public void setImportantValue(int newValue) {
if (newValue < 0) {
throw new IllegalArgumentException("value cannot be < 0");
}
importantValue = newValue;
}
...
}
MyAPI V1.1 (now with audit trails)
public class MyClass {
private int importantValue;
...
public void setImportantValue(int newValue) {
if (newValue < 0) {
throw new IllegalArgumentException("value cannot be < 0");
}
this.addAuditTrail("importantValue", importantValue, newValue);
importantValue = newValue;
}
...
}
Existing users of the API make no changes to their code and the new feature (audit trail) is now available.
Without encapsulation using accessors your faced with a huge migration effort.
When coding for the first time, it will seem like a lot of work. Its much faster to type: class.varName = something vs class.setVarName(something); but if everyone took the easy way out, getting paid for BigCustomerA's feature request would be a huge effort.
In Object Oriente Programming there is a principle that is known as (http://en.wikipedia.org/wiki/Open/closed_principle):
POC --> Principle of Open and Closed. This principle stays for: a well class design should be opened for extensibility (inheritance) but closed for modification of internal members (encapsulation). It means that you could not be able to modify the state of an object without taking care about it.
So, new languages only modify internal variables (fields) through properties (getters and setters methods in C++ or Java). In C# properties compile to methods in MSIL.
C#:
int _myproperty = 0;
public int MyProperty
{
get { return _myproperty; }
set { if (_someVarieble = someConstantValue) { _myproperty = value; } else { _myproperty = _someOtherValue; } }
}
C++/Java:
int _myproperty = 0;
public void setMyProperty(int value)
{
if (value = someConstantValue) { _myproperty = value; } else { _myproperty = _someOtherValue; }
}
public int getMyProperty()
{
return _myproperty;
}
Take theses ideas (from Head First C#):
Think about ways the fields can misused. What can go wrong if they're not set properly.
Is everything in your class public? Spend some time thinking about encapsulation.
What fields require processing or calculation? They are prime candidates.
Only make fields and methods public if you need to. If you don't have a reason to declare something public, don't.
When inside a class you have a private fiels and expose that field on a public property, which one should I use from inside the class?
Below you is an example on what I am trying to find out.
Should manioulate the Private Field _Counter or the Property Counter?
Public Class Test
Private _Counter As Integer
Public Property Counter() As Integer
Get
Return _Counter
End Get
Set(ByVal value As Integer)
_Counter = value
End Set
End Property
Private Sub Dosomething()
'What is the best practice?
'Direct access to private field or property?
'On SET
_Counter += 1
'OR
Me.Counter += 1
'On Get
Console.WriteLine(_Counter)
Console.WriteLine(Me.Counter)
End Sub
End Class
Thanks in advance for the help.
Edu
IMO you should be using the Property accessor whenever possible. This is because you don't have to worry about any internal logic that might be available when you have an a property.
A good example of where this happens is in the code behind in a Linq DataContext.
check this out...
[Column(Storage="_ReviewType", DbType="TinyInt NOT NULL")]
public byte ReviewType
{
get
{
return this._ReviewType;
}
set
{
if ((this._ReviewType != value))
{
this.OnReviewTypeChanging(value);
this.SendPropertyChanging();
this._ReviewType = value;
this.SendPropertyChanged("ReviewType");
this.OnReviewTypeChanged();
}
}
}
Notice all that logic in the 'setter'?
This is why it's important to start getting into the practice of calling your Properties instead of fields, IMO.
Thank you all for the answers and suggestions.
After considering all the suggestions here plus other researches it is my impression that for this situation on Private Field versus Assessor it is more of a personal choice. So basically the most important is that no matter what you choose be consistent.
That said; my personal rule is leaning towards this:
Access your private fields directly.
If accessing accessors use the keyword ME. to improve readability
Use the accessor only if it implements vital logic logic that also applies to private access. This way you know that if you are using the accessor it is because there is "something else to it"
Avoid using Protected Fields. Derived classes should always use the accessor, never direct access to the field.
Let me know what you think.
SideNote:
After this I think we are missing a new scope for the class level fields. A keyword like “Restricted” where this field could only be accessed from its getter/setter. This way you always access directly the private fields, but if you need to make sure certain field can only be accessed by its accessor that you change the Private to Restricted. (how about "Restricted , RestrictedRead and RestrictedWrite"?)
In my opinion, using a public accessor internally is over-encapsulation: it blurs the code. With such an approach, otherwise simple operations invoke accessors that may contain more complex logic, so it's harder to analyze the code of the operations.
In my programming experience, I've rarely had a situation when it would help much. Instead, I prefer to access fields directly, and only if it's really needed, to abstract the access by creating a private accessor, which can be used by both the public accessor and other functions. The rationale is that if you need to attach some special logic in the public accessor, chances are that the logic may not be the same for internal access.
Note also that most modern IDEs (like Eclipse) allow to see immediately all references to a private field, and to refactor the code to use a function instead of a direct access.
I always use the property accessors, because the I am safe in case I add logic in the getter or setter in the future, knowing for sure that no code bypasses it.
I prefer to use the property whenever possible. This gives you the flexibility in the future to modify what the property returns/sets without having to go through and find all the locations that were using the private variable.
Use the private field because you are not doing something in specific in the setter.
I would also recommend to remove the property-setter, this way you force the state of the counter to be set by the given method DoSomething()
Depending on the situation, it may be preferable to allow the direct modification of a field on a class only privately, and or through some method which associates semantics with the modification. This way it becomes easier to reason about this class and that particular value, since you can be certain that its modified only in a certain way. Moreover, at some point, an action such as incrementing and int may have additional required consequences at which point it makes more sense to expose access to it through methods.
If you are worried about the performance overhead of calling property accessors when they just go directly to the field, don't. Most compilers will inline this sort of thing, giving you effectively the same performance. At least, you're pretty unlikely to need the extra nanoseconds of time you might gain by going directly to the field.
It's better to stick with property accessors because a) you can be very consistent in all of your code which makes it more maintainble and b) you get the benefits pointed out by others here.
Also, I don't usually add the Me. (or this.) keywords, unless there's a scope problem (which I try to avoid by choosing my identifiers carefully). I don't get confused by this because my functions and subs are never so long that I'm not sure whether I am working with a local (stack-based) variable or a member of the class. When they get too long to tell easily, I refactor.
Original poster is EXACTLY correct.
1) Access your private fields directly.
Makes refactoring easier.
2) If accessing accessors use the keyword ME. to improve readability
explicitly listing scope requires less thinking by reader
3) Use the accessor only if it implements vital logic logic that also applies to private access. This way you know that if you are using the accessor it is because there is “something else to it”
this is the only reason to violate rule #1.
4) Avoid using Protected Fields. Derived classes should always use the accessor, never direct access to the field.
This is a general OOP question although I am designing in Java. I'm not trying to solve a particular problem, just to think through some design principles.
From my experience I have reached the habit segregating object setup into three phases.
The goal is to minimize: extra work, obfuscated code and crippled extensibility.
Construction
The minimal actions necessary to
create a valid Object, passes an
existence test
Instantiate and initialize only "one time", never to be over-ridden, non variable objects that will not change/vary for the life of the Object
Initialize final members
Essentially a runtime stub
Initialization
Make the Object useful
Instantiate and initialize publicly accessible members
Instantiate and initialize private members that are variable values
Object should now pass external tests with out generating exceptions (assuming code is correct)
Reset
Does not instantiate anything
Assigns default values to all variable public/private members
returns the Object to an exact state
A Toy example:
public class TestObject {
private int priv_a;
private final int priv_b;
private static int priv_c;
private static final int priv_d = 4;
private Integer priv_aI;
private final Integer priv_bI;
private static Integer priv_cI;
private static final Integer priv_dI = 4;
public int pub_a;
public final int pub_b;
public static int pub_c;
public static final int pub_d = 4;
public Integer pub_aI;
public final Integer pub_bI;
public static Integer pub_cI;
public static final Integer pub_dI = 4;
TestObject(){
priv_b = 2;
priv_bI = new Integer(2);
pub_b = 2;
pub_bI = new Integer(2);
}
public void init() {
priv_a = 1;
priv_c = 3;
priv_aI = new Integer(1);
priv_cI = new Integer(3);
pub_a = 1;
pub_c = 3;
pub_aI = new Integer(1);
pub_cI = new Integer(3);
}
public void reset() {
priv_a = 1;
priv_c = 3;
priv_aI = 1;
priv_cI = 3;
pub_a = 1;
pub_c = 3;
pub_aI = 1;
pub_cI = 3;
}
}
I would design my classes in a way so that an "init" method is not required. I think that all methods of a class, and especially public methods, should guarantee that the object is always left in a "valid" state after they complete successfully and no call to other methods is required.
The same holds for constructors. When an object is created, it should be considered initialized and ready to be used (this is what constructors are for and there are numerous tricks to achieve this). Otherwise, the only way that you can safely use it is checking if the object has been initialized in the beginning of every other public method.
I come from a C++ background where the rules are a bit different from Java, but I think these two-stage initialization principles apply in the general case.
Construction
Everything that can be done at construction time should be done at construction time.
Minimize the amount of "badness" that can result from trying to use your object before calling init().
All member variables need a value, even if it's a normally invalid sentry value (e.g., set pointers to null). I think Java will initialize all variables to zero by default, so you need to pick something else if that's a valid number.
Initialization
Initialize those member variables that depend on the existence of other objects. Basically, do the things you couldn't do at construction time.
Ensure your object is now in a complete, ready-to-use state. Consider throwing an exception if it isn't.
Reset
Think long and hard about what state The System will be in when you'd want to call such a function. It may be better to create a new object from scratch, even if that operation seems expensive. Profile your code to find out if that's a problem.
Assuming you got past item 1, consider writing a method to handle the things that both reset() and your constructor need to do. This eases maintenance and avoids code duplication.
Return your object to the same state it was in after init().
Can't say that I've ever used this exact pattern, but I've used similar things to reduce code duplication. For example when you have an object that may be either created via a constructor or from a another object (like a DTO) via a factory method. In that case, I'll often have an internal initializer that populates the properties of the object that is used by both. Can't say that I've ever used a "reset" method, nor do I see a real need for one if all it does is replicate the process of creating a new object.
Lately, I've moved to only using default constructors and using property settors to initialize the object. The new C# syntax that allows to easily do this in a "constructor-like" format makes this every easy to use and I find the need to support parameterized constructors disappearing.
Is there a reason init() and reset() need to be different? It's hard to see in this simple example why the "does not instantiate anything" rule is important.
Beyond that, I think objects should be useful as soon as they're constructed. If there's a reason -- some circular dependency or inheritance issue -- an object has to be "initialized" after construction, I would hide the constructor and the initialization behind a static factory method. (And probably move the initialization code to a separate configurator object for good measure.)
Otherwise you're counting on callers always to call both the constructor and init(), and that's a non-standard pattern. We have some old, too-useful-to-throw-away code here that does that; it's an abstract dialog class, and what happens is, every time someone extends it, they forget to call constructUI() and then they waste 15 minutes wondering why their new dialog is empty.
Interesting. I especially find this construction useful if you have an object that needs to perform IO operations. I do not want anything to perform IO operations direct or indirectly in their constructor. It makes the object a nightmare to use.