Сохранение вспомогательных методов в той же области, что и у main_operation_methods, снижает читабельность.

У меня есть программа MineSweeper, в которой я сталкиваюсь со сценарием, похожим на.,

В чем моя проблема?

 class operation{

    <Data's needed for all operations> 
    /*(Each operation needs all the datas.)*/

   public  mainOperation(){ // user can call this mainOperation whenever they want to do some work.
       operation_ABC();
       operation_LMN();
    }

    private  void operation_ABC(){
    helper_DEF();  //This helper does partial work of ABC()
    helper_IJK();  //This helper does remaining work of ABC()     
    }

    private void DEF(){..//access and work on data..}
    private void IJK(){..//access and work on data..}       

    private void operation_LMN(){
    helper_OPQ();  
    < some work on data >
    helper_RST();  
    }

    private void helper_OPQ(){..//access and work on data...}
    private void helper_RST(){..//access and work on data...}    
    }

Что мне нужно?

Что мне нужно, так это какой-то способ сгруппировать методы и уменьшить видимость helper_DEF и helper_IJK в операции_ABC. Здесь я четко назвал операцию_ или помощник_, но реальный сценарий в моей программе таков....

private void backEndActionTaker(){
      <type: private void > initializeMinePlacer(); 
      <type: private void > mineValueAssigner();    
}

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

Что у меня получилось? Я планировал создать внутренние классы без каких-либо данных, но почувствовал две неловкие вещи.

 class operation_ABC{
    exec_ABC(){
      helper_1();
      helper_2();
    }
    private helper_1(){......//Access outer class data...}
    private helper_2() {.........}
  }
  1. создание класса без каких-либо данных-членов.
  2. всякий раз, когда мне нужно вызвать эту операцию, я должен создать объект и вызвать его (методы статических внутренних классов не будут работать, потому что вспомогательные методы обращаются к данным внешнего класса.)

person Muthu Ganapathy Nathan    schedule 11.12.2011    source источник


Ответы (1)


Если частные методы вызывают другие частные методы, это нормально. Если вы хотите улучшить читабельность, не используйте префиксы вроде «helper_» или «operation_», которые не являются стандартными, нарушают соглашения об именах и в любом случае мало что говорят о методе. Просто выберите четкие имена методов и задокументируйте их, используя комментарии javadoc.

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

person JB Nizet    schedule 11.12.2011
comment
как насчет моих внутренних классов. Являются ли они правильным способом сделать это? - person Muthu Ganapathy Nathan; 11.12.2011
comment
В этом случае, я думаю, они просто добавляют сложности без какой-либо пользы. - person JB Nizet; 11.12.2011
comment
Я. Непростая вещь, которую я чувствую, заключается в том, что оба метода OPERATION и HELPER являются закрытыми, и они находятся в одной и той же области (без различия между обоими). (Какой-либо способ улучшить читаемость) путем ограничения объема вспомогательного метода внутри метода операции? и я не могу получить заявление Разделение в частном вызове других частных методов в порядке. - person Muthu Ganapathy Nathan; 11.12.2011
comment
Я перефразировал фразу. Не беспокойтесь об этом. Наличие их в одном объеме является нормальным и распространенным явлением. Не переусердствуйте. - person JB Nizet; 11.12.2011
comment
Предполагая, что частные операции могут быть сгруппированы по сходной функциональности, добавление частных вложенных классов (с соответствующими именами) может быть использовано для улучшения организации класса. Поскольку они сами становятся более сложными, рассмотрите возможность их рефакторинга в частные классы верхнего уровня. На самом деле, это зависит от вас. Однако, как указано выше, часто методы в классе вызывают другие методы. - person Saish; 29.12.2011