надлежащий способ изолировать код, который должен быть изменен в будущем?

Question

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

Answer 1

Ниже приведено только мое мнение.

То, что вы должны и не должны делать:

• У вас есть очень большой метод. Поэтому я предполагаю, что это делает больше, чем одно. Я думаю, вы должны превратить это:

-

//Do thing 1 
xxx1(); 
xxx2(); 
xxx3(); 

//Do thing 2 
yyy1(); 
yyy2(); 
yyy3(); 

//Do thing 3 
zzz1(); 
zzz2(); 
zzz3{}; 

в этом:

doThing1(); 
doThing2(); 
doThing3(); 

и объявить эти методы:

private void doThing1() { 
    xxx1(); 
    xxx2(); 
    xxx3(); 
} 

private void doThing2() { 
    yyy1(); 
    yyy2(); 
    yyy3(); 
} 

private void doThing3() { 
    zzz1(); 
    zzz2(); 
    zzz3(); 
} 

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

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

• Если ваш редактор не позволяет этого, вы должны добавлять комментарии, чтобы рассказать об этом людям:

-

// MARK - things related to <insert name of large method here> 
private void doThing1() { 
    xxx1(); 
    xxx2(); 
    xxx3(); 
} 

private void doThing2() { 
    yyy1(); 
    yyy2(); 
    yyy3(); 
} 

private void doThing3() { 
    zzz1(); 
    zzz2(); 
    zzz3(); 
} 
// MARK - other stuff 
<insert other stuff here> 

• Вы также можете добавить распакованные методы внутренний класс для большей ремонтопригодности.

• Если извлекаемые методы растут все больше и больше, помните, чтобы разорвать их на куски, а

• Вы не должны поместить этот код в другой файл, если он тесно связан с классом.

• Если большой метод имеет несколько вещей, чтобы сделать с классом, рассмотреть вопрос о переходе его в отдельный класс