Как / Когда писать повторно используемые методы в ООП

Question

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

Мой вопрос: какие шаблоны мы должны искать, которые указывают на то, что мы должны создать новый метод. Я ценю ваш ответ.

Answer 1

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

Например, вы хотите разработать приложение, которое может индексировать содержимое PDF-файлов.Это просто выдумка, но на первый взгляд, я мог бы выделить по крайней мере три компонента:

1. PdfParser - он предоставляет вам содержимое pdf
2. Indexer - получает ввод от парсера исчитает значимые слова
3. Хранилище - это для настойчивости;это можно сделать общим;просто скажите repository.Get<IndexData>(filename) или что-то

Вы также должны попытаться кодировать с интерфейсами.Особенно когда задействован какой-то интерфейс.Например, вы разрабатываете чат-клиент с WinForms.Если вы следуете шаблону MVC / MVVM , вы можете легко (т.е. проще, чем кодировать объект Form) использовать исходную логику с версией клиента WPF.

Answer 2

Я бы начал с чтения принципа СУХОЙ (не повторяйте себя), надеюсь, он даст вам хороший ответ на ваш вопрос, который, кстати, всем разработчикам следует задавать себе, отличный вопрос !!

Смотри Не повторяйся

Я хотел оставить это в DRY, потому что это такая простая, но мощная концепция, которая потребует некоторого чтения и большой практики, чтобы получить хорошее дополнение. Но позвольте мне попытаться ответить прямо на ваш вопрос (ИМХО),

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

Вы обнаружите, что СУШИТЕ свой код с легкостью, появятся многократно используемые фрагменты, и вы, вероятно, никогда не обнаружите, что повторяете код.

Я бы сделал это, даже если бы это означало иметь методы только с несколькими строками кода.

Следуя этой практике, вы придадите смысл своему коду, сделаете его читабельным и предсказуемым , и определенно больше многоразовым

Answer 3

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

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

• Как программисты практикуют повторное использование кода
• Какие методы вы используете для максимального повторного использования кода?
• Повторное использование кода: оно того стоит?
• Приоритеты кодирования: производительность, ремонтопригодность, возможность повторного использования?

Answer 4

Вы можете создать локальную переменную внутри вашей функции типа Action<> или Func<> и присвоить ей фрагмент кода. Затем вы можете использовать его везде внутри вашей функции, не загрязняя ваш класс слишком большим количеством вспомогательных функций.

Answer 5

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

Answer 6

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