Излишняя абстракция объектно-ориентированного дизайна (удалена только для 10k).

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

Не относится строго к Java, но вызывает дорогостоящую функцию снова и снова вместо сохранения результата, когда вы знаете, что он не изменится. Пример:

if (expensiveFunction() > aVar)
    aVar = expensiveFunction();
for (int i=0; i < expensiveFunction(); ++i)
    System.out.println(expensiveFunction());

Подобно вашему, но сделал еще один шаг вперед:

Использование переменных класса (статических), когда переменная с областью действия запроса была правильным действием в действии Struts. : O

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

Ненавижу, когда люди создают интерфейсы только для того, чтобы вешать набор констант:

public interface InterfaceAntiPattern {
  boolean BAD_IDEA = true;
  int THIS_SUCKS = 1;
}

- Интерфейсы предназначены для определения поведенческих контрактов, а не удобного механизма для включения констант.

Создание подклассов, когда вы не должны этого делать, например вместо использования композиции, агрегирования и т. д.

Обновлено: это особый случай молот.

Абстрагирование функциональности в библиотечный класс который никогда не будет использоваться повторно, поскольку он настолько специфичен для решаемой исходной проблемы.. Таким образом, мы получаем огромное количество библиотечных классов, которые никто никогда не будет использовать и которые полностью заслоняют две полезные утилиты, которые у вас есть на самом деле делать (то есть CollectionUtils и IOUtils).

... паузы для вздоха ...

Мне пришлось поддерживать java-код, где большая часть обработки исключений была такой:

catch( Exception e ) {}

Наш стажер использовал модификатор static для сохранения текущего пользователя в приложении Seam.

 class Identity{
    ...
    public static User user; 
    ...
 }

 class foo{

    void bar(){
       someEntity.setCreator(Identity.user); 
    }

 }

Конечно сработало, когда он его тестировал :)

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

Нелепая объектно-ориентированная мания с иерархией классов глубиной 10+ уровней.

Отсюда и названия типа DefaultConcreteMutableAbstractWhizzBangImpl. Просто попробуйте отладить такой код - вы часами будете метаться вверх и вниз по дереву классов.

@madlep Совершенно верно! Часть сообщества Java действительно переборщила с экстремальными абстракциями и безумно глубокой иерархией классов. Пару лет назад у Стива Йегге был хороший пост в блоге: Казнь в царстве существительных.

