Методы программирования: передача объектов или значений в качестве параметра метода

Question

Передача параметров обычна в ежедневном программировании, но должны ли мы передавать параметры как объект или значения?

(А)

public boolean isGreaterThanZero(Payment object) {
    if (object.getAmount() > 0) {
       return true;
    }

    return false;
}

(B)

public boolean isGreaterThanZero(int amount) {
    if (amount > 0) {
       return true;
    }

    return false;
}

Answer 1

Ни то, ни другое.

При правильном ООП для объекта Payment будет isGreaterThanZero (), то есть:

class Payment {
  int amount
  public boolean isGreaterThanZero() {
    return amount > 0
  }
}

, а затем:

Payment payment
boolean flag = payment.isGreaterThanZero()

Answer 2

Предполагается, что вы спрашиваете о передаче параметров, а не об объектном дизайне ...

При разработке метода необходимо учитывать ряд аспектов.

1. Можно ли использовать этот метод в других местах? В вашем примере ответом может быть «да» - он может сказать, является ли любое int больше нуля, - в этом случае (B) является более полезным.
2. Если метод требует более одного параметра и относится к определенному объекту в вашем коде, тогда передайте объект.

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

Answer 3

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

Я бы прошелобъект, когда:

1. Метод должен иметь дело с большим количеством данных, передаваемых извне.Желательно обернуть эти параметры в объекте, потому что это означает, что метод может принимать один параметр, а не 1 на значение данных.Вы также можете переориентировать логику проверки параметров в класс-оболочку для лучшей локализации.1.
2. Когда одна и та же комбинация параметров часто используется в API

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

Answer 4

Это надуманный пример, но если это единственное взаимодействие, которое получающий класс имеет с Платежем, я бы использовал это значение в интересах развязки.Нет смысла создавать лишние зависимости классов.

РЕДАКТИРОВАТЬ: Марсель и я печатали одну и ту же вещь одновременно.:) Это.

Answer 5

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

Answer 6

Согласно концепциям ООП, мы должны использовать Objects.Но не злоупотребляйте этим.Например, в вашем примере я бы использовал int.Но в методе, где я использую несколько значений во многих местах, я бы использовал объект.
Я бы не создавал класс Payment только с одним членом данных "amount".

Answer 7

Да, мы можем передать объект как параметр в Программе Java.

Первый путь

     class demo
     {private int length=1;
      private int breadth=1;
      private int area;
      void input(int length,int breadth)
      {
         this.length=length;
         this.breadth=breadth;
      }
      void add(demo d1,demo d2)
      {
          length=d1.length+d2.length;
         breadth=d1.breadth+d2.breadth;
      }
     void output()
     {
         System.out.println("\nLength="+length+"\nBreadth="+breadth);
     }

        public static  void main(String args[])
        {

            demo d1=new demo();
            demo d2=new demo();
            d1.input(1, 1);
            d1.output();
            d2.input(2, 2);
            d2.output();
            demo d3=new demo();
            d3.add(d1, d2);
            d3.output();

        }

     }

Второй путь

</p>

<code>     class demo
     {private int length;
      private int breadth;

      void input(int length,int breadth)
      {
         this.length=length;
         this.breadth=breadth;
      }
     demo add(demo d2)
      { demo obj=new demo();//Neccesary as we want to return complete  
                                     object irrespective of its number of data fields
          obj.length=length+d2.length;//Storing the length of two objects  
                                                     in the obj 
         obj.breadth=breadth+d2.breadth;
         return obj;
      }
     void output()
     {
         System.out.println("\nLength="+length+"\nBreadth="+breadth);
     }

        public static  void main(String args[])
        {

            demo d1=new demo();
            demo d2=new demo();
            d1.input(1, 1);
            d2.input(2, 2);
            demo d3=d1.add(d2);//Here we created new object d3 called  
                                         add() by d1 and passed d2 object through it 
            d3.output();

        }

     }
</code>

Answer 8

Addenum для моего предыдущего ответа. Это также зависит от оптимизации компилятора и контекста вызова метода. Если объект уже определен до вызова метода или это метод, который может извлечь выгоду из встраивания и оптимизации, не рекомендуется использовать адрес. Если вы находитесь в цикле, то лучше использовать адрес. Вам нужно немного подумать о том, как метод будет использоваться в конкретной программе (= предвидеть, как он будет скомпилирован).

Answer 9

Иногда, передача адреса объекта (или указателя, дескриптора, как бы вы его ни называли) в качестве параметра, а затем приведение его в методе (как экземпляр полученного объекта) быстрее, чем передача объекта в качестве параметра.Это просто способ ограничить способ компиляции.Если иногда это ничего не меняет, то в других случаях передача адреса будет значительно ускорять работу программы.Это низкоуровневый компилятор, но он действительно МОЖЕТ сделать код быстрее.

Answer 10

Я думаю, что мы должны использовать примитивные типы всякий раз, когда это возможно (int, double, boolean, char) в качестве параметров, потому что не случайно, что существуют примитивные типы. Я предпочитаю второй вариант, потому что он более общий (он не заставляет вас предоставлять объект Payment, любое значение int будет достаточно хорошим). Но когда вам нужно состояние объекта (как минимум, два значения данных объекта), ситуация может измениться, вы можете использовать значения в качестве параметров для более общей возможности использования или объекты в качестве параметров для простоты.