Отражение Java: порядок полей класса и методов стандартизирован?

Проверенные исключения в своей первоначальной форме были попыткой устранить непредвиденные обстоятельства, а не сбои. Похвальной целью было выделить конкретные предсказуемые точки (невозможно подключиться, файл не найден и т. Д.) & Amp; убедитесь, что разработчики справились с этим.

То, что никогда не было включено в первоначальную концепцию, заключалось в том, чтобы заставить широкий спектр системных & amp; неисправимые ошибки, которые будут объявлены. Эти сбои никогда не были правильными, чтобы быть объявленными как проверенные исключения.

Сбои, как правило, возможны в коде, а EJB, web & amp; Контейнеры Swing / AWT уже учитывают это, предоставляя внешний обработчик исключений «неудавшийся запрос». Самая основная правильная стратегия - откат транзакции & amp; вернуть ошибку.

Одним из важных моментов является то, что runtime & amp; проверенные исключения являются функционально эквивалентными. Не существует обработки или восстановления, которые могут делать проверенные исключения, чего не могут делать исключения во время выполнения.

Самый большой аргумент против «проверенных» исключений заключается в том, что большинство исключений нельзя исправить. Простой факт в том, что мы не владеем кодом / подсистемой, которая сломалась. Мы не можем видеть реализацию, мы не несем за нее ответственность и не можем ее исправить.

Если наше приложение не является БД, мы не должны пытаться исправить БД. Это нарушило бы принцип инкапсуляции .

Особенно проблематичными были области JDBC (SQLException) и RMI для EJB (RemoteException). Вместо выявления исправляемых непредвиденных обстоятельств в соответствии с первоначальной концепцией «проверенных исключений» эти широко распространенные проблемы принудительной системной надежности, которые на самом деле не устраняются,

Другим серьезным недостатком Java-дизайна было то, что обработка исключений должна быть правильно размещена на максимально возможном уровне «бизнес» или «запрос». Принцип здесь "бросай рано, лови поздно". Проверенные исключения мало что делают, но мешают этому.

У нас есть очевидная проблема в Java - требовать тысячи блоков без пробных попыток, при этом значительная часть (40% +) неправильно кодируется. Почти ни один из них не реализует никакой подлинной обработки или надежности, но накладывает большие накладные расходы на кодирование.

Наконец, «проверенные исключения» в значительной степени несовместимы с функциональным программированием на FP.

Их настойчивое требование «немедленно обрабатывать» противоречит как передовой практике «обработки с опозданием», так и любой структуре FP, которая абстрагирует циклы / или поток управления.

Многие люди говорят об «обработке» проверенных исключений, но говорят через свои шляпы. Продолжая после сбоя с нулевыми, неполными или неправильными данными, притвориться, что успех не обрабатывает ничего. Это халатность инженерии / надежности самой низкой формы.

Чистая неудача - самая основная правильная стратегия обработки исключения. Откат транзакции, запись ошибки & amp; Сообщения о «неудачном» ответе пользователю являются разумной практикой и, самое главное, предотвращают передачу неверных бизнес-данных в базу данных.

Другими стратегиями обработки исключений являются «повтор», «переподключение» или «пропуск» на уровне бизнеса, подсистемы или уровня запросов. Все они являются общими стратегиями надежности и работают хорошо / лучше с исключениями времени выполнения.

Наконец, гораздо предпочтительнее потерпеть неудачу, чем работать с неверными данными. Продолжение может вызвать вторичные ошибки, далекие от первоначальной причины & amp; сложнее отлаживать; или в конечном итоге приведет к ошибочным фиксации данных. За это людей увольняют.

См .:
- http://literatejava.com/exceptions/checked-exceptions-javas-biggest-mistake/

46
задан ivan_ivanovich_ivanoff 8 July 2009 в 12:51
поделиться

3 ответа

Согласно документации :

getFields ()

Возвращает массив, содержащий объекты Field, отражающие все доступные общедоступные поля класса или интерфейса, представленного этим Объект класса. Элементы в возвращаемом массиве не сортируются и не находятся в каком-либо определенном порядке. Этот метод возвращает массив длины 0, если у класса или интерфейса нет доступных общедоступных полей или если он представляет класс массива, примитивный тип или void.

getMethods ()

