Нужны советы по кодированию лучших практик

Question

Я хочу понять, является ли следующая практика кодирования хорошей или плохой.

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

Class A
{
  initStudent()
  {
    Student studentObj = new Student();
    //do some processing

    studentObj = processStudent(studentObj);
  }

  processStudent(Student pObj)
  {
    //do something

    return pObj;
  }
}

Answer 1

иногда необходимо получить параметр и вернуть параметр того же типа, даже если манипуляция с параметром происходит по некоторым причинам:
1.если объект неизменный (т. е. строка)
2.если объект действительно может быть изменен (хорошим примером для него является <T>[] List.toArray(<T>[]), где, если в массиве параметров недостаточно места, создается новый, в противном случае массив записывается в параметре)
3.он также неявно сообщает пользователю, что значение может быть изменено ...
4.не бойтесь делать это при необходимости, многие проекты используют его (например, Apache Lucene)

Answer 2

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

Если метод не предназначен для изменения объекта, вы не должны возвращать его.

Answer 3

Действительно, вам не нужно возвращать объект. Просто ничего не возвращай.

Class A
{

  void initStudent()
  {
     Student studentObj = new Student();
   //do some processing
    processStudent(studentObj);
  }

 private void processStudent(Student pObj)
   {
       //do something
   }

}

Редактировать: Кроме того, как указал adarshr, созданный вами объект Student будет бесполезен, если он не "выйдет" из метода initStudent(). Возможно, вы захотите вернуть его или сохранить в поле экземпляра коллекции.

Answer 4

Да, вы не должны его возвращать.Используйте модификаторы доступа и возвращаемые типы правильно.

public class A
{

  public Student initStudent()
  {
     Student studentObj = new Student();
     //do some processing

     processStudent(studentObj);

     return studentObj;
  }

  private processStudent(Student pObj)
  {
       //do something
  }
}

Answer 5

Я бы скорее стремился к внедрению зависимостей в сочетании с шаблоном проектирования декоратора

В основном коде я бы обработал инициализацию ученика и передал ее, чтобы ее оформить

studentObj = new Student();

decoratedStudentObj = new A(studentObj);

finalStudentObj = decoratedStudentObj.getStudent()

Который вызвал бы метод getStudent () во всех разных классах и изменил бы весь объект ученика в каскаде.

Так что в итоге вы могли бы получить что-то вроде этого:

studentObj = new Student();

decoratedStudentObj = new A(studentObj);

decoratedStudentObj = new A(decoratedStudentObj );

decoratedStudentObj = new B(decoratedStudentObj);

decoratedStudentObj = new C(decoratedStudentObj );

finalStudentObj = decoratedStudentObj.getStudent()

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

IE:

studentObj = new Student()

decoratedStudentObj = new A(studentObj);

finalStudentObj = decoratedStudentObj.getStudent()


highSchoolStudentObj = new HighSchoolStudent()

decoratedHighSchoolStudentObj  = new A(highSchoolStudentObj);

decoratedHighSchoolStudentObj = new B(decoratedHighSchoolStudentObj );

finalHighSchoolStudentObj   = decoratedHighSchoolStudentObj .getStudent()


collegeStudentObj = new CollegeStudent()

decoratedCollegeStudentObj  = new A(collegeStudentObj );

decoratedCollegeStudentObj  = new C(decoratedCollegeStudentObj);

finalCollegeStudentObj  = decoratedCollegeStudentObj.getStudent()

И, наконец, проще реализовать UnitTesting, так как вы можете легко насмехаться над классом ученика, чтобы самостоятельно протестировать его класс обработки.

Answer 6

как насчет установки studentObj в качестве переменной-члена, так как это тот же класс

EDIT: я полагаю, что processStudent вызовет некоторые методы для Student, которые называются завистью к функциям - этот метод «хочет быть в Student»,Это не очень хорошая практика, вместо этого создайте эту обработку внутри класса Student, создав новый метод