Hot answers tagged

21

Simply exposing fields – whether as public fields, properties, or accessor methods – can be an indicator of insufficient object modelling. The result is that we ask an object for various data and make decisions on that data. So these decisions will be made outside of the object. If this happens repeatedly, maybe that decision should be the responsibility of ...


17

I think you are missing the point. Its not saying you should rename the setter and getter, but to have methods which add and remove items from the fridge. ie public class Fridge { private int numberOfCheeseSlices; public void AddCheeseSlices(int n) { if(n < 0) { throw new Exception("you cant add negative cheese!"); ...


13

Getters Getters turn an object inside out. They say give this data to everyone. I'm just a place to store info. If you want something done about this stuff you have to do it. Encapsulation Rather then give up your state to anything that asks it's better to hide it. Anything that needs to be done with that state is better done by methods of the class that ...


11

So I did some googling. Here is the rule you quote: To respect OO encapsulation concepts, private fields should always be accessed through accessors https://www.appmarq.com/public/changeability,4576,Provide-accessors-to-Private-Fields Its remediation: Write a getter and setter to each private field And a reference. Presumably for justification: ...


8

I see such code often, and I do not like it. My colleagues often use that for injecting some dependencies into an instance. But by doing so, they open up that property for change some when later on, while the property is expected to be set during object creation only. And that's the reason why I do not like it: you cannot be sure that the public setter ...


7

Firstly, you have to consider why we encapsulate state. This stock answer is fairly typical: Encapsulation makes it possible to separate an objects implementation from its behavior to restrict access to its internal data. This restriction allows certain details of an object's behavior to be hidden. It allows us to create a “black box” and protects an ...


7

No, you don't seem to have missed anything. That audit sounds misguided, among other things it implies immutable objects, like String, are "against OO encapsulation concepts".


6

Generally, the point of OOP is that you don't need access to the attribute. Think about what you want to do with the attribute - whatever that is, should potentially be a method of the class, so you should call that method to do it, instead of getting the attribute value and doing it yourself. There are exceptions, of course, but if all your 'classes' are ...


5

Getters and setters break encapsulation every single time, by definition. What might be argued is that sometimes we need to do that. With that out of the way, here are my answers: How is encapsulation preserved by renaming it from get/set to putCheese()/takeCheese() You're obviously getting/setting a value, so why not simply leave it as get/set? The ...


5

A class should encapsulate its state, which means abstracting over it. In the first example, your members might as well be public, since returning references lets the user do absolutely anything with them anyway. The second is harder to decide. The theoretical nature of your example means that I still don't like it; the names are meaningless, and I can't ...


4

Is your class a dumb bag of containers? Then give direct access to them! Is your class maintaining complex internal state in containers? Then you probably don't want to expose that internal state to damage from outside (especially if that vector and map are somehow in sync with each other). tl;dr it depends what you're trying to achieve. "Things in a class"...


4

Restricting write access to an internal variable but granting read access does not preserve encapsulation, as external code can then depend on the objects internal state just as much as any of its methods would. Having getters for all of a class's member variables should be a warning sign that something is wrong. Instead, you should have something like a ...


4

The reason you have never seen this before is not because such code would cause any immediate problems. The reason is probably: this combination is not particular useful. Code which makes setters public allows calling code to change the object's state, then the calling code "knows" already the content of what was passed into through the setter, and there is ...


4

When are getters acceptable? When you are dealing with a collection. Collections are typically not aware of their contents beyond their address in memory. This not knowing makes them data structures more than traditional objects. I never bemoan them having getters and setters. It's nice to have a place to set a break point. If you want to follow Tell, don'...


3

Almost all of this shows a fundamental misunderstanding of encapsulation, and how it applies. The initial response that you were breaking encapsulation is just wrong. Your application may have a need to simply set the value of cheese in the fridge instead of increment/decrement or add/remove. Also, it is not semantics, no matter what you call it, if you ...


3

Short answer: NO Long answer: You are misusing the Getter. You have Setters & Getters to encapsulate data, i.e. prevent direct access to the member variables. In your Setter, you might e.g. check that you actually set some kind of water (hot/cold/soapy). If you abuse the Getter to Set data you circumvent that. Also, it runs contrary to the expected use ...


3

It is not an inherently bad design, but like any powerful feature it can be abused. The point of properties (implicit getter and setter methods) is that they provide a powerful syntactic abstraction allowing consuming code to treat them logically as fields while retaining control for the object that defines them. While this is often thought of in terms of ...


3

Ideally, you should avoid having getters or setters altogether. The fundamental tenet of OO is behavioral abstraction, your objects should do stuff, not just "store" stuff. If you absolutely must have getters and setters, the best thing to do would be to actually stick to standard Ruby conventions: def content_type=(content_type_uid) @content_type = ...


3

I like the C#/Ruby/Python/etc. terminology of Properties. I think this helps disambiguate the concept a bit. In C# properties are a nice way to write formalized setters and getters. In Java properties are a matter of convention (i.e. JavaBeans with the set/get pair sharing the same name). Properties are exposed logical values that you intend for other ...


2

The answer to this question might be in the answer to What is an Anti-Corruption layer, and how is it used?. A quote of a quote from the accepted answer: Above example is based on how Anticorruption Layer is explained at c2 wiki: If your application needs to deal with a database or another application whose model is undesirable or inapplicable ...


2

The most primitive definition is that the getter is a method that retrieves a value, and a setter is a method that modifies a value. There is no requirement that the value be backed by a field or even stored in the implementing object. For .net specifically, there are a set of guidelines to follow that ensure properties (getters and setters in .net) behave ...


2

Adding getters and setters reflexively (that is, without thought, not to be confused with doing it reflectively as per the question you link) is a sign of problems. First of all, if you have passthrough getters and setters for fields, why not just makes the fields public? For example: class Foo { private int _i; public int getData() { return _i; } ...


2

Might I suggest first and foremost, not doing bulk rewrites of the entire source tree. :) That aside, there are pros and cons to using constants and accessors. Using constants often allows data to be available to Java at compile time instead of just run time (of course it depends on what the data type is, and how you set that data). This will likely be ...


2

The names you give to program entities shows what you think about them, and that doesn't seem to be straight (if I understand your description correctly): Instances of Human represent human beings, and that's good. A method getHealth() returning a list of lifeCurrent and lifeMax implies that a "health" is a pair of lifeCurrent and lifeMax. That's strange. ...


2

While there are few hard and fast rules in software design and development, there's a school of thought that mutators/getters/setters for every attribute of a class are an anti-pattern or at least not a good practice for OOP. At least in some measure, the widespread use of getters/setters seems to have been heavily influenced by JavaBeans, which are not ...


1

It's not just renaming a method. The two methods function differently. (Picture this in your mind) get_cheese and set_cheese exposes the cheese. putCheese() and takeCheese() keeps the cheese hidden and takes care of managing it and give the user a way to handle it. The observer doesn't see the cheese, he/she only sees two methods of manipulating it.


1

Short answer is no. As soon you define any method that returns an instance variable in any form for the sole purpose of having that information on the other side, you are smearing responsibilities all over your application, violating encapsulation and all sorts of other things. Now the question becomes: Do you have a reason to invite all those bad things? ...


1

Do all of these mutable properties need to be mutable? I suspect not, having worked on solvers myself. Take the "configuration" mutable properties, and turn them into immutable fields in your class. Initialize them using a constructor. This leads to... Stop using an interface if you can use a base class instead. This will enable your to use constructors to ...


1

My question is for those developers that agree that getters/setters break encapsulation and should be avoided. Consider Wikipedia's description of Encapsulation: A language mechanism for restricting direct access to some of the object's components. A language construct that facilitates the bundling of data with the methods (or other functions) ...


1

(A) They provide read or write access to a specific attribute. (B) They allow hiding the internal representation of data inside a class while still being able to access and modify it. Because you access the attribute via a method they technically do both. If you changed the internal representation of the attribute this change can be hidden to code ...


Only top voted, non community-wiki answers of a minimum length are eligible