Существуют ли неблагоприятные последствия от передачи объектов вместо назначения их в качестве членов класса

Question

У меня есть привычка создавать классы, которые, как правило, передают объекты для выполнения операций над ними, а не присваивают их переменной-члену, а операции ссылаются на переменную-член.Это гораздо более процедурно для меня, чем ОО.

Это ужасная практика?Если да, каковы неблагоприятные последствия (производительность, потребление памяти, более подвержены ошибкам)?Разве проще и более тесно увязано с ОО-принципами, такими как инкапсуляция, в пользу переменных-членов?

Придуманный пример того, что я имею в виду, приведен ниже.Я склонен делать следующее:

public class MyObj()
{

  public MyObj() {}

  public void DoVariousThings(OtherObj oo)
  {
    if (Validate(oo))
    {
       Save(oo);
    }
  }

  private bool Validate(OtherObj oo)
  {
    // Do stuff related to validation
  }

  private bool Save(OtherObj oo)
  {
     // Do stuff related to saving
  }

}

, тогда как я подозреваю, что должен делать следующее;

public class MyObj()
{

  private OtherObj _oo;

  public MyObj(OtherObj oo) 
  {
    _oo = oo;
  }

  public void DoVariousThings()
  {
    if (Validate())
    {
       Save();
    }
  }

  private bool Validate()
  {
    // Do stuff related to validation with _oo
  }

  private bool Save()
  {
     // Do stuff related to saving with _oo
  }
}

Answer 1

Если вы пишете свои программы на объектно-ориентированном языке, люди будут ожидать объектно-ориентированный код. Таким образом, в вашем первом примере они, вероятно, ожидают , что причина для того, чтобы сделать oo параметром, состоит в том, что вы будете использовать разные объекты для него все время. Во втором примере они будут знать , что вы всегда используете один и тот же экземпляр (как инициализировано в конструкторе).

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

Answer 2

Я думаю, что вы уже ответили на свой вопрос сами, вам кажется, что вы знаете о том факте, что второй подход в целом более предпочтителен и его следует использовать (если нет серьезных причин для первого подхода).

Преимущества, которые сразу же приходят мне в голову:

• Упрощенная удобочитаемость и удобство обслуживания как для вас, так и для других
• Только одна точка входа, поэтому требуется только проверка! = Ноль и т..

• В случае, если вы хотите проверить этот класс, это намного проще, то есть получить что-то вроде этого (извлечь интерфейс IOtherObj из OtherObj и работать с этим):

  public MyObj (IOtherObj oo)  
  {
      if (oo == null) throw...
      _oo = oo;
  }
  

Answer 3

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

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

В двух словах, ваш путь плох для: 1. повторного использования кода.2. Вы должны обрабатывать больше исключений.3. Хорошо, если вы держите вещи при себе, иначе - не очень хорошая практика.

Надеюсь, это прояснило некоторые сомнения.