Прикосновение к объектно-ориентированному программированию

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

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.

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

ОТВЕТЫ

Ответ 1

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

A Soda can - это объект, объект имеет много свойств. И многие методы. Например..

SodaCan.Drink();

SodaCan.Crush();

SocaCan.PourSomeForMyHomies();

и т.д...

Цель OO Design - теоретически написать строку кода один раз и абстрагироваться между объектами.

Это означает, что Coder.Consume(SodaCan.contents); относится к вашему вопросу.

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

Многое, как я, употребляющее соду, не означает, что я - содовая баня.

Ответ 2

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

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

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

или

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

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

Ответ 8

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

public class Encoder
{
    private string videoPath; 

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

    public bool Encode() {

        ...snip...

        return true;
    }
}

Ответ 9

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

Является ли ООП хорошей идеей? Да.

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

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

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

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

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

Ответ 10

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

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