Разбираться с объектно-ориентированным программированием

Question

Я начинающий разработчик .Net и использую его для разработки веб-сайтов. Я начал с классического жереха и в прошлом году прыгнул на корабль с короткой книгой на C #. По мере развития я узнал больше и начал понимать, что исходя из классического asp, я всегда использовал C # -подобный язык сценариев. Например, в моем последнем проекте мне нужно было закодировать видео на веб-сервере и написать код, подобный

public class Encoder
{
    Public static bool Encode(string videopath) {

        ...snip...

        return true;
    }
}

При поиске примеров, связанных с моим проектом, я видел людей, которые делают это

public class Encoder
{
    Public static Encode(string videopath) {
        EncodedVideo encoded = new EncodedVideo();

        ...snip...

        encoded.EncodedVideoPath = outputFile;
        encoded.Success = true;

        ...snip...
    }
}

public class EncodedVideo
{
    public string EncodedVideoPath { get; set; }
    public bool Success { get; set; }
}

Как я понимаю, второй пример является более объектно-ориентированным, но я не вижу смысла в использовании объекта EncodedVideo.

Я что-то не так делаю? Действительно ли необходимо использовать такой код в веб-приложении?

Answer 1

кто-то однажды объяснил мне OO как банку содовой.

Сода может это объект, объект имеет много свойств. И много методов. Например ..

SodaCan.Drink ();

SodaCan.Crush ();

SocaCan.PourSomeForMyHomies ();

и т.д ...

Цель OO Design теоретически состоит в том, чтобы один раз написать строку кода и иметь абстракцию между объектами.

Это означает, что Coder.Consume (SodaCan.contents); относительно вашего вопроса.

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

Так же, как я потребляю банку содовой, это не значит, что я банку содовой.

Answer 2

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

Объектно-ориентированный дизайн лучше всего подходит, если он позволяет:

1) Храните связанную информацию и / или функции вместе (вместо использования параллельных массивов и т. П.).

Или

2) Воспользуйтесь преимуществами наследования и реализации интерфейса.

Ваш второй пример МОЖЕТ лучше хранить данные вместе, если он возвращает объект EncodedVideo, и об успехе или неудаче метода необходимо следить за фактом. В этом случае вы заменили бы комбинацию логической переменной «success» и пути одним объектом, четко документируя отношение двух частей данных.

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

Answer 3

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

Помните: 1. Философия ОО может быть весьма субъективной, и нет единого правильного ответа, 2. Вы всегда можете рефакторинг позже: p

Answer 4

Нужно ли ООП? Нет.

ООП - хорошая идея? Да.

Вы не обязательно делаете что-то не так. Может быть, есть лучший способ, а может и нет.

ООП, как правило, способствует модульности, расширяемости и простоте обслуживания. Это касается и веб-приложений.

В вашем конкретном примере Encoder / EncodedVideo я не знаю, имеет ли смысл использовать два отдельных объекта для выполнения этой задачи, потому что это зависит от многих вещей.

Например, данные, хранящиеся в EncodedVideo, используются только когда-либо в методе Encode()? Тогда может не иметь смысла использовать отдельный объект.

Однако, если другие части приложения должны знать некоторую информацию, содержащуюся в EncodedVideo, например, путь или статус успешен, тогда хорошо иметь объект EncodedVideo, который можно передавать в остальной части приложения. В этом случае Encode() может возвращать объект типа EncodedVideo, а не bool, делая эти данные доступными для остальной части вашего приложения.

Answer 5

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

public class Encoder
{
    private string videoPath; 

    public Encoder(string videoPath) {
        this.videoPath = videoPath;
    }

    public bool Encode() {

        ...snip...

        return true;
    }
}

Answer 6

Это вопрос дизайна, поэтому ответ зависит от того, что вам нужно, то есть нет правильного или неправильного ответа. Первый способ более прост, но во втором случае вы инкапсулируете логику кодирования в классе EncodedVideo и можете легко изменить логику (например, на основе типа входящего видео) в своем классе Encoder.

Answer 7

То, как ваша структура ОО-программы - какие объекты вы используете и как вы их упорядочиваете - действительно зависит от многих факторов: возраста проекта, общего размера проекта, сложности проблемы и немного только для личного вкуса.

Лучший совет, который я могу придумать, заключит все причины ОО в один быстрый урок - это то, что я подобрал, изучая шаблоны проектирования: «Инкапсулируйте части, которые меняются». Целью ОО является повторное использование элементов, которые будут повторяться без написания дополнительного кода. Но очевидно, что вам нужно «обернуть» код в объекты только в том случае, если он будет фактически использован повторно или изменен в будущем, поэтому вам следует выяснить, что может измениться, и сделать из него объекты.

В вашем примере причина использования второй настройки может заключаться в том, что вы можете повторно использовать объект EncodedVideo в другом месте программы. В любое время, когда вам нужно иметь дело с EncodedVideo, вы не заботитесь о том, «как я кодирую и использую видео», вы просто используете объект, который у вас есть, и доверяете ему для обработки логики. Также может быть полезно инкапсулировать логику кодирования, если она сложна и может измениться. Затем вы изолируете изменения только в одном месте кода, а не во многих потенциальных местах, где вы могли бы использовать объект.

(Вкратце: конкретный пример, который вы опубликовали, не является допустимым кодом C #. Во втором примере у статического метода нет возвращаемого типа, хотя я предполагаю, что вы хотели, чтобы он возвращал объект EncodedVideo.)

Answer 8

Вы не обязательно делаете что-то не так. Вопрос о том, какая парадигма работает лучше всего, является спорным и вряд ли будет иметь явный победитель, поскольку существует так много разных способов измерения «хорошего» кода, например. ремонтопригодный, масштабируемый, производительный, многоразовый, модульный и т. д.

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

Answer 9

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

Answer 10

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

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