могут ли конструкторы иметь объекты bufferedReader в java

Question

В C ++ возможно иметь поток по умолчанию, такой как

class c
{
 public:
  c(istream fin =cin):fin(fin){}


} 

Similary я могу сделать это в Java или это неправильная практика. Или есть лучший способ сделать это?Я хочу выбирать между чтением из консоли и чтением из файла.

class c
{ 
    c()
    { BufferedReader br=new BufferedReader(new InputStreamReader(System.in));
    }
   c(int i)
   {  FileReader f=new FileReader(path);
      BufferedReader br=new BufferedReader(f);

    }
}

Answer 1

«Да, они могут».

Однако я думаю, что большинство посоветует сделать как можно меньше в конструкторе. (И я подозреваю, что многие также будут утверждать, что конструктор не должен завершиться с ошибкой , исключая, возможно, неверный ввод) Конструктор не обязательно должен быть потребителем. Например, посмотрите, как работает класс сканера . Также интерфейс Closeable удобен для управления ресурсами.

Удачного кодирования.

Answer 2

Вы можете сделать это на Java.Возможно, вам придется что-то делать с возможными исключениями IOException.Тем не менее, лучшим подходом может быть определение конструктора, который принимает Reader, так что вы можете создать экземпляр экземпляра, используя любой источник данных:

class C {
    C(Reader rdr) {
        BufferedReader br = new BufferedReader(rdr);
    }
}

(Кстати, соглашения Java по кодированию - это имена классовначинаются с заглавных букв.)

Answer 3

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

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

Однако, при условии, что такой конструктор действительно является «перегрузкой удобства» для других более фундаментальных методов / конструкторов API, которые выполняют задачи конструирования и анализа, в этом нет ничего плохого:

public Foo(Reader reader) {
    this();
    this.load(reader);
}

public Foo() {
    ...
}

public void load(Reader reader) {
    ...
}

Я бы использовал Reader вместо BufferedReader в качестве типа аргумента.В некоторых случаях использования не требуется буферизация BufferedReader, и если ваш класс использует ограниченные возможности синтаксического анализа BufferedReader, вам не следует раскрывать детали реализации в своих методах API ...равны.(Но прагматика может диктовать иное.)

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

public void load(Reader reader) {
    BufferedReader br = (reader instanceof BufferedReader) ?
            (BufferedReader) reader : new BufferedReader(reader);
}

---

Ваш обновленный пример:

Аппаратно подключен System.in или имя файла в классе - плохой дизайн.Это делает код слишком негибким.Простое изменение конфигурации для чтения данных из другого места повлечет за собой изменение кода ... и, возможно, поиск кода, чтобы найти все другие места, где пути и т. Д. Были жестко запрограммированы.