![]() The best way, though, is to not expose the member in any way at all and instead bring the behavior that manipulates the member inside the class. Another way is to have an immutable member. One way to guard against this is to return a copy instead. In Java at least, returning a reference type from a getter provides that reference to the caller and now it can be manipulated by the caller in unexpected ways. If you only have a getter, things can be just as bad. ![]() A little piece of code that ran on a schedule happened to be updated recent to this fiasco that changed the underlying value that determined site headers and languages by calling this setter. The culprit was a setter method deep in the guts of a shared platform that all these different sites were using. Then (bam!) all of a sudden something would happen that made the whole thing go sideways. The operations team was frantically restarting hundreds of servers around the globe because for the first half-hour or so that these servers ran, things functioned normally. One day this friend came into work, and found that dozens of well-known web sites in countries around the world all had the header and navigation of the parent corporation's main web site (not their own), and were using British English. Getters and setters can actually be dangerous Have you ever noticed how most languages have a Dictionary data structure but it's called Map in Java? Dictionary actually was an interface that was introduced in JDK 1.0, but it had problems and ultimately had to be replaced by Map. Things like this are the reason why famous libraries have terrible legacy classes. It would have been better just to have behavior methods like fillUp(Fuel fuel). What if we want a hydrogen-fuelled car? We have to throw out this whole Car class now. Now this code is brittle and hard to change. That's really bad and this is why getters and setters expose implementation / violate encapsulation. If you assume that this is a gas-powered car that internally tracks gasoline in liters, then you are going to be right 99.999% of the time. One supposed advantage of getters and setters is that on the off-chance that the type of a class member needs to change, the change can be limited to inside the class by making the existing getter simply translate from the internal type to the previously-exposed type. ![]() Getters and setters are a fake insurance policy of isolated change The following are some of the disadvantages of public getters and setters that directly expose a single private member, have the same name, and provide no other functionality. Which-I'm sorry-I personally think is funny since there's literally the same (non-existent) protections around both of these things. Yet for some reason we breathe a sigh of relief when we see Car2.java. We see that public member sitting there and we say, not safe! Engine is not protected by anything! Anyone can do anything! Aaaaaaaaagggghhhhh! This is important because we've been taught to get squeamish when we see Car1.java. The point here is that anything I can do with Car2.java, I can do with Car1.java, and vice-versa. Enter fullscreen mode Exit fullscreen mode
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |