Теряясь в ООП joungle при попытке положить метод на правильное место и т.д.

Меня всегда поражало, насколько точны в этих ситуациях правила Роберта Гласса Правил трех . Не беспокойтесь о повторном использовании, пока у вас не будет трех мест, где может поместиться ваша функция. Мне всегда нравится писать функцию в первый раз, когда она мне нужна. Обратите внимание, что я дублирую его второй раз. И в третий раз сделайте работу по повторному использованию (преобразовав ее в служебную библиотеку).

Рефакторинг - это хорошо. Хотя вы, возможно, не захотите начинать с чтения этого тезиса о рефакторинге , это хорошее прочтение, которое рассматривает все в перспективе. Вы также можете проверить ответы на https://stackoverflow.com/questions/441896/how-to-be-master-in-c-and-object-oriated-technology , в которых есть книга по рефакторингу.

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

Добавление материала в Ответ Джейсона :

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

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

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

В вашем конкретном случае вы библиотека классов не нужна, так как есть только одна функция, поэтому я бы просто вставил ее в класс Helper. Однако если вы планируете добавить много полезных функций, тогда библиотека классов - хороший способ использовать код снова и снова. Но не добавляйте слишком много слоев в приложение, которое в этом не нуждается.

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

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

Я знаю, что это невозможно, если вы работаете со встроенными типами из BCL, но запах должен вас поразить. начал думать об альтернативах.

Давайте посмотрим на ваш пример: вы не можете добавить безопасный GetTempFile ни в System.String, ни в FileStream, но представляет ли какой-либо из параметров скрытую концепцию, которую было бы лучше смоделировать как объект?

Хотя я не знаю, правда ли это в вашем примере, но «extension» для меня звучит как концепция, так почему бы не определить класс Extension следующим образом:

public class Extension
{
    private readonly string extension;

    public Extension(string extension)
    {
        // Guard Clauses go here
        this.extention = extension;
    }

    public string GetTempFileSafe(out FileStream)
    {
        // implementation goes here, using this.extension...
    }
}

В качестве следующего шага вы можете изменить этот API, чтобы избавиться от параметра out , инкапсулируя результирующую строку и FileStream в новый объект.

По-видимому, вы говорите о C #, которого я не знаю. В наши дни я в основном занимаюсь Java, так что, возможно, есть техническая разница, но ...

В Java вы можете разделить ваши классы на «пакеты». Вы можете компилировать несколько пакетов одновременно, хранить их вместе в IDE и т. Д., Но их также легко разбить на части.

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

Таким образом, во время разработки он все еще является частью того же проекта, все еще в той же рабочей области и т. Д., Поэтому его легко отлаживать и в общем, чтобы отслеживать.

Если я никогда не использую его где-либо еще, найди, никакого вреда.

Если я использую его где-то еще, то иногда я ленив и просто копирую пакет в новый проект. Иногда я действительно делаю ее отдельной библиотекой. (И когда я говорю «изредка», я думаю, что в реальной жизни я имею в виду, что проделал это дважды за последние десять лет.)

Как я уже сказал, я не знаю, как C # группирует вещи, есть ли простой способ разбить набор классов на некую удобную «единицу».