Блог

Главная - Вопросы по программированию - метод проверки объектов из разных корней повторяет большинство проверок

метод проверки объектов из разных корней повторяет большинство проверок

#java #lambda #instanceof

#java #лямбда #instanceof

Вопрос:

пожалуйста, есть ли способ сделать код более кратким — чтобы избежать повторения похожих / одинаковых действий — у меня есть метод, выполняющий проверки объектов, но большинство параметров похожи / одинаковы, например, используя для этого какое-то лямбда-выражение, но объекты не из одного дерева.

Мой вариант использования такой:

 validate.( car );

и где-то еще я делаю:

 validate.( person );

Прямо сейчас я выполняю проверку следующим образом:

 public boolean validate( Object obj ) {
  if ( obj instanceof Car ) {

    Car car = (Car) obj;
    if ( car.getAge() <= 0 ) return false;
    // many other checks which are repeated below

  } else if ( obj instanceof Person ) {

    Person person = (Person) obj;
    if ( person.getAge() <= 0 ) return false;
    // many other check which are repeating those above

  }
  // here I would like to do checks for both objects, but objects are from different roots

return true;
}

Ответ №1:

Вы можете использовать перегрузку метода :

 public boolean validate(Car car) {
    if ( car.getAge() <= 0 ) return false;
    return validate((Master)car);
}
public boolean validate(Person p) {
    if ( p.getAge() <= 0 ) return false;
    return validate((Master)p);
}
public boolean validate(Master m) {
    // common validations
    return true;
}

Master является общим родителем Person и Car (я предполагаю, что существует общий родительский интерфейс / класс).

Ответ №2:

«Не»s:

  1. Прежде всего, я бы строго посоветовал вам стараться изо всех сил избегать разработки вашего метода, как вы это делаете сейчас;
  2. Person и Car не имеет ничего общего с логической, моделирующей или концептуальной точки зрения. И они не имеют каких-либо схожих характеристик в реальной жизни;
  3. Не принимайте Object в качестве аргумента в вашем методе. Вам будет трудно управлять своими ошибками и / или поддерживать непредсказуемое поведение.

«Do»s:

  1. Определите свой метод, следуя принципу единой ответственности;
  2. Рассмотрим с точки зрения вашего объекта модели — каким должен быть ваш метод в качестве поведения? какую проблему он должен решить?
  3. Попробуйте разделить проблемы в их соответствующих классах / файлах / блоках и постарайтесь не перекрывать их.

Если вы хотите, чтобы ваш метод работал на основе фактического экземпляра аргумента, лучший способ — использовать instanceof проверки.

Однако вместо этого вы можете создать некоторое правильное наследование и принять супертип в качестве аргумента метода. Тогда включится полиморфизм, и у вас будет только одна логика в вашем методе.

Комментарии:

1. Спасибо, это сущности, и моя модель, вероятно, не оптимальна, поэтому я создам абстрактный суперкласс, и оба объекта унаследуют его.