At some point I’m guessing that the
SheepImpl I’m looking at was an implementation of a
Sheep interface, which extended the
Animal interface. There’s also an
AnimalImpl class. The
Impl classes are generated by persistence layer stuff, so there’s some logic there.
(Why couldn’t we just have called it
HibernatingSheep? Would that have been too obvious, perhaps?)
There are other unrelated uses of Impl as implementations for interfaces –
GrassImpl for the
MangerService – you get the picture. It seemed reasonable to assume that the animals followed the same daft convention.
Assumptions are dangerous. Conventions are dangerous, especially when they are conventions in sheep’s clothing, so to speak. I should have read the code more carefully.
Sheep is now also a class with its own functionality, and is extended, not implemented, by
Sheep itself extends
Animal (also a class) but not
AnimalImpl. It’s taken me half an hour to work this out, and now my head hurts. Partly from unravelling spaghetti this late on a Friday, but mostly from doing this:
*Bangs head on table repeatedly*
Note: The actual code is in a retail application and has nothing to do with sheep. Thinking about things in terms of sheep, however, is helping me to be less stressed about this. One sheep. Receipt for one sheep. Special offer: two sheep for one! I would like four sheep, please. I’m sorry, Sir, we only have three sheep in stock, but I can order a fourth sheep for you.
Dreaming of electric sheep. Hmm.