Заблудиться в джойстике ООП при попытке поместить метод в нужное место и т. Д.

Question

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

Что лучше из примера? Поэтому мне нужно было загрузить файл во временный путь, и я решил получить временный путь не обычными методами точечной сети по неуместной причине. Поэтому я написал свой собственный метод для этого string GetTempFileSafe(string extension, out FileStream), хорошо, не так ли? Но эй, подожди минутку, это не подходящее место для этого метода ... Этот метод может быть использован для других целей. Это должен быть статический публичный метод где-то. но где? Ну, я думаю, мне нужно открыть новый статический класс для него. Надеюсь, я добавлю больше методов в другой день.

Итак, я определил public static class FileStreamUtils \\one hell of a name huh? и добавил к нему свой метод. Но держись .. Где этот класс должен быть? В принципе, я могу использовать любой проект ... это не имеет ничего общего с этим конкретным. Поэтому я открыл целую новую библиотеку, в которую позвонил MyUtils.

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

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

Так что вы думаете? Я просто плачу ни о чем, и такие вещи, как открытие библиотеки утилит, делаются в основном один раз, и мне просто нужно изменить свое отношение? Или вы думаете, что иногда лучше не слишком аккуратно придерживаться аккуратности (в моем случае, например, просто использовать метод там, а в случае , когда-нибудь он мне понадобится снова, переместить его в общий доступ использовать)?

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

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

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

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

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 в новый объект.

Answer 6

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

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