Возвращает массив, содержащий объекты Method, отражающие все общедоступные методы-члены класса или интерфейса, представленные этим объектом Class, в том числе объявленные классом или интерфейсом и унаследованные от суперклассов и суперинтерфейсов. Классы массивов возвращают все (общедоступные) методы-члены, унаследованные от класса Object. Элементы в возвращаемом массиве не сортируются и не находятся в каком-либо определенном порядке. Этот метод возвращает массив длины 0, если этот объект Class представляет класс или интерфейс, у которого нет открытых методов-членов, или если этот объект Class представляет примитивный тип или void.

61
ответ дан 26 November 2019 в 20:17
поделиться

Несмотря на то, что getFields () и getMethods () возвращают результаты в произвольном порядке, вы можете добавлять элементы из возвращенных массивов в коллекции и предоставлять свой собственный Comparator для их сортировки по своему усмотрению.

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

public void PrintClassData(Class c) {
    Field[] fieldArray = c.getFields();
    Method[] methodArray = c.getMethods();
    SortedSet<Field> fields = new TreeSet<Field>(new FieldComparator());
    fields.addAll(Arrays.asList(fieldArray));
    SortedSet<Method> methods = new TreeSet<Method>(new MethodComparator());
    methods.addAll(Arrays.asList(methodArray));

    StringBuffer b = new StringBuffer("All About ");
    b.append(c.getName());
    b.append("\nFields:\n");
    for(Field f : fields) {
        b.append("\t");
        b.append(Modifier.toString(f.getModifiers()));
        b.append(" ");
        b.append(f.getType());
        b.append(" ");
        b.append(f.getName());
        b.append("\n");
    }
    b.append("\nMethods:\n");
    for (Method m : methods) {
        b.append("\t");
        b.append(Modifier.toString(m.getModifiers()));
        b.append(" ");
        b.append(m.getReturnType());
        b.append(" ");
        b.append(m.getName());
        b.append("( ");
        for (Class param : m.getParameterTypes()) {
            b.append(param.getName());
            b.append(", ");
        }
        b.deleteCharAt(b.lastIndexOf(","));
        b.append(")\n");
    }
    System.out.println(b.toString());
}

private static class FieldComparator implements Comparator<Field> {

    public int compare(Field f1, Field f2) {
        return (f1.getName().compareTo(f2.getName()));
    }   
}

private static class MethodComparator implements Comparator<Method> {

    public int compare(Method m1, Method m2) {
        return (m1.getName().compareTo(m2.getName()));
    }

}
8
ответ дан 26 November 2019 в 20:17
поделиться

Образец моей идеи, основанной на аннотациях.

public class FiledOrder {
    @Retention(RetentionPolicy.RUNTIME)
    public @interface Order {
        int value();
    }
    public class SomeClass {
        @Order(value=2)
        public int field1;
        @Order(value=1)
        public int field2;
        // no annotation
        public int field3;
        @Order(value=1)
        public void start() { }
        @Order(value=2)
        public void end() { }
    }
    /**
     * @param args
     */
    public static void main(String[] args) {
        Field[] fields = SomeClass.class.getFields();
        Arrays.sort(fields, new Comparator<Field>() {
            @Override
            public int compare(Field o1, Field o2) {
                Order or1 = o1.getAnnotation(Order.class);
                Order or2 = o2.getAnnotation(Order.class);
                // nulls last
                if (or1 != null && or2 != null) {
                    return or1.value() - or2.value();
                } else
                if (or1 != null && or2 == null) {
                    return -1;
                } else
                if (or1 == null && or2 != null) {
                    return 1;
                }
                return o1.getName().compareTo(o2.getName());
            }
        });
        for (Field f : fields) {
            System.out.println(f.getName());
        }
        Method[] methods = SomeClass.class.getMethods();
        Arrays.sort(methods, new Comparator<Method>() {
            @Override
            public int compare(Method o1, Method o2) {
                Order or1 = o1.getAnnotation(Order.class);
                Order or2 = o2.getAnnotation(Order.class);
                // nulls last
                if (or1 != null && or2 != null) {
                    return or1.value() - or2.value();
                } else
                if (or1 != null && or2 == null) {
                    return -1;
                } else
                if (or1 == null && or2 != null) {
                    return 1;
                }
                return o1.getName().compareTo(o2.getName());
            }
        });
        for (Method m : methods) {
            System.out.println(m.getName());
        }
    }

}
36
ответ дан 26 November 2019 в 20:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: