Проверка объектов с использованием интерфейсов Java

Question

В настоящее время я сталкиваюсь с проблемой проектирования и был бы признателен за советы, как мне ее решить:

Проблема

Я буду использовать пример, чтобы проиллюстрировать мою заметку о проблеме, это простопример:

Предположим, у вас есть интерфейс под названием Pass с перечисленными методами:

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

Предположим, у вас есть класс, который реализует этот интерфейс под названием Assessor:

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

НаконецКласс ученика:

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

Тогда возникает вопрос, как я могу сделать взаимодействие между Ассессором и объектом ученика более гибким?

Что я заметил, так это то, что объект Ассессора должен бытьчто-то абстрактное, потому что в действительности не существует такого понятия, как Assessor, но вместо этого у вас есть разные типы асессоров, такие как Math Assessor или English Assessor и т. д., что, в свою очередь, позволит мне создавать разные типы объектов Assessor, например

MathAssessor extends Assessor
EnglishAssessor extends Assessor

Концепция заключается в том, что Student может пройти, если все методы, объявленные в интерфейсе Pass, возвращают trи все дополнительные методы в классах subjectAssessor возвращают true.

Что мне делать в классе Assessor?Я читал о шаблонах проектирования адаптеров, но не полностью понял это понятие или оно вообще применимо к этой ситуации?

Answer 1

Для начала, интерфейс Pass не очень гибок, что может создать трудности. Например, что если одной реализации Pass требуется только иметь hasPassedA, или у вас есть реализация, для которой нужны hasPassedA, hasPassedB, hasPassedC и hasPassedD. Затем различные типы оценщиков должны будут выяснить, какие условия проходят проверку.

Более гибкий способ сделать это может быть что-то вроде этого. Вместо того, чтобы иметь интерфейс Pass, может быть что-то вроде интерфейса Condition (имена классов / интерфейсов должны быть изменены, чтобы иметь смысл для вашего домена).

public interface Condition {

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

Теперь у вас может быть один класс Ассессора (я не уверен, что именно так будет работать ваш оценщик, но это всего лишь руководство):

public class Assessor {

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

Надеюсь, это поможет вашей проблеме.

Answer 2

Прежде всего, чтобы ответить на ваш вопрос о шаблоне адаптера, он здесь не применим. Шаблон адаптера используется для добавления слоя между двумя несовместимыми системами, чтобы они могли передавать данные туда и обратно.

Используя ваш пример, я бы порекомендовал написать реализации по умолчанию методов hasPassed_ () в Assessor, даже если реализация представляет собой не что иное, как создание нового исключения UnsupportedOperationException (чтобы ответить на вопрос о том, что, если конкретному Assessor требуется только подмножество Методы hasPassed_ () вы можете просто перезаписать только те, которые вам нужны). Вы можете изменить методы оценки субъекта (например, MathAssessor, EnglishAssessor и т. Д.), Чтобы они были более конкретными или предоставляли дополнительные проверки перед вызовом super.hasPassed_ () (в зависимости от конкретной реализации).