''King of Swamp Castle'': Make sure the Prince doesn't leave this room until I come and get him. ''Pair 1'': Not ... to leave the room ... even if you come and get him. ''King'': No. ''Until'' I come and get him. ''Pair 2'': Hic. ''Pair 1'': Until you come and get him, we're not to enter the room. ''King'': No ... --MontyPython ---- Usually some domain-specific constraints upon the data & behaviour of a business system. For example, "if the terms of the contract are XXX then we can start recognizing the revenue at date YYY". The rules should be explicit model of contracts and contractual behavior, encapsulated in objects. An approach might be to define a common Rule interface, and then compose Rules into a Rule''''''Set: public interface Rule { public boolean check(); } public class Rule''''''Set implements Rule { // skip private list of rules, constructor, etc... public void addRule( Rule rule ) { _rules.add(rule); } public boolean check() { Iterator rules = _rules.iterator(); while ( rules.hasNext() ) { Rule rule = (Rule)rules.next(); if (!rule.check()) return false; } return true; } } Concrete Rule instances can be constructed with the data necessary to fire the rule as prescribed by their check() method. The Rule''''''Set is assembled with a collection of Rule instances, with which a single call to check() will effectively accomplish the 'if' logic. Combining AND and OR operators takes a bit more work. This is probably more than is necessary for checking whether a field is editable or not, but it does address the 'if' statement for generic rule-based systems. The simplest approach is to simply refactor each test into its own method, as you've already pointed out. ---- I don't think business rules. I think it sucks. ''Yes, but in many cases the alternatives suck more.'' ---- See BusinessRulesMetabase BusinessRule ----- CategoryBusinessDomain, CategoryRealdata