I'm sorry, but wasn't it called "bubble 2.0"?
Nothing irritates me more than people talking about web 2.0 like its the next best thing, when they can't even explain what it is! If you want to sell something, just call it web 2.0.
I'm sorry, but wasn't it called "bubble 2.0"?
Nothing irritates me more than people talking about web 2.0 like its the next best thing, when they can't even explain what it is! If you want to sell something, just call it web 2.0.
The design with the exception is also not good for a completely
different reason. This is that an exception is introduced to deal with
a very special case, namely accidentally finding the solution to the
problem.
If you would leave out the entire mechanism with the exception, then
the algorithm would probably still work. It looks like trying to
optimize for a very special case. By the way, I have worked extensively
in numerical mathematics with a focus on iterative solution methods and
I never saw any code to deal with the extremely special case of
accidentally finding the solution. If your algorithm is good you can
just leave out the check.
Suppose you would like to write a DAO with a flexible interface to retrieve
objects based on certain conditions. Then of course, representing the condition(s)
as objects and generating some sort of 'where' clause from the condition
could be a valid solution.
But if you can think only in linearly and not in terms of nested or
composite conditions, you would view the following condition
i == 5 AND j == 6 AND k == 5
not as AND ( AND (i == 5, j ==6), k ==5 ) but instead as
'i ==5' 'AND j ==6' 'AND k == 5'
And of course, to pass in this condition to a DAO interface you would need
a collection of conditions like this:
findByCriteria(Collection<Condition> conditions)
instead of simply
findByCriteria(Condition condition)
But then how to represent conditions? Well of course, you would
use a concrete base class Condition which implements all the basic conditions
like this:
public class Condition {
protected String _field;
protected int _operator;
protected RowValue _value;
public final static int OP_EQUALS = 1;
public final static int OP_LARGER_THEN = 2;
public final static int OP_SMALLER_THEN = 3;
public final static int OP_SMALLER_EQUALS_THEN = 4;
public Condition(String aField, int anOperator, RowValue aValue) {
_field = aField;
_operator = anOperator;
_value = aValue;
}
public Condition(Condition aCondition){
_field = aCondition.getField();
_operator = aCondition.getOperator();
_value = aCondition.getValue();
}
public void toWhereClause(StringBuffer aQuery) {
aQuery.append(_field);
switch(_operator) {
case OP_EQUALS:
aQuery.append("=");
break;
case OP_LARGER_THEN:
aQuery.append(">");
break;
case OP_SMALLER_THEN:
aQuery.append("<");
break;
case OP_SMALLER_EQUALS_THEN:
aQuery.append("<=");
break;
}
aQuery.append("?");
}
}
Apart from some little things like (1) using protected data, (2) using a switch
statement instead of inheritance to represent operations, (3) not testing the
operator values passed in for validity, (4) not testing
for the 'default' of the switch statement, and (5) using a concrete base class
instead of an interface, this could be a valid implementation.
To implement the AndCondition, the programmer extended the normal condition
and pass in the Condition to extend. The toWhereClause() method now simply
delegates to the base class method and adds " AND " to the beginning.
public class AndCondition extends Condition {
private Condition _condition;
public AndCondition(Condition aCondition) {
super(aCondition);
_condition = aCondition;
}
public void toWhereClause(StringBuffer aQuery) {
aQuery.append(" AND ");
_condition.toWhereClause(aQuery);
}
}
Ok, just to make sure the programmer did not loose any information, note
that the condition passed in to the AndCondition is passed to the base class
but also stored as member variable just in case (!?).
Now, this is just a simplified version of the actual case we found in a
production system. The Condition base class also contains the following
convenience methods:
// AND aField == aValue
static Condition createAndConditionEquals(String aField, int aValue);
// AND aField == aValue
static Condition createAndConditionEquals(String aField, String aValue);
with of course also some methods for the OrCondition. This adds cyclic
dependences to the list of bad coding practices.
Of course, one could only imagine how to implement conditions such as
i == 5 AND (j ==4 OR k == 5)
No doubt, we would need the Condition class for representing i == 5, the
AndBracketOpenCondition for "AND (j ==4", and the OrBracketCloseCondition for
"k ==5)".
It took me about 1 hour to really understand this ludicrous design so I wanted
to share this with you all. The (variable) names have been changed to protect
the incompetent.
Cheers
Erik
I'd like to join as well. I really admire Oracle for its data expansion
capabilities (expanding a 50MB dump into a 2GB database), as well as
for its built-in delay loops at database creation.