- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
public ArrayList<String> bookListByAuthor(String author)
{
ArrayList<String> bookList = null;
for (BookType bType : bookTypes)
{
ArrayList<String> authors = bType.getBookAuthors();
for (String bookAuthor : authors)
{
if (author.equalsIgnoreCase(bookAuthor))
{
if (bookList == null)
{
bookList = new ArrayList<String>(INITIAL_CAPACITY);
}
bookList.add(author);
break;
}
}
}
return bookList == null ? null : bookList;
}
Follow us!
return жесткий. Хочу из этого же проекта классы реализующие запросы к БД.
не найдется, bookList итак null'ом будем. Ещё забавляет попытка экономии
памяти с отложенной инициализацией, но это уже другая история...
2. Вообще возвращать null - дурацкая идея, для этого есть Collections.emptyList()
3. Напрягает алгоритм перебора с квадратичной сложностью
2. Почему возвращать null плохо?
3. Как улучшить алгоритм?
2. К примеру, в моём проекте 80% критических ошибок связано с NPE
3. Использовать для поиска БД
Ну да, а ждать, пока нажатие на "Другие книги этого автора" будет выполнять поиск по БД с квадратичной сложностью - не спорно. Ну-ну.
П. С. Хотя в данном примере наверное все-таки логично было бы создать сущность. Ибо Пушкин написал далеко не одну книгу.
2. В целом соглашусь. Сам предпочитаю никогда не возвращать null. Использую emptyList().
С другой стороны это может быть логика: либо Null, либо в списке по крайней мере один элемент. Отчасти дело вкуса.
3. Описал чуть выше, когда это сделать не получится
Зависит от семантики. Однозначного ответа быть не может.
Не вижу ничего зазорного в некоторых случаях возвращать конкретную реализацию, вместо интерфейса.
П. С. Вообще в беседе пока только мы вдвоем учавствуем как-то =)
именно потому, что в жаве хрен так просто что-то отфильтруешь.
Ещё часто вижу примеры, где Lisp бы идеально подошёл для создания DSL (последнее, что приходило в голову - генерация MathML-кода). Поэтому подумываю поближе посмотреть Clojure в ближайшем будущем.
Что это?
Is Google broken today?
Я, например, иногда пишу небезопасный код: в API возвращается List, а я его модифицирую, зная, что его можно модифицировать, т. к. возвращается копия да к тому же изменяемая.
Так почему же возвращать ArrayList - это плохо? Вроде как сразу явная декларация намерений происходит =)
> явная декларация намерений
когда я вижу метод, который возвращает ArrayList, я скорее буду воспринимать это как неопытность автора кода, чем как декларацию намерений. И, скорее всего, полезу в сорцы. Не проще ли написать по-человечески и задокументировать семантику?
И вообще этот больше смахивает на метод модели.
>когда я вижу метод, который возвращает ArrayList, я скорее буду воспринимать это как неопытность автора кода
в public методах пожалуй соглашусь
>написать по-человечески и задокументировать семантику
код по сути тоже может являться документацией. ведь юнит-тесты по сути документация.
да нет, как раз-таки это нормально - возвращать конкретный подкласс - так больше возможностей манипуляции с ним.
а вот на вход хорошая практика подавать интерфейсы
А просто "return bookList;" не дает ответа может ли возвращаться null или нет.
Поэтому, если меня просят что-то посмотреть требую описание методов. Хотя бы на любом сленге, которым обладает индивид. Вот это и есть "документация". Но, сами понимаете, еще надо найти понимающих свою же логику студентов :D
> bookList.add(author);
Оно будет работать раз в 5 медленней, верно?
Как скала обрабатывает пресловутые nullы?
2. В Scala не принято вообще использовать null. Пустые списки, как правило, инициализируются значением Nil, что в некотором роде аналогично Collections.emptyList(). Если результат поиска может быть неопределён (find в примере), возвращается инстанс класса Option, который может содержать, а может и не содержать значение (вызов isDefined в примере). Null в любом случае не возвращается.
а вообще писать на функциональных языках - огромное удовольствие.
от слова "поганый"?
fixed? :)
Что, в данном случае, обозначает символ _ ?
Глобальное пространство имен?