Результат поиска файлов

[Hopkroft]

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

[Spectator]

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

[Hopkroft]

Spectator, т.е. поиск должен происходить следующим образом.
1. Создаю класс. Хотя можно метод Search сделать статическим.
2. Вызываю метод Search, который в начале работы очищает список с результатами.
3. Внутри метода, есть функция поиска файлов FindFiles.
4. По мере нахождения, файлов FindFiles потихоньку пишет, данные в мой список.
5. На выходе, Search возрвращает список.
Верный ход мыслей?

[Spectator]

Hopkroft, не совсем.
создаешь класс, в нем делаешь единственный конструктор, который принимает параметр - путь.
создаешь метод, делаешь его приватным и вызываешь только из этого конструктора, Search ИЛИ FindFiles, который делает всю работу - и очищает и заполняет список.

таким образом после создания (конструирования) объекта у тебя уже будет готовый список файлов, НЕИЗМЕННЫЙ, до тех пор пока ты ЯВНО его не уничтожишь и не создашь заново, что будет достаточно заметным кодом чтобы его не заметить при отладке.

нечто вроде того что ты и написал но вместо пары методов Search / FindFiles - конструктор / метод FindFiles

[Hopkroft]

Spectator, т.е. получается что-бы найти файл, мне придётся каждый раз создавать объект для поиска?
Я думал, мне будет достаточно создать объект в начале, а потом уже использовать его метод для поиска файлов. Ну или сделать метод статичным, что-бы мог пользоваться им без создания объекта.

[silly]

Мысль не доведена до логического завершения: список нужно передавать в функцию поиска. Примерно вот так:

private void actuallyFindFiles(Path dir, List<Path> found) {

	...

	for (Path path : myfiles) {
		found.add(path);
	}

	...

	for (Path subdir : subdirectories) {
		actuallyFindFiles(subdir, found);
	}
}

public List<Path> findFiles(Path dir) {
	List<Path> found = new ArrayList<>();
	actuallyFindFiles(dir, found);
	return found;
}

[Spectator]

Сообщение от Hopkroft

Spectator, т.е. получается что-бы найти файл, мне придётся каждый раз создавать объект для поиска?

да.
Если тебя такой вариант не устраивает - воспользуйся тем что предлагает silly
Но так как ты предлагаешь - не делай. Это криво и раньше или позже выйдет боком. _И_ хранить результат поиска в классе _И_ хранить результат поиска в какой то глобальной переменной - плохо.

[manifest]

Spectator, Hopkroft, ООПите ради ООПности, господа

[Hopkroft]

manifest, есть вариант лучше? Или на Яве без ООП можно написать?

[manifest]

Сообщение от Hopkroft

manifest, есть вариант лучше? Или на Яве без ООП можно написать?

Мой посыл был в том, что зачем городить класс, когда функции более чем достаточно. Другими словами, silly, привел самое лаконичное решение имхо. Я бы еще вместо двух ф-ций, перегрузил одну, пускай будет публичной, пользователь сам решит какой вариант ему использовать в каждом конкретном случае, будет еще гибче. Под ООПностью понимал создание класса, так как далек от мира Java, не знаю является ли функция в этом языке объектом или нет.

[Spectator]

Сообщение от manifest

Мой посыл был в том, что зачем городить класс

тема не об этом совершенно, это флуд, это раз.
класс городить потому что это Java, в ней нет понятия "просто функция" или "глобальная функция". точка входа в программу находится в методе класса унаследованного от системного, весь остальной код - тоже внутри классов.

на что тебе Hopkroft и намекал:

Или на Яве без ООП можно написать?

чтобы ты не умничал, если не разбираешься в принципе в языке, о котором идет речь.

[manifest]

Сообщение от Spectator

тема не об этом совершенно, это флуд, это раз.

Сообщение от Hopkroft

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

тема как раз об этом, судя по вопросу

Сообщение от Spectator

класс городить потому что это Java, в ней нет понятия "просто функция" или "глобальная функция". точка входа в программу находится в методе класса унаследованного от системного, весь остальной код - тоже внутри классов.

Не вижу связи между вопросом топика и точкой входа и тем где находится весь остальной код. Перефразирую свое предыдущее предложение в терминах Java: "Зачем городить класс и создавать в нём еще какое-либо свойство, когда статического метода более чем достаточно? И еще раз другими словами, зачем создавать класс в классе, когда достаточно статического метода в классе?".

Сообщение от Spectator

чтобы ты не умничал, если не разбираешься в принципе в языке, о котором идет речь.

Так это же интересно, разобраться. В спорах истина рождается.

[Hopkroft]

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

[manifest]

Сообщение от Hopkroft

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

А для чего может понадобиться вызывать из статического метода не статический?

[Hopkroft]

Напимер в примере от Silly, findFiles вызывает actuallyFindFiles. Если findFiles сделать статическим он не сможет вызывать actuallyFindFiles. А если сделать не статическим, то уже подавай, экземпляр класса.
Честно сказать, я не думаю что мы ухудшим читаемость если создадим объект и воспользуемся его методом.

[manifest]

Чтобы было понятнее о чем говорю, переписал пример silly.

public class Example {

public static List<Path> findFiles(Path dir) {
	return findFiles(dir, new ArrayList<>());
}

public static List<Path> findFiles(Path dir, List<Path> acc) {
	...
	for(Path fp : files)
		acc.add(fp);
	...
	for(Path dp : subdirectories)
		ListUtils.union(acc, findFiles(dp, acc));
	
	return acc;
}

}

[Hopkroft]

manifest, думаю пойдёт как вариант.

У меня тут один вопрос, если папка окажется недоступной, например системной. Пользователя нужно как-то об этом известить exception кинуть, или её просто не выводить в списке найденных.

[manifest]

Сообщение от Hopkroft

Честно сказать, я не думаю что мы ухудшим читаемость если создадим объект и воспользуемся его методом.

Я конечно понимаю, что Java имеет свою философию, в которой даже элементарные вещи описываются трехэтажным кодом, и безусловно, каждый дро пишет как он хочет. Но иногда бывает полезно задачать вопрос: "А зачем я так делаю? И дает ли мне это решение какие-то плюсы?".

[Hopkroft]

Сообщение от manifest

Но иногда бывает полезно задачать вопрос: "А зачем я так делаю? И дает ли мне это решение какие-то плюсы?".

Ну вот я этим вопросом как раз и задался

[manifest]

Сообщение от Hopkroft

manifest, думаю пойдёт как вариант.

У меня тут один вопрос, если папка окажется недоступной, например системной. Пользователя нужно как-то об этом известить exception кинуть, или её просто не выводить в списке найденных.

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

[silly]

Сообщение от manifest

Чтобы было понятнее о чем говорю, переписал пример silly.

ListUtils.union(acc, findFiles(dp, acc));

Вот здесь должно быть просто findFiles(dp, acc), поскольку findFiles дергается ради ее побочных эффектов (изменения acc), не для возвращаемого результата.

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

public static List<Path> findFiles(Path dir) {

	List<Path> acc = new ArrayList<>();

	...
	for(Path fp : files)
		acc.add(fp);

	...
	for(Path dp : subdirectories)
		acc = ListUtils.union(acc, findFiles(dp));

	return acc;
}

Да, кстати, насчет файлов, в документации по nio нашелся метод Files.walkTree и даже пример использования есть.

[Hopkroft]

silly, я так понял ты примерами из 7 jdk пользуешься (судя по Path)
а почему acc.add вместо addAll не юзаешь?

[silly]

Сообщение от Hopkroft

а почему acc.add вместо addAll не юзаешь?

Написал по памяти, исправлял ошибки 4 раза, больше ничего трогать не хочу.