We performed a code review recently of mobile application Java code that was developed by an outside contractor and noticed that all of the domain objects / data transfer objects are written in this style:

public class Category {
    public String name;
    public int id;
    public String description;
    public int parentId;

public class EmergencyContact {
    public long id;
    public RelationshipType relationshipType;
    public String medicalProviderType;
    public Contact contact;
    public String otherPhone;
    public String notes;
    public PersonName personName;

Of course, these members are then accessed directly everywhere else in the code. When we asked about this, the developers told us that this is a customary performance enhancement design pattern that is used on mobile platforms, because mobile devices are resource-limited environments. It doesn't seem to make sense; accessing private members via public getters/setters doesn't seem like it could add much overhead. And the added benefits of encapsulation seem to outweigh the benefits of this coding style.

Is this generally true? Is this something that is normally done on mobile platforms for the reasons given above? All feedback welcome and appreciated -

  • 7
    "Domain specific pattern" is one of my favourite excuses for crappy code, and it comes right after "performance issues". That said, not a mobile developer, there might be some truth in there.
    – yannis
    Jun 6, 2012 at 6:48
  • Why is there a Java tag and iphone tag. These two tags do not coincide. This is either a generic coding question or an android/j2m question.
    – Rig
    Jun 6, 2012 at 13:44
  • 1
    @Rig Because the original post was meant to include objective C as well, that code exhibits the same style, but I ran out of Tags to attach to the post. I should have added clarity to the original post or removed the iphone tag. I've removed the iphone tag for the sake of clarity. Jun 6, 2012 at 16:56
  • @SeanMickey That's cool. Just a by the wayside comment...people tend to severely underestimate what mobile devices can do these days. Almost sounds like old hats premature optimizing.
    – Rig
    Jun 6, 2012 at 17:53

5 Answers 5


the developers told us that this is a customary performance enhancement design pattern that is used on mobile platforms, because mobile devices are resource-limited environments

Assuming that authors did not bother to provide authoritative references to justify their "design decision", you are pretty safe to consider this a brain-fart of underqualified coders.

I've been in mobile Java racket for several years (still having 2 or 3K SO reputation in related tags because I use it as the way to not forget the basics), reviewed and wrote plenty of code, studied multiple specifications, tutorials and style guides - none of these ever mentioned even a shade of difference this kind design could possibly have compared to Java SE. If you're interested in finding such tutorials and guides yourself, check SO tag wikis in relevant tags like java-me, midp etc.

  • I really wouldn't go as far to say "underqualified developers". Logically it makes sense and simply could be a hangover from really old phones (slow) with really old Java versions (not optimized)
    – TheLQ
    Jun 9, 2012 at 17:42
  • @TheLQ this funny pattern per se isn't thier problem; the problem is that they can't explain it. And no, customary performance enhancement for mobile is not an explanation - one can not just throw such a maintainability nightmare at strangers and expect it to stick with justification like that
    – gnat
    Jun 12, 2012 at 9:39

There is a grain of truth in your contractor's assertion.

For some time, Android game developers were encouraged to avoid internal getters and setters for performance reasons. However, this advice only applies to game developers who need to push devices to the limit, and are required to sacrifice other benefits to achieve their aims. Moreover, with the release of Gingerbread, this even gamed benefit little from this practice.

More than once, I've met developers give "best practice" advice or follow guidelines that is perfectly valid in one scenario (often historic) but which simply doesn't apply to the case in hand. More often than not, this is because the developer has forgotten (or never knew) the reasons why their advice applied the first place, so they assume it must be valid for all cases at all times. In my experience, this is particularly common when discussing performance tuning. That seems to be the case here.

The correct approach to performance is:

  1. to get it right before you make if fast
  2. use metrics to tell you what to optimise and again to determine whether your efforts are succeeding
  • 2
    This answer adds a general perspective that is very helpful. It is a nice complement (not compliment) to @gnat's and allows me to understand what has been done in a broader way. It confirms my initial assessment of the approach. Thanks Jun 8, 2012 at 11:51

You're right that on its own this probably not a significant difference in performance, but if it's a sign that in general the developers are keeping an eye on reducing the number of method calls (which are relatively expensive) and other overhead, it means they're doing a good job.

I'd discuss more in depth with them about their general coding philosophy to see if this is what they're aiming for.

(you're also making the assumption that public fields are unquestionably bad and getters/setters are the only way, which I don't think you'd find 100% support for, even on this site)

  • Thanks for you thoughts. But I'm not really making an assumption; I have an open mind. I am trading it off against the benefits of encapsulation. And having validation in the setXyz methods. Jun 6, 2012 at 7:21

Is this generally true? Is this something that is normally done on mobile platforms for the reasons given above?

It may be true that historically it was done this way; e.g. because earlier mobile platforms are particularly resource constrained ... or have particularly poor optimizers ( not naming any names :-) ).

But I don't think that "customary" or "historical practice" is relevant. You have an absolute right to say what coding standards you want your contractor to adhere to. Besides, if your platform is not resource constrained (or whatever) then your contractor's "customary practice" justification is empty ... because the conditions that make this unfortunate practice acceptable do not exist.


For domain objects this is rubbish design - you want logic encapsulated on the domain objects, or you at least want to be able to add logic easily later.

But for DTO's I use similar design as they have no logic - they are DTOs.

I would assume that any performance overhead (which would be minuscule anyway) will be optimized out by the java virtual machine anyway.

Your Answer

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

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