if{
 if{
  if{
   if{
    if{
     if{
      if{
       if{
         ....

Однажды мне пришлось исследовать веб-приложение, в котором ВСЕ состояние сохранялось на веб-странице, отправляемой клиенту, а не состояние на веб-сервере.

Хотя хорошо масштабируется :)

Шесть действительно плохих примеров;

• Вместо сообщения об ошибках просто System.exit без предупреждения. например,
  if (properties.size()>10000) System.exit(0); похоронен глубоко в библиотека.
• Использование строковых констант как замки. например synchronized("one") { }.
• Блокировка изменяемого поля. например synchronized(object) { object = ...; }.
• Инициализация статических полей в конструкторе.
• Запуск исключения только для получения трассировки стека. например try { Integer i = null; i.intValue(); } catch(NullPointerException e) { e.printStackTrace(); }.
• Бессмысленное создание объекта, например. new Integer(text).intValue() or worse new Integer(0).getClass()

Мой любимый алгоритм сортировки, любезно предоставленный бригадой седобородых:

List needsToBeSorted = new List ();
...blah blah blah...

Set sorted = new TreeSet ();
for (int i = 0; i < needsToBeSorted; i++)
  sorted.add (needsToBeSorted.get (i));

needsToBeSorted.clear ();
for (Iterator i = sorted.iterator (); i.hasNext ();)
  needsToBeSorted.add (i.next ());

По общему признанию, это сработало, но в конце концов я убедил его, что, возможно, Collections.sort будет намного проще.

Как только я обнаружил исключение singleton:

class Singletons {
    public static final MyException myException = new MyException();
}

class Test {
    public void doSomething() throws MyException {
        throw Singletons.myException;
    }
}

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

API, требующий от вызывающего:

Foobar f = new Foobar(foobar_id);
f = f.retrieve();

Лучше было бы любое из следующего:

Foobar f = Foobar.retrieve(foobar_id);

или же

Foobar f = new Foobar(foobar_id); // implicit retrieve

или же

Foobar f = new Foobar();
f.retrieve(foobar_id); // but not f = ...

Не закрывать соединения с базой данных, дескрипторы файлов и т. д. В finally {}

Создание аксессоров и мутаторов для частных переменных все, не задумываясь, иногда автоматически.

Инкапсуляция была изобретена неспроста.

Ошибка молодых программистов: без необходимости использовать переменные-члены вместо локальных.

Пример Java EE:

Запуск потоков в сервлетах или EJB (например, для запуска задач асинхронной обработки).

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

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

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

В Java есть сборка мусора, если вам нужен объект, создайте новый.

Определение логики с использованием исключений, где будет достаточно цикла for или любой формы цикла.

Пример:

while(i < MAX_VALUE)
{
   try
   {
      while(true)
      {
         array[j] = //some operation on the array;
         j++;  

      }
   }
   catch(Exception e)
   {
      j = 0;
   }
}

Серьезно, я знаю парня, который написал этот код. Я просмотрел и поправил код :)

Пару минут назад я видел эту строчку:

Short result = new Short(new Integer(new Double(d).intValue()).shortValue());

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

    public DataObjectList (GenerateList (massive signature involving 14 parameters, three of which are collections and one is a collection of collections) 
try { 

250 lines of code to retrieve the data which calls a stored proc that parses some of it and basically contains GUI logic

 } catch (Exception e) {
            return new DataObjectList(e, filterFields);
        }

Итак, я попал сюда, потому что мне было интересно, почему следующий метод вызова дал сбой, и я не мог видеть, где было установлено поле Exception.

DataObjectList dataObjectList= EntireSystemObject.getDataObjectList Generator().generateDataObjectList (viewAsUserCode, processedDataRowHandler, folderQuery, pageNumber, listCount, sortColumns, sortDirections, groupField, filters, firstRun, false, false, resetView);

dataObjectList.setData(processedDataRowHandler.getData());

if (dataObjectList.getErrorException() == null) {

do stuff for GUI, I think, put lots of things into maps ... 250 lines or so

       }
            return dataObjectList;
        } else {

put a blank version into the GUI and then  

            throw new DWRErrorException("List failed due to list generation error", "list failed due to list generation error for folder: " + folderID + ", column: " + columnID, List.getErrorException(), ListInfo);
        }

Все пока со мной?

Ну, по крайней мере, они сказали нам во внешнем интерфейсе, что что-то действительно пошло не так!

AbstractSpringBeanFactoryFactoryFacadeMutatorBeanFactory. Я терпеть не могу эту надуманную, непонятную чушь. Бенджи Смит делает это немного элегантнее.

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

int sval, eval, stepv, i;
double d;
                if (/*someCondition*/)
                    {
                    sval = 360;//(all values multiplied by 20)
                    eval = -271;
                    stepv = -10;
                    }
                else if (/*someCondition*/)
                    {
                    sval = 320;
                    eval = -601;
                    stepv = -10;
                    }
                else if (/*someCondition*/)
                    {
                    sval = 0;
                    eval = -311;
                    stepv = -10;

                    }
                    else
                    {
                    sval = 360;
                    eval = -601;
                    stepv = -10;
                    }
                for (i = sval; i > eval; i = i + stepv)
                    {
                    d = i;
                    d = d / 20.0;
                    //do some more stuff in loop
                    }

оказывается, он хотел повторить цикл на 0,5 и это не ошибка вставки, это схема отступов

В файловом вводе-выводе: некорректное использование блока try-catch.

try {
   /* open file */
}
catch(Exception e) {
  e.printStackTrace();
}

try {
   /* read file content */
}
catch (Exception e) {
  e.printStackTrace();
}

try {
   /* close the file */
}
catch (Exception e) {
  e.printStackTrace();
}

видел что-то вроде этого:

public static boolean isNull(int value) {
    Integer integer = new Integer(value);

    if (integer == null) {
        return true;
    } else {
        return false;
    }
}

У них был аналогичный метод для лонгов.

Я предполагаю, что они изначально сделали что-то вроде

if (value == null) {

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

Не думать так, как следовало бы программисту.

После длительного воздействия Java делает это с некоторыми людьми.

Почему? Я считаю, что это потому, что есть слишком много Intellisense и никакого смысла. Он позволяет делать глупые вещи так быстро, что люди не перестают думать.

Пример 1:

boolean negate( boolean shouldNegate, boolean value ) {
  return (shouldNegate?(!value):value;
}

который, конечно, совпадает со значением ^ shouldNegate, простым XOR.

Пример 2: (клянусь, я не выдумываю)

boolean isNotNull( Object o ) {
  return o != null;
}

Оба с дополнительными 4-6 строками Javadoc, объясняя, что эти методы сделали.

Пример 3:

/**
*
*
*/

Пустой документ Javadoc, чтобы убрать эти предупреждения раздражающий Eclipse об отсутствии Javadoc.

Пример 3b:

/**
* A constructor. Takes no parameters and creates a new instance of MyClass.
*/
public MyClass() {
}

Преобразование простого XML-сообщения (без XSD / пространств имен) в DataObject:

DataObject operation_file = boFactory....

try{operation_file.setString("file_name", Constants.getTagValue("file_name", eElementOp));}catch (Exception e){operation_file.setString("file_name","");}
try{operation_file.setDate("proposed_execution_date", sdf.parse(Constants.getTagValue("proposed_execution_date", eElementOp)));}catch (Exception e){operation_file.setString("proposed_execution_date",null);}
try{operation_file.setString("instructions", Constants.getTagValue("instructions", eElementOp));}catch (Exception e){operation_file.setString("instructions","");}
try{operation_file.setString("description", Constants.getTagValue("description", eElementOp));}catch (Exception e){operation_file.setString("description","");}

Я назвал это программированием, ориентированным на попытки отлова (tcop) ...

Огромные имена классов. Помню: AbstractTableComponentListeningBehaviourPanel.java и другие подобные монстры.

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