Как изменить дизайн возвращаемого значения в ОО манере?

Question

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

В моем случае я вижу многое из этого:

        if (ret == 1) {
            out.print("yadda yadda");
        } else if (ret == 2) {
            out.print("yadda yadda");
        } else if (ret == 3) {
            out.print("yadda yadda");
        } else if (ret == 0) {
            out.print("yadda yadda");
        } else if (ret == 5) {
            out.print("yadda yadda");
        } else if (ret == 6) {
            out.print("yadda yadda");
        } else if (ret == 7) {
            out.print("yadda yadda");
        }

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

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

Ваш вклад, пожалуйста?

Answer 1

Это ИМХО две совершенно разные вещи:

OO-против-OO дизайн

и

дизайн на основе исключений и возвращаемых значений.

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

Что касается вашей кодовой базы: я бы порекомендовал целостный анализ всего программного обеспечения, а затем немного подумать над тем, является ли хорошей идеей отказ от кодов возврата. Будет ли программное обеспечение расширяться в будущем? Или это просто мертвый лес, лежащий где-то для выполнения одной конкретной задачи?

Я бы порекомендовал прочитать "рефакторинг" и "устаревший код". Люди вокруг меня говорят, что «Эффективная работа с устаревшим кодом» Майкла Фезерса - очень солидная и рекомендуемая книга. Так что это может вам очень помочь.

Удачи!

Answer 2

Но это Java (не C ++). Поэтому, если вы работаете с «кодами», вам следует работать с Enums. А используя Enums (или целые числа, между прочим), вы можете использовать оператор switch (), чтобы значительно улучшить код.

public abstract class Example {

    protected abstract ErrorCode test();

    public void run() {
       ErrorCode code=test();
       switch(code) {
           case OK: 
               System.out.println("All ok"); 
           break;
           case OOPS: 
               System.out.println("Oops, an error occurred.");
           break;
           case OTHER_ERROR: 
               System.out.println("A different error occurred");
           break;
           case UNKNOWN_ERROR: 
               System.out.println("Yet another, unknown error occurred.");
           break;
       }
    }

    public static enum ErrorCode {
        OK, OOPS, OTHER_ERROR, UNKNOWN_ERROR;
    }
}

Это может быть расширено, чтобы придать ему еще один вид Continuation Passing Style; путем определения метода обратного вызова для ErrorCode и вызова этого метода вместо выполнения оператора switch ().

Answer 3

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

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

Answer 4

По общему мнению, исключения не должны использоваться для потока управления. Однако сообщество Python, похоже, думает иначе.

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

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

Answer 5

В соответствии с подходом if-else, я приведу лишь подсказку, если вы хотите пойти дальше.Вы определенно можете использовать шаблон состояний .

Class State{
   public:
       virtual void showInfo()=0;

}

class Iddle:public State{
    public:
       void showInfo(){
        std.cout<<"I've just initialized"<<std.endl;
        };

}

class Wrong:public State{

   public:
       void showInfo(){
        std.cout<<"Something goes wrong"<<std.endl;
        };

}
main()
{
boost::scoped_ptr<State> mystate = new Iddle();

mystate->showInfo();

.....
mystate.reset(new Wrong());
....
mystate->showInfo();

}

. Вы можете реализовать все, что захотите, в нужных состояниях.Таким образом, вы выбросите if-elses.Именно так ваша общая функция «catch» может устанавливать состояния.Это, конечно, может использоваться обычными системными задачами, поэтому любой главный компонент будет знать, в каком состоянии и какие действия необходимо выполнить.

Упрощает:

, если у вас возникнет исключениеустановите состояние Wrong, затем завершите поток, остановите действие или любой другой объект, ответственный за сбой.У вас все еще будет состояние, вы правильно обработали исключение, но у вас все еще будут некоторые состояния, которые могут послужить основой для принятия соответствующих действий в другом потоке.