3

This could be a quirk of the IDE I am using, Android Studio, or it could be something more nuanced that I don't understand.

I have a method setCustomFont that appears as a property in the Structure view in my IDE. It appears that AS is making this decision to class it as a property based on its signature and the set / get prefix of the method name. The field that it thinks I am mutating is customFont however this does not exist.

I changed the method name to applyCustomFont and now the Structure view in AS reflects something closer to the truth in my class.

I was wondering if this is by design? Should I try and stay clear of set / get unless I have an associated field?

Edit: I am also wondering about sensible method names regardless of whether the IDE has a Structure view.

Improve this question
5
  • 1
    looks like AndroidStudio is making assumptions based on method name. You'll just have to put up with it using that IDE.
    – gbjbaanb
    Jun 30, 2015 at 7:35
  • why didn't you ask at Stack Overflow? meta.stackexchange.com/a/129632/165773
    – gnat
    Jun 30, 2015 at 7:35
  • 2
    @gnat Because I felt that it was a more general whiteboardy type question not tied into a particular implementation of my code.
    – mez.pahlan
    Jun 30, 2015 at 7:43
  • Does your code still behave properly when you name the method how you want? The behavior is more important than what the "structure view" or whatever in your IDE shows you.
    – Brandin
    Jun 30, 2015 at 7:54
  • @Brandin Yes it behaves the same. I was wondering about sensible method names too. Even if the IDE didn't provide a structure view. I'll add that as an edit to make it clearer. Thanks.
    – mez.pahlan
    Jun 30, 2015 at 7:56

2 Answers 2

Reset to default
9

That's not a quirk of your IDE - that's part of the Java Beans convention. There are many other Java tools and libraries(ORMs, serializers, configuration readers etc.) that rely on these conventions and will not work(or work poorly) if you disobey them.

That being said - getters should not always be restricted to physical fields. If you have a class Circle with a radius field, then in addition to the getRadius() method you can also have a getArea() field that calculates the area from the radius. As long as you can calculate the result in a fast, side-effects-free manner, there is no problem with getters that aren't directly mapped to member fields. Sure, that means that your IDE will show you the area in addition to the radius - and this shouldn't be a problem.

Setters are a different story, because some tools/libraries might be using reflection to invoke all your setters, which may alter the state of the object in unexpected ways. For example, in your class a serializer might call getCustomFont(), receive null(because there is no custom font), serialize it, and when reading it'll call setCustomFont(null) and override the non-custom font.

Improve this answer
1

Given the popularity of different kinds of frameworks that rely on Java Beans convention, I think we should avoid prefixing the methods with get/set if they don't represent the object's properties.

It happened to me in a few occasions that I unintentionally added a useless attribute in a JSON response of a service, just because I added a new helper get method to the object being serialized. Sometimes it's just an extra useless information, but sometimes it causes NullPointerExceptions or similar.

Rather, I prefer using other equivalent prefixes, so instead of:

circle.getArea();

I would have:

circle.calcArea();

This way I also more explicitly indicate that some calculation is done in the method, rather than just returning a stored value.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.