I tried googling and searching for this question but somehow couldn't find anything relevant about it. I'm wondering if there is a bbest-practise guide on when to use attributes in a class and when not, but rather use parameters to the single methods.
Many cases are clear to me, e.g.
public class Dog
{
private name;
public setName(...) {....}
}
But sometimes it's not clear to me what's better to use.
E.g. the following, either use:
public class calculation
XYZ bla;
public calculation(XYZ something)
{
this.bla = something;
}
public void calc1()
{
// some calculations with this.bla
}
public void calc1()
{
// some more calculations with this.bla
}
public XYZ getBla()
{
return this.bla;
}
}
or maybe do:
public class calculation
public calculation() {}
public static XYZ calc1(XYZ bla) // maybe static, if not dependant on other attributes/instance-variables etc
{
// some calculations with bla
return bla;
}
public static XYZ calc1() // maybe static, if not dependant on other attributes/instance-variables etc
{
// some more calculations with bla
return bla;
}
}
I mean you can argue for both cases. I see advantages and maybe disadvantages for both different styles, but somehow I prefer the second one as far as long as there are not too many arguments/parameters needed. Sure, if I need many many more attributes etc., then the first one will be better, simpler etc. because I dont need to pass so many parameters to the method...
Just a question of personal style?
Or how to decide for one approach?
Thanks
EDIT: A better example: I'm curently doing much image processing and the question would be wether to store the image internally in the state of the object or not. I'm currently NOT doing it because I'm using static methods, and psasing the image itself I to each method:
public class ImageProcessing
{
/**
*
*/
public static Mat cannyEdges(Mat I, int low, int high)
{
// ...
return I;
}
public static Mat cannyEdges(Mat I)
{
return ImageProcessing.cannyEdges(I, ContourDetection.CANNY_LOWTHRES, ContourDetection.CANNY_HIGHTHRES);
}
/**
*
*/
public static Mat getHoughLines(Mat Edges, ...some_conf_vars...)
{
// ...
return I;
}
}
and then I'm calling it from the outside like this e.g.:
// here: read image to I...
Mat edges = ImageProcessing.cannyEdges(I, 20, 100);
Mat lines = ImageProcessing.getHoughLines(I);
// draw lines...
question is: Does I belong to the state of the object? Would it make sense to convert to non-static and then use for example:
// here: read image to I...
ImageProcessing IP = new ImageProcessing(I);
IP.cannyEdges(20, 100); // CHANGE OF cannyEdges: Also save `edges` internally as property!?
IP.calcHoughLines(); // also save the lines internally maybe?
Mat lines = IP.getLines();
// draw lines...
is this nicer?
The question arising is then again: Should I for example store the result of getHoughLines() (i.e. the lines) internally or should I directly return it to the caller!?
I can use some examples:
public class Multiplier {
private int number;
public Multiplier(int number) {
this.number = number;
}
public int multiply(int other) {
return number * other;
}
}
This class could be instantiated like:
Multiplier multiplyByTwo = new Multiplier(2);
I could use it to multiply many elements on a list by 2.
But I could need to multiply pairs of numbers. So the following class could be what I neeed:
public class Multiplier {
public static int multiply(int number, int other) {
return number * other;
}
}
I could make it static since no state is needed.
This example could be used like this on a list:
for (int x:listOfInts) {
print(Multiplier.multiply(x * 2));
}
But probably in this specific case the 1st example was nicer.
for (int x:listOfInts) {
print(multiplyByTwo(x));
}
or even nicer used with a Java 8 ''map''
If I need to get the elements of the multiplication and the result at many points in my code i could do.
class Multiplier {
private int x;
private int y;
public int multiply() {
return x * y;
}
// getters and setters for x and y
}
In this last case I may consider not adding setters and pass x, y in the constructor.
Every structure could be used in some specific cases.
It's not entirely a question of personal style. But nevertheless, I assume that this topic might be slightly controversial (opinion-based) and thus not perfectly suited for a Q/A-site.
However, the obvious question is: Does an object of the respective class really carry a state? That is, is there any benefit in having the state represented by an instance? If the sole purpose of the instance is to be an accumulator of variables that are modified with a sequence of set... calls and a final call to an execute() method, then there is usually no real justification for such an instance - except for avoiding to have a static method with "many" parameters.
I think that the advantages of static methods outweigh most of the potential clumsiness of calling a method with "many" parameters. One of the most important ones is probably that the approach with static methods doesn't increase the state space. Every field is another dimension in the state space, and documenting state space properly can be hard. Static methods enforce a more "functional" programming style: They don't have any side-effects, and thus, are thread-safe (which is becoming increasingly important).
(Note: All this refers to static methods that are not related to any static state - that should be avoided anyhow. And of course, this refers to methods that are not involved in or aiming at anything related to polymorphism).
And after all, one can easily call any static method from anywhere - even from within an instance method, and pass in some fields as parameters. The opposite is not so easy: When you want to call a method that depends on many instance fields, it can be a hassle when you first have to create an object and set the fields appropriately (still not knowing whether it is in a valid state to call the method). I also see the default methods of Java 8 as a nice application case where static utility methods come in handy: The default method may easily delegate to the utility method, because no state is involved.
There are a few reasons I'd go with the first option, i.e. an object with state over static functions, particularly for complex calculations but also for simpler ones.
Objects work better for the command pattern.
Objects work better for the strategy pattern.
Static methods can turn unit tests into a nightmare.
Static is an anti-pattern in OOP because it breaks polymorphism, with the side-effect that related techniques will break with it, e.g. open/closed, mocking, proxies, etc.
That's my 2c at least.
The weird part of your first example is that those calcX methods don't say anything about idempotency, so it's unclear what this.bla is when it's being manipulated. For complex computations with optional settings, an alternative is to construct an immutable object using a builder pattern, and then offer calcX methods that return the result based on fixed object state and parameters. But the applicability of that really depends on the use case, so YMMV.
Update: With your new code, a more OOP approach would be to decorate Mat. Favouring delegation over inheritance, you'd get something like
public class MyMat
{
private Mat i;
public MyMat(Mat i) {
this.i = i;
}
public Mat getBackingMat() {
return this.i;
}
public MyMat cannyEdges(int low, int high)
{
// ...
return new MyMat(I); // lets you chain operations
}
public MyMat cannyEdges()
{
return new MyMat(ImageProcessing.cannyEdges(I, ContourDetection.CANNY_LOWTHRES, ContourDetection.CANNY_HIGHTHRES));
}
public MyMat getHoughLines(...some_conf_vars...)
{
// ...
}
}
MyMat myMat = new MyMat(I);
lines = myMat.cannyEdges(20, 100).calcHoughLines();
This is just a guess, cause I have no idea what those things mean. :)
When not to use static:
If the result that will be returned is dependent on other variables (state) that make up your "calculation" class then static cannot be used.
However, if you are simply doing calculations on a variable, as the example implies, static is probably the way to go as it requires less code (For example to perform calc1 and then calc2 on a variable by the first method you would have to do:
calculation calc = new calculation(x)
calc.calc1();
calc.calc2();
XYZ y = calc.getBla();
while with the second example you could do
static import ...calculation.*;
...
XYZ y = calc2(calc1(x));
Related
As you can see, I've created (instantiated?) a static array of Corner objects in the object Corner. Is this good form? I want all the Corner object to have access to all the other Corner objects.
package Main;
public class Corner {
private String biome;
private static Corner[][] corners;
private float elevation, moisture, heat;
private boolean isRiver, isLake;
private int x, y;
public void createArray(int width, int height) {
corners = new Corner[width][height];
}
public String getBiome() { return biome; }
public void setBiome(String biome) {
this.biome = biome;
}
public float getElevation() { return elevation; }
public void setElevation(float elevation) {
this.elevation = elevation;
}
public float getMoisture() {
return moisture;
}
public void setMoisture(float moisture) {
this.moisture = moisture;
}
public float getHeat() { return heat; }
public void setHeat(float heat) { this.heat = heat; }
public boolean isRiver() {
return false;
}
public boolean isLake() {
return false;
}
public static Corner[][] getCorners() {
return corners;
}
}
There are no more details to add.
If the amount of Corners changes you need to create a new bigger array and copy all the Corners from the old array to the new bigger one. This should indicate to you that you might want to ave a different data structure than an array. One that can grow like a List or a Set.
In general, a Corner should not need to know of other Corners. A different type should manage all the Corners and handle dependencies between them.
You did not wrote why 'I want all the Corner object to have access to all the other Corner objects' so I cannot recommend how this managing type could look like.
First of all, taking in not what Kevin has said, you should change
public void createArray(int, int);
to
public static void createArray(int, int);
I do not understand the need to have a two-dimensional array for accessing other Corner objects.
Also array is not a good structure type for dynamic allocation. List is better alternative and in this case List. So you should implement it as -
You should create a list as -
private static List<Corner>;
In general, static is an abnormality in good OO design. You only use it if there are very good reasons to do so.
Your example doesn't look like such a case. You see, you are mixing up things that don't belong together. A "corner" is simply that a "corner". It doesn't know about other "corners".
In the model that you are actually creating, you have some "enclosing" thing that deals with corners in plural. That enclosing thing could have some List<Corner> field that is used to track all Corner objects belonging to the enclosing entity.
static often looks like an easy, convenient way to solve such problems. But in reality, you are just creating a lot of problems by implementing something like this. It works initially, but it breaks as soon you try to enhance your program.
Is this good form?
No.
There are two reasons:-
Reason 1 :- Single responsibility principle. Every object should be responsible about its concern . So its not the concern of corner object to maintain the list of other corner object. Maintaining corner object can go under some util class method or singleton object maintaining the corner cache(which will be easy to test also)
Reason 2 :-
unit testing. Say you want to write unit test for static method you won't be able to do it easily until and unless you provide any third party lib that provides static mocking like jmockit,
This question already has answers here:
Set and Get Methods in java?
(16 answers)
Closed 8 years ago.
In my CS class I am just learning about classes and OOP.
So when you create a class you initialize a certain number of private variable.
I know you make them private because if they were public they would be easily changeable and could lead to a lot of bugs.
So we use get and set methods to change the variable. But that once again makes the variables very easy to change right? So whats the point of making them private in the first place?
Some benefits of using getters and setters (known as encapsulation or data-hiding):
1. The fields of a class can be made read-only (by only providing the getter) or write-only (by only providing the setter). This gives the class a total control of who gets to access/modify its fields.
Example:
class EncapsulationExample {
private int readOnly = -1; // this value can only be read, not altered
private int writeOnly = 0; // this value can only be changed, not viewed
public int getReadOnly() {
return readOnly;
}
public int setWriteOnly(int w) {
writeOnly = w;
}
}
2. The users of a class do not need to know how the class actually stores the data. This means data is separated and exists independently from the users thus allowing the code to be more easily modified and maintained. This allows the maintainers to make frequent changes like bug fixes, design and performance enhancements, all while not impacting users.
Furthermore, encapsulated resources are uniformly accessible to each user and have identical behavior independent of the user since this behavior is internally defined in the class.
Example (getting a value):
class EncapsulationExample {
private int value;
public int getValue() {
return value; // return the value
}
}
Now what if I wanted to return twice the value instead? I can just alter my getter and all the code that is using my example doesn't need to change and will get twice the value:
class EncapsulationExample {
private int value;
public int getValue() {
return value*2; // return twice the value
}
}
3. Makes the code cleaner, more readable and easier to comprehend.
Here is an example:
No encapsulation:
class Box {
int widthS; // width of the side
int widthT; // width of the top
// other stuff
}
// ...
Box b = new Box();
int w1 = b.widthS; // Hm... what is widthS again?
int w2 = b.widthT; // Don't mistake the names. I should make sure I use the proper variable here!
With encapsulation:
class Box {
private int widthS; // width of the side
private int widthT; // width of the top
public int getSideWidth() {
return widthS;
}
public int getTopWIdth() {
return widthT;
}
// other stuff
}
// ...
Box b = new Box();
int w1 = b.getSideWidth(); // Ok, this one gives me the width of the side
int w2 = b.getTopWidth(); // and this one gives me the width of the top. No confusion, whew!
Look how much more control you have on which information you are getting and how much clearer this is in the second example. Mind you, this example is trivial and in real-life the classes you would be dealing with a lot of resources being accessed by many different components. Thus, encapsulating the resources makes it clearer which ones we are accessing and in what way (getting or setting).
Here is good SO thread on this topic.
Here is good read on data encapsulation.
As the above comment states, getters and setters encapsulate (i.e. hide) inner details of your class. Thus other classes that interact with yours, do not need to know about the implementation details.
For example, in the simple case you describe, instance variables are exposed via getters and setters. But what if you wanted to change your class so that you no longer used instance variables, but rather you persisted the values to disk. You could make this change to your class without affecting the users of your class.
Keep in mind also that getters and setters need not always be provided. If you do not want your class to provide a way to set or read these properties, then don't. Simply make them private.
get is used to obtain a value for an attribute and set is used to put a value to an attribute
ex:
private int variable;
public int getVariable(){
return variable;
}
public void setVariable(int aux){
variable=aux;
}
In general, is used to encapsulate an attribute.
reference:
Set and Get Methods in java?
Encapsulation or data hiding gives u more control on what values can be set to a field. Here is an example if you don't want a class attribute to have a negative value:
class WithoutGetterSetter {
public int age;
}
class WithGetterSetter {
private int age;
public setAge(int age) {
if(age < 0)
// don't set the value
else
this.age = age;
}
}
public class testEncapslation {
public static void main(String args[]) {
WithoutGetterSetter withoutGetterSetter = new WithoutGetterSetter();
withoutGetterSetter.age = -5;
WithGetterSetter withGetterSetter = new WithGetterSetter();
withGetterSetter.setAge(-5);
}
}
Get and Set methods are preferable to "public" variables because they insulate the users of a class from internal changes.
Supposing you have a variable "StockQty" and you made it public because that seemed like the easiest thing to do.
Later on you get a user requirement to track the history of stock over time. You now need to implement a SetStockQty() method so you can save the old quantity somewhere before setting the new quantity.
Now all the users of your class have to change there code, re-document and re-test.
If you had SetStockQty() method to begin with only you would need to change and test your code.
The second reason is you can have Getters without Setters effectivly making the variable "read only".
Traditionally, they are justified in terms of encapsulation. By providing moderated access to read and write the fields of a class, we supposedly reduce coupling.
In simpler language: by controlling the ways in which other classes can read and change our data, we reduce the ways in which our class's data can change. This means that the connections between classes are reduced, which reduces complexity.
However, the same logic says that getters and setters should generally be avoided unless there's an actual need for them, and there very seldom is such a need. For the most part, a class should "tend to its own knitting" - if there's a calculation to be done on this class's data, it should do it. If a value should be changed, it should do the changing.
For example, consider an object in space. It has a location specified as (x,y,z). We could possibly allow other classes to just set those arbitrarily - this would be horrible, obviously, but it's not obvious that a setter for these would be any better. What you really want is a constructor to set an initial position, and then methods to influence that position - for example, to register an impact or an acceleration. Then you're doing OO programming.
One word, Encapsulation.setters also allow you to control how values are entered into your program. Many new programmers like myself are often confused by this concept. I strongly advice you read this SO question
Being objective: it's all about best pratices!!!
1) IF necessary, expose your attributes with get methods.
2) IF necessary, allow attribute modification (state modification) using set methods;
Have both public get and set methods without treatment is the same as have the attributes public.
I've just read a fantastic example of a builder pattern.
In my program I'm creating a series of playerCharacter entities, which can be constructed in various ways, with some compulsory fields and some that can be added on as extra or added latter on (after construction). So, after reading the above post, it seems as though I need a builder pattern.
Do I have the option of the builder and super class (here, in the example Pizza and builder) sharing some of the methods? Is there a neat, known solution to this?
For instance if, in the above example (of the pizza), at a later time we had a method of Boolean isPizzaCold() and void heatTo(int degrees) and we wanted the pizza to return false to start with, as it's 'built' hot, and later to let the pizza 'get cold', so that it cools. How would I do this such that they share the same methods?
[edit: as per Joeri's suggestion I've changed the method example.]
If you take the builder out of the class, it's still a builder. A builder is in the first place a convenient way to construct your object, it doesn't always need to be the only way. You could even state that creating an object is clearly a separate responsibility, and that it is cleaner to separate it (like a factory - builder pattern combined). I personally believe it depends mostly on the complexity of the creation.
No, your object and builder classes cannot share methods. The only way to share method is through inheritance, which clearly is not to be used here.
Your builder is a throwaway object, and the object it constructs is clearly of a different class. The only thing you can do is store the requested value, and call the appropriate setters automatically after the object was built.
void setTemperature(int t){
this.temperature = t;
}
Pizza build() {
Pizza pizza = new Pizza(... usual constructor stuff);
pizza.setTemperature(temperature);
return pizza;
}
Also, I wonder if void setTemperature(int) makes sense. void heatTo(int degrees) makes more sense to me :)
I don't really see the relation between your question and the builder pattern. If you want a method setTemperature() and a method isCold(), just add them to the Pizza:
private static final int COLD_THRESHOLD = 40;
private int temperature = 70;
public void setTemperature(int temperature) {
this.temperature = temperature;
}
public boolean isCold() {
return temperature <= COLD_THRESHOLD;
}
Where can I use an instance method and where is it appropriate to use a class method?
I know the term of class and instance method.
Static methods are class level methods, they are good for utility methods for example Math class in Java. These classes usually take a few inputs work with them and gives desired output(For example Math.pow(4,5)).
Instance methods rather work with the whole object in question. Good example would be almost any class of Java. Still, for example; FileInputStream where read() method reads data from underlying stream.
Example of static method would be
class Math(){
public static long multiply(long a, long b){
return a*b;
}
public static void main(String[]args){
System.out.println(Math.multiply());
}
}
Example of instance method can be
class User(){
private String pass;
private String uname;
public User(String p,String u){
pass=p;
uname=u;
}
public boolean authenticate(){
if("secret".equals(this.pass) && "Grrrr".equals(this.uname){
return true;
}else{
return false;
}
}
public static void main(String[]args){
User u = new User("wrong secret","grrr");
System.out.println(u.authenticate());
}
}
In the second example pay attention to the fact that to use the instance method we must create an object first and then only call the method.
Static methods are conceptually the same as static variables, thus the reasons to use or not use them are similar. They belong to the class, not specific objects of that class. An example from the java API is Math, all the variables are static. Does it make sense to have to create a Math object just to call a single method? Other then the fact that the methods perform some mathematical operation, there is little relation between them. In other words, there are no logical instance variables that would tie the math methods together. As an aside, you can't instantiate Math, so don't waste time trying.
A simple answer to why and when is 'whenever it makes sense". If a method needs to be in a class, but not tied to an object, then it makes sense. If the method is more logically part of an object, then it shouldn't be
Main is static because someone at Sun decided it would be better if the JVM could call main without creating an object first. It probably simplified the design of the JVM.
Hoi,
i can add the following reference:
Excerpt of Joshua Bloch's "Effective Java"
or as Print:
Effective Java (2nd Edition) [Paperback]
The book is really great and anyone wanting to write better code should at least skim it ^^
cu
Here's the link to the Java tutorial, which has a good overview, with examples and code:
http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html
Static methods are suitable for utility classes and to create singletons. Basically in 90% you will avoid static methods.
You cannot overwrite static method using inheritance (polymorphism) - you can only shadow it. Shadowing is anti paten in OOD.
Static methods should not be part of Object Oriented Design - use them only as technical helpers.
This is about understanding representations and their uses.
If you have a class that represents a person, all people may share the same attributes, but their specific attributes will differ. So everyone has a height, but some people are shorter and others taller. To represent a person you need a specific instance that says "my name is bob and im 2m tall", or "my name is sally im 1.9m tall". Your representation of a person depends on the specific instance.
However some things can be represented universally. For example, adding one number to another will always yield the same result, so there's no need for many representations. Hence the Math class has static methods.
In practice, with Java, the jvm will load a class and use it as a "blueprint" for creating instances (all people will share the same attributes, even if their actual values vary), or as the universal definition (for statically declared stuff). For static methods you should be wary of synchronisation (it helps to understand the heap/stack), as well as potential bottlenecks. In distributed applications, the universal definition may be loaded more than once (per jvm).
Ivor Horton has a great example in his book, with a Sphere class. He defines getCount() as a class method, because it gives you the ability to count the number of Spheres you have created, even when there is no Sphere object it returns 0. volume() on the other hand, is an instance method since it calculates the volume of a specific sphere and you have a different volume for every Sphere instance.
public class Sphere {
static final double PI = 3.14; // Class variable that has a fixed value
static int count = 0; // Class variable to count objects
// Instance variables
double radius; // Radius of a sphere
double xCenter; // 3D coordinates
double yCenter; // of the center
double zCenter; // of a sphere
// Class constructor
public Sphere(double theRadius, double x, double y, double z) {
radius = theRadius; // Set the radius
// Set the coordinates of the center
xCenter = x;
yCenter = y;
zCenter = z;
++count; // Update object count
}
// Static method to report the number of objects created
public static int getCount() {
return count; // Return current object count
}
// Instance method to calculate volume
public double volume() {
return 4.0/3.0*PI*radius*radius*radius;
}
}
Try it out with this class:
public class CreateSpheres {
public static void main(String[] args) {
System.out.println(“Number of objects = “ + Sphere.getCount());
Sphere ball = new Sphere(4.0, 0.0, 0.0, 0.0); // Create a sphere
System.out.println(“Number of objects = “ + ball.getCount());
Sphere globe = new Sphere(12.0, 1.0, 1.0, 1.0); // Create a sphere
System.out.println(“Number of objects = “ + Sphere.getCount());
// Output the volume of each sphere
System.out.println(“ball volume = “ + ball.volume());
System.out.println(“globe volume = “ + globe.volume());
}
}
i am giving a brief explanation since i myself am learning about java,but what i have understood in simple language is-
instance methods-dynamic,work with whole objective or purpose of the object in question
class instances-are static,deal with a particular topic concerned with all the objects
This is a very generic scenario, where I am setting a variable using setter function and using the variable only locally.
class Main {
private String str;
public Main(String value)
setStr(value);
}
private String getStr() {
return str;
}
private void setStr(String str) {
this.str = str;
}
public void display() {
//METHOD1
System.out.println(getStr());
//METHOD2
System.out.println(this.str);
}
}
What would be the better practise to follow between the two METHOD1/2 in display function, basically what would be the better way of using "str" variable.
Does it even make sense to have private getter/setter functions?
Ivard
If the getter is private, and doesn nothing more than returning a private variable, it isn't needed, IMHO (i.e. I prefer the second method of accessing it).
But if the getter was public and not final, and could thus be redefined by a subclass, then you'd have to decide if you want to get the potentially overridden value returned by the getter, or if you want the value of the private field in the display method.
Here should be at least one comment with Yes.
By providing new abstraction barrier you can separate data accessors and data presentation. For example, lets look at complex number class. Which can be implemented as
class ComplexNumber {
private final double realPart;
private final double imaginaryPart;
ComplexNumber(double realPart, double imaginaryPart) {
this.realPart = realPart;
this.imaginaryPart = imaginaryPart;
}
public double getRealPart() {
return realPart;
}
public double getImaginaryPart() {
return imaginaryPart;
}
}
or in polar expressions form
class ComplexNumber {
private final double r;
private final double angle;
ComplexNumber(double r, double angle) {
this.r = r;
this.angle = angle;
}
public double getR() {
return r;
}
public double getAngle() {
return angle;
}
}
Presume that you should implement basic operation like +-/*. What presentation model should you choose? For addition and subtraction standard model preferable, but for multiplication and division polar form preferable. So you can create getters for both form. And implement add/_sub_ like you have standard model and div/_mult_ like with polar form. This operation wouldn't depend from your actual data presentation. For change presentation you should change getters. Thats all. In Java world it's called self encapsulation.
For simple cases you'd just use this.str. For more complex cases, you might want to inherit from such a class, and have getStr() be implemented in a subclass perhaps it would lazily get the string from a file/database. Then these methods would't be private though.
For trivial cases where you just assign and fetch a private member, not really. For more complex cases where you might need to do additional logic, it'd make sense to confine that logic to one place. As with 1., it would make sense if you want sub classes to override the methods as welll.
Unless you have a side effects in your public getter which you desire I would consider always using this for consistency unless inheritance is assumed.
It doesn't make sence at all to me to employ private accessors. A routine should typically only do one thing and preferably without side effects. Creating a private getter
without side effects only creates useless redundancy.
with side effects basically proves that either the method is doing too much or is poorly named
Using this might also make refactoring easier [1].
[1] Refactoring a private variable gives less impact than refactoring a method. If you later decide to change the contract, e.g., by no longer providing a getter routine you will get less to refactor. Besides, many editors highlight all occurences of a variable when pointing the cursor to it, which is lost when hiding its use in a sub-routine.
No, it's not useful to have private getter/setter methods. If they were public or otherwise overridible by subclasses though it would be a different story. Should a subclass override your getter/setter, it could change the way the display() method functions.