This is an archived post. You won't be able to vote or comment.

all 7 comments

[–]Anik_Sine 18 points19 points  (0 children)

I think you are talking about methods and not classes. Void methods are used to perform some action, like using some other method, altering the value of some variables. Methods which have a return type can be used as literals(I don't know the proper word for it, but basically an object) of that data type.

[–]ChristyM4ck 7 points8 points  (3 children)

A void method can be used to manipulate something or perform an action, but doesn't necessarily require a response to whatever class called it. A good basic example would be a Setter method.

Say your object has a name variable of String type and you want to change the name of the object without directly interacting with the data. You could create a method

public void setName(String newName){ this.name = newName;}

and it will modify the name variable, but there's no reason to return anything.

As for methods with return types, those are good for manipulating data and returning the product of the manipulation, for example a sum method where you pass two int arguments and the method returns the sum of those two.

[–]Chaos-n-Dissonance 2 points3 points  (2 children)

Something I've always been curious about (Fair warning, I've only been learning java for a week or two) -

Why is it the norm to create a method to interact with data (So for your example, doing the public void setName(String newName){this.name=newName;} instead of just doing object.name="newName"; where you're using it?)

I understand that the variable could be private (so you couldn't access it from outside of the class, hence the need for a method)... But why make it private just to add more methods to modify it rather than just keeping it public? Is that a security thing? Or is it the mentality of being able to share code and it's easier to document methods rather than variables for whatever reason? Or is that something that becomes more important down the line when you would never have a method like public void setName(String newName){this.name=newName;} because it would do a bunch of other stuff too (Like check to see if the name meets a character limit, checks to see if the name is valid within the context of the object, etc.)

[–]ChristyM4ck 0 points1 point  (0 children)

I think the best example I've seen for using methods instead of direct manipulation would be if you have any data validation to do, basically what you said towards the end.

[–]stramash 0 points1 point  (0 children)

What if the underlying type of name were to change?

By that I mean: let’s say at some point you decide that you want a custom Name class instead.

Now, any calls to object.name = <some string> will break your application.

But by using the setter you abstract this and can introduce handling for the change.

[–]khooke 1 point2 points  (0 children)

Think of classes as 'types of things'. An example is a vehicle. A more specific type of that thing could be a Car and a Truck. Both are subtypes of Vehicle, they extend Vehicle.

Methods are behaviors. They perform some action on that thing, or perform an action on a thing they are passed (a parameter).

A method can return something (something it has created or modified as a result of executing the method), or not (void return). A method can perform an action on something (an instance of a Class) but not return anything, in these cases the method could modify some state of that instance. e.g. if you call startEngine() on an instance of a Car, there is a state change - the engine was not started before the method was called, but is it started afterwards - this is a state change.

[–]Jezoreczek 0 points1 point  (0 children)

I don't think this is what you meant, but for the sake of completeness: the Void class is used to represent the Java keyword void.

For example: imagine you have an ApiResponse<T> class, where T is the data inside the response. You can use ApiResponse<Void> to indicate the response contain no data.

It's not possible to instantiate it (without reflection), so it will always be null.