Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+79
/**
* @return
* true - если все строчки выделены,
* false - если все строчки не выделены,
* null - если есть как выделенные, так и не выделенные строчки
*/
private Boolean lookRowsDownwards(ColumnHolder rowHolder, boolean isPreviousRowsSelected) {это реализация переключателя с 3-мя состояниями
Запостил: 
Demetr,
06 Июля 2011
Follow us!
меня тоже порадовал
Либо после рефакторинга класс стал иметь более универсальную реализацию, но про название забыли или на него забили.
По сути, Boolean — трехзначный тип.
" boolean " 3116 раз
" Boolean " 141 раз
с возможным null не увидел использования, проглядел штук 20 случайным образом, только там, где надо объект возвращать. Ах, да, ещё " Boolean." 242 раза для выражений Boolean.TRUE и Boolean.False.
Что я делаю неправильно?
Первое же в возвращаемом значении: AbstractXMLSchema.getFeature. Дальше ImageIO.CacheInfo.getHasPermission, XMLComponent.getFeatureDefault (и перегрузка в дюжине классов), Timer.getFixedRate.
Среди членов-данных GroupLayout.ComponentInfo.honorsVisibili ty, NimbusDefaults.DerivedFont.bold и т.д.
А сколько среди этого всего с возвратом null?
Да и чего вы тут развели. Это же вообще дебильный эстетический вопрос. Я вот раньше просто не додумывался, что можно использовать Boolean и возвращать null. Просто потому, что не было необходимости делать подобное. Теперь знаю. Вам спасибо. Буду делать так, ежели необходимо вернуть состояние "не закрыта".
Никто и не утверждает, что это нужно часто, но бывает. Используется для возврата состояния не открыто или закрыто, а «фиг его знает, спёрли шкатулку». Если где встречается Boolean, нужно задуматься, а не может ли он быть null, и устроит ли нас NullPointerException.
Видимо, далеко мне еще до вашего New School. Или я просто не готов видеть в своих проектах модель поведения: открыто, закрыто, не закрыто ^_^
А вообще, как по мне, дак вы придаете излишнюю смысловую нагрузку простецкому классу-обертке.
П. С. Метод приватный + есть жавадок, вообще не вижу проблемы
Лучше использовать паттерн ValueContainer/Option/Optional/Nullable используется как некое_значение_любого_типа/не указано.
ВоВо. А эти паттерны уже реализованы в большинстве библиотек.
И да, в части языков - это есть в стандартной библиотеке.
Уж что, что, а городить велосипед ради одного места точно не стоит. Лучше воспользоваться либой.
Часто бывает надо работать с коллекциями. В java.utils.* действительно нет многого. Давайте подключим либу, например, Apache Collections. Все хорошо, пока не понадобился метод, которого нет в Apache, но он есть в Guava. Ну, давайте еще и Guava подключим. Мы счастливы, мы не изобретаем велосипед. Но вот опять встает задача, для которой нет метода в либе, но он есть еще в каких-либо collections. Давайте и их подключим. В итоге выходит, что подключена куча либов, которые на 90% если не больше делают одно и тоже. Помимо коллекций надо работать еще и со строками, и с xml и с прочей всякой фигней. И либы растут как снежный ком. Растет размер приложения. Если работает команда разработчиков, то каждый начинает использовать разные либы. Теряется общий стиль кода. Кому-то нравится new ArrayList(), кому-то Lists.arrayList(), кому-то Collections.newArrayList() или подобная фигня. Усложняется понимание кода, т. к. в разных либах методы делающие одно и то же часто называются по-разному, т. е. программисту дополнительно надо держать это в голове. Засирается PermGen. Когда программа не укладывается в 256Mb PermGen'а, это уже перебор.
Поэтому иметь самописный метод, проверяющий, что строка не пустая - это нормально. Пока нужен лишь один этот метод.
Подключение любой либы должно быть осмысленным, целесообразность должна быть доказана.
Очень часто бывает, что пригоняют ядерную боеголвку, когда достаточно было рогатки.
Вот когда-то мне нужен был простенький логгер. Что бы не подключать всякие log4j, как мне показалось, достаточно громоздкие, я написал маленький велосипед gargoyle.util.log.Log с одним СТАТИЧНЫМ методом Log.log(String,LEVEL);
Потом он немного разросся. И теперь в большинстве случаев он не нужен :)
Логгер - это уже фреймворк. Вот тут уж точно изобретать велосипеды не стоит. Это как свой jpa писать, или di-фреймворк, или xml парсить.
Просто надо выбирать один инструмент, и его использовать до тех пор, пока нет весомых аргументов в пользу другого.
не согласен в терминологии. Логгер - это библиотека. Разница (может быть, только для меня) в том, что фреймворк, в отличии от библиотеки, навязывает свою логику работы приложения (смежное, особенно для веба, понятие - IoC).
И если смена библиотеки относительно безболезненна (чаще просто хватает поменять имена), то смена фреймворка скорее аналогична переписыванию приложения.
Фреймворк, в моем понимании, несет набор законченой функциональности.
П. С. Погуглил, в очень многих местах написано log4j - logging framework
п.с. неважно, как во многих местах написано, важно, как называют на офсайте:
"The products of the Apache Logging Services Project included four logging frameworks"
(http://logging.apache.org/index.html)
Можно копировать нужный кусок из библиотеки, обрезая до собственной лайт-версии.
А если нужно изобретать свой велосипед -- то изучить подход в наиболее распространенных библиотеках, предоставляя похожий API - что бы, во-первых, не сбивать с толку остальных (сотрудников\поддержку\любопытных), во-вторых, что бы безболезненно подключить соотв. библу, когда это уже будет целесообразно
Неплохо бы такой же подход применять и в Джаве тоже
https://github.com/apache/poi/blob/trunk/src/ooxml/java/org/apache/poi/util/OOXMLLite.java
Единственное условие - код должен иметь хорошее покрытие тестами, так как при вычислении "нужных" классов анализируются классы, загруженные в процессе тестирования.
Хотя лучше бы int'ом сразу вернуть количество выделенных строчек.