Compile-time business rules

Question

using apt i have embedded compile-time checks for particular relationships, e.g. AnnotationA exists (only) on ClassB, AnnotationC exists on subclass of ClassD, ClassE has 0..n refs to ClassF, ClassG declares AnnotationH, ClassI has 0..n fields/methods annotated (by), etc.
with a declarative programming approach, knowing what functionality a particular annotation declares, the absence/existence of this metadata can tell us about business relationships
with apt business rules can be enforced at compile-time
this approach provides an alternative to another thread posting
http://forum.java.sun.com/thread.jspa?threadID=5180602&tstart=0
and is available without spec change
i am interested in hearing if others are doing this
additional relationship
Message was edited by:
developer_jbs

Answer 1

Declarative programing has all but gone the way of
the doe doe because...
1: It is not flexible (It is extremely difficult to
change a complex system in a predetermined way)isn't this the "expert system" model?
2: It lengthens the development cycle (see item 1)
3: It normally forces the developer to add many
things to there code to get things to work, that have
nothing to do with the intent of the code.more things? the declarations or the declaration processing?
In its defense (I like a declarative model but, do
not like being forced into one)...not advocating a forced change in Java
1: It increases code safety.
2: It can shorten the development cycle, in certain
circumstances (especially if it is not overused),
because it can greatly increase the readability of
code.
3: It follows many best practices (although this is
also possible in a Non-Declarative model).as for best practices what I'd like to see are declarative design patterns, Adapter, Singleton, Factory, Delegate, Strategy, Interpreter, Proxy, Visitor
too often the design intent is lost in an implementation or design details can only be deduced by class/field/method names, comments, and accompanying docs
So, if everyone had unlimited time, and an unlimited
budget, yes declaritive is the way to go. Since that
is not the case, we filtered out 99% of what it gave
us, made sure the stuff that was getting in the way
was removed, and what do you have???
You guessed it OOA&D.
Now having said that should we be more declarative? I
think so, but I will tell you now, REQUIRING
declarative elements in code is a sure fire way to
get the majority of development groups to drop the
language (and I think Java as it stands currently CAN
be declarative, so if you have one of those unlimited
budgets, go for it!).no need to require it
I believe given good (reusable) declarative options, on top of OOP, will become the chosen approach
reusable design declarations would lessen overall cost and increase readability