Когда использовать конструктор и когда передавать аргументы

Question

Мой общий вопрос в том, когда передавать аргументы конструктору vs, когда передать его методу класса. В общем случае объектом являются «данные» + «методы, действующие на данные».

У меня есть несколько вариантов дизайна класса DFS. Какой из следующих примеров лучше всего подходит для защиты?

Вариант 1: График, переданный в конструкторе, источник в функции. Adv: Тот же объект DFS будет повторно использоваться с другим источником.

public class DFS { 
    Graph g; 
    public DFS(Graph g) { 
    this.g = g; 
    } 

    public void doDfs(int source) { 
    // dfs computation 
    } 
} 

Вариант 2: Конструктор с 2 Params и не полиморфизма Disadv: для каждого нового источника новый объект должен быть построен.

public class DFS { 
    Graph g; 
    int source; 

    public DFS(Graph g, int source) { 
     this.g = g; 
     this.source = source; 
    } 

    public void doDfs() { 
     // dfs computation 
    } 
} 

Вариант 3: Конструктор перегрузки Adv: решает все наши случаи использования. Dis: Полиморфизм является дорогостоящим.

public class DFS { 
    Graph g; 
    int source; 

    public DFS(Graph g) { 
    this.g = g; 
    } 

    public DFS(Graph g, int source) { 
    this.g = g; 
    this.source = source; 
    } 

    public void doDfs() { 
     doDfs(source); 
    } 

    public void doDfs(int source) { 
    // dfs computation 
    } 
} 

Вариант 4: Нет конструктор

public class DFS { 

    DFS() { } 

    public void doDFS(Graph g, int source) { 
     this.g = g; 
     this.source = source; 
     // dfs computation 
    } 
} 

Answer 1

Если у вас есть что-то, связанное с операциями/определения класса, то это означало быть принят в качестве конструктора. Это также означает, что было бы очень желательно иметь его как immutable. Например:

public class DFS { 
    final Graph g; 
    public DFS(Graph g) { 
    this.g = g; 
    } 

    public void doDfs(int source) { 
    // dfs computation 
    } 
} 

Вот вы знаете, что класс DFS содержит несколько методов (каждый с собственным алгоритмом), чтобы найти DFS графа g. В таких случаях вы знаете, что g является неизменным и будет больно передавать его для каждого вызова метода, поэтому лучше сделать его аргументом конструктора. Некоторые преимущества:

1. Отсутствие избыточного аргумента для каждого вызова метода.
2. Если вы хотите сделать некоторое внутреннее кэширование, вы можете это сделать. Это работает так, как все связано с известным объектом: g
3. Безопасность нити, отсутствие явной блокировки. Вам это понадобится с сеттерами.

Короче говоря, если вы знаете, что что-то не изменится к определению класса, сделайте его аргументом конструктора. Имейте методы, которые используют эти переменные экземпляра. Используйте Setters, когда вы знаете, что что-то может измениться.

Answer 2

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

Но вы могли бы выбрать, чтобы создать класс, чтобы данные были добавлены позже. Это зависит от того, как вы собираетесь использовать свой класс, - вы должны разрабатывать свой класс для пользователей.

Кстати, вы прокомментируете в своем сообщении, что «Полиморфизм является дорогостоящим». Нет, если полиморфизм - это то, что делает работу для вас, тогда это не дорого. И это зависит от того, какой именно полиморфизм вы имеете в виду.

Answer 3

Лично я предпочитаю вариант 4. Конструктор или минимальный конструктор не позволяют тестировать класс с модульным тестированием.

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