Копировать конструктор, используя личные атрибуты - PullRequest
3 голосов
/ 11 марта 2010

Мой первый вопрос, так что будьте нежнее.

Я хотел бы получить аргументы для следующего кода:

public class Example {
    private String name;
    private int age;

    ...

    // copy constructor here
    public Example(Example e) {
        this.name = e.name; // accessing a private attribute of an instance
        this.age = e.age;
    }

    ...
}

Я считаю, что это нарушает модульность экземпляра, переданного конструктору копирования. Вот что я считаю правильным:

public class Example {
    private String name;
    private int age;

    ...
    // copy constructor here
    public Example(Example e) {
        this.setName(e.getName());
        this.setAge(e.getAge());
    }

    ...
}

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

Я стою на перекрестке. Можете ли вы пролить свет?

Ответы [ 2 ]

1 голос
/ 11 марта 2010

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

Однако, если вы добавляете методы / свойства доступа, любой приличный компилятор должен оптимизировать их до простых «inline», в этом случае второй метод - более чистый код (все обращения осуществляются через вашу функцию доступа), но оба подхода должны закончить нас быть одинаково эффективными (возможно, идентичными) для каждого элемента.

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

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

1 голос
/ 11 марта 2010

Доступ основан на классе, а не на объекте.

Логическое обоснование для того, чтобы сделать член закрытым, заключается в том, что классы не должны знать подробности реализации вне четко определенного API, чтобы остальная часть системы терпела изменение реализации. Однако конструктор копирования не является «первым в системе» - это ваш собственный класс.

...