Another language on top of ye olde JVM is Qi4j. There's a list of thoughts behind it, including something which sorta ran a bell with layman-me. (Recently, due to design frustrations at work and due to Warnock's "Stay an order of magnitude more general than you think you need" quote, I've been thinking that really atomizing things in a design would be neat, so you could more easily in theory use the bits a la lego to refactor into whatever new take on your app you need.)

Decoupling is Virtue:
Decoupling is more important than developers in general think. If you could have every OOP class decoupled from all other classes, it is easy to re-use that class. But when that class references another class and the chain never ends, your chances of re-use diminishes quickly.
Object Oriented Programming is suffering a lot from this, and many mechanisms have been introduced over time to counter this problem. But in reality, the best we can manage is subsystems of functionality, which client code can re-use. And these subsystems tend to be infrastructure related, since domain models are less prone to be similar enough from one project to the next, and since OOP in reality constrains the the re-use of individual domain classes, we need to re-do the domain model from scratch ever time.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I like the idea of

I like the idea of decoupling as much as possible. The principles used to design a good library should apply:

- Types should not depend too much on types from another library
- Types in the same library should work well together
- Each type has a well defined use
- A minimum number of types needed for a given task
- Make use of interfaces wherever user-defined functionality is likely to be plugged-in

(Well that is my principles, some may think differently :-) )