Verifying Objects using Java interfaces

I’m currently facing a design problem and would appreciate advice on how I could resolve it:

The problem

I will use an example to illustrate my problem note this is just an example:

Suppose you have an interface called Pass with methods listed:

public interface Pass {
  public boolean hasPassedA();
      public boolean hasPassedB();
      public boolean hasPassedC();
}

Suppose you have a class which implement this interface called Assessor:

public class Assessor implements Pass{
// how should I implement this class ?? 
}

Finally Student class:

public class Student {
  // some code that defines student behaviour not important.
}

The question is then how can I make the interaction between the Assessor and the student object a lot more flexible?

What I noticed is that an Assessor object should be something that is abstract because in reality there is no su开发者_开发技巧ch thing as an Assessor, but instead you have different types of assessors such as a Math Assessor or English Assessor etc, which in turn will allow me to create different types of Assessor objects e.g.

MathAssessor extends Assessor
EnglishAssessor extends Assessor

The concept is that a Student can pass if all the methods declared in the Pass interface return true and all additional methods in the subjectAssessor classes return true.

What do I do in the Assessor class? I have read about adapter design patterns but haven’t fully grasped that notion or does it even apply to this situation?

---

To start, the Pass interface you have is not very flexible, which could make for difficulties. For example, what if one implementation of Pass only needs to have hasPassedA, or you have an implementation which needs hasPassedA, hasPassedB, hasPassedC and hasPassedD. Then the various types of assessors will need to figure out which pass conditions to check.

A more flexible way to do this might be to do something like this. Rather than having a Pass interface, maybe something like a Condition interface (the names of the classes/interfaces should be changed to make sense for your domain).

public interface Condition {

   // true means the condition passed, false means it did not
   boolean evalutate();
}

Now you could have a single Assessor class (I'm not sure if this is exactly how your assessor would work, but it's just a guideline):

public class Assessor {

   boolean assess(Collection<Condition> conditions) {
      for (Condition c : conditions) {
        if (!c.evaluate()) {
           return false;
        }
      }
      // all conditions passed
      return true;
   }
}

Hopefully this helps for your problem.

---

First off, to answer your question about the adapter pattern, it doesn't apply here. You use the adapter pattern to add a layer between 2 incompatible systems to allow them to pass data back and forth.

Using your example, I would recommend writing default implementations of the hasPassed_() methods in Assessor, even if the implementation is nothing more than throwing a new UnsupportedOperationException (to answer the question about what if a particular Assessor only needs a subset of hasPassed_() methods you can just overwrite only the ones you need). You can modify the subject assessor's (e.g. MathAssessor, EnglishAssessor, etc.) Pass methods to be more specific or to provide additional checks before calling super.hasPassed_() (depending on your specific implementation).