From experts to novice, everyone uses the “layer” jargon in the context of testing, code reuse, modular design,
For starters, i have a blog post on “DB entity object HAS-A DAO”.
* import — Ideally, a upper-layer class imports lower-layer classes. Shared-layer classes can be imported by all.
* compile-time dependency — Ideally, low-layer classes should be compilable without upper-layer classes.
* reusable components — therefore, lower-layer classes should be reusable in other projects in the absence of upper-layer classes.
* testing — To test a upper-layer method (we didn’t say “class”), you often need to instantiate (or mock) the lower-layer objects. Even if you use interfaces, you still need to instantiate these lower objects to run their methods.
(Suggestion: reduce cross-layer inter-dependencies.)
* use-a, has-a — upper-layer classes could use-a or has-a lower-layer class, but not vice versa.
* separation of concern — lower-layer objects should not need to know about upper-layer. If my class uses xstream (or a mailer, a scheduler, a serializer, a parser, a timer…), then xstream should be oblivious of my class.