Win a copy of Bad Programming Practices 101 (e-book) this week in the Beginning Java forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Class naming  RSS feed

 
Greenhorn
Posts: 1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

While reviewing a co-workers code, I came across a number of model POJO classes named CustomerJson, AddressJson, etc. These are pure data structures. There are fields with jackson annotations, and the usual getters and setters.

These class names don't seem right to me, they should just be named Customer and Address. The fact that they will at some point be serialized as JSON seems irrelevant.  Is there some OO principle that is being violated here, or are the names ok?

Thanks.
 
Sheriff
Posts: 12091
197
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The programming principle or concept that comes to mind is that of leaky abstractions whereby something that should be more abstract gives away information about its underlying implementation. This can be a problem both from a semantic as well as a conceptual point of view if the underlying implementation changes in the future. I think your instinct about those names are well founded.
 
Junilu Lacar
Sheriff
Posts: 12091
197
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And welcome to the Ranch!
 
Marshal
Posts: 5804
401
BSD
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Problems may be larger than one can imagine.

It can also carry this exposed implementation details to the test suite, so now you'd need to maintain implementation details naming not just in actual code, but also presumably in unit tests. And if an underlying data structure changes, and unluckily you don't reflect that in test suite, you end up with asymmetry between the code and tests, which in turn makes the code base sloppy over the time.
 
Saloon Keeper
Posts: 8990
168
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I also wouldn't call them Customer and Address. These classes are obviously intended to represent objects from your business model while they are being transferred somewhere else. I would call such classes CustomerData and AddressData.
 
Bartender
Posts: 19560
90
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Liutauras Vilda wrote:Problems may be larger than one can imagine.

It can also carry this exposed implementation details to the test suite, so now you'd need to maintain implementation details naming not just in actual code, but also presumably in unit tests. And if an underlying data structure changes, and unluckily you don't reflect that in test suite, you end up with asymmetry between the code and tests, which in turn makes the code base sloppy over the time.



This was a very real problem when I tried using Hungarian Notation with C++. Items would go from being a boolean to an integer to a counter to an enumeration and sometimes even to a class. It was either rename things all over the place or have misleading names (and this was back when IDEs had much less automatic refactoring ability).
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!