Getting my head around object oriented programming

I am entry level .Net developer and using it to develop web sites. I started with classic asp and last year jumped on the ship with a short C# book. As I developed I learned more and started to see that coming from classic asp I al开发者_如何学运维ways used C# like scripting language. For example in my last project I needed to encode video on the webserver and wrote a code like

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

        ...snip...

        return true;
    }
}

While searching samples related to my project I’ve seen people doing this

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; }
}

As I understand second example is more object oriented but I don’t see the point of using EncodedVideo object.

Am I doing something wrong? Does it really necessary to use this sort of code in a web app?

someone once explained OO to me as a a soda can.

A Soda can is an object, an object has many properties. And many methods. For example..

SodaCan.Drink();

SodaCan.Crush();

SocaCan.PourSomeForMyHomies();

etc...

The purpose of OO Design is theoretically to write a line of code once, and have abstraction between objects.

This means that Coder.Consume(SodaCan.contents); is relative to your question.

An encoded video is not the same thing as an encoder. An encoder returns an encoded video. and encoded video may use an encoder but they are two seperate objects. because they are two different entities serving different functions, they simply work together.

Much like me consuming a soda can does not mean that I am a soda can.

Neither example is really complete enough to evaluate. The second example seems to be more complex than the first, but without knowing how it will be used it's difficult to tell.

Object Oriented design is at it's best when it allows you to either:

1) Keep related information and/or functions together (instead of using parallel arrays or the like).

Or

2) Take advantage of inheritance and interface implementation.

Your second example MIGHT be keeping the data together better, if it returns the EncodedVideo object AND the success or failure of the method needs to be kept track of after the fact. In this case you would be replacing a combination of a boolean "success" variable and a path with a single object, clearly documenting the relation of the two pieces of data.

Another possibility not touched on by either example is using inheritance to better organize the encoding process. You could have a single base class that handles the "grunt work" of opening the file, copying the data, etc. and then inherit from that class for each different type of encoding you need to perform. In this case much of your code can be written directly against the base class, without needing to worry about what kind of encoding is actually being performed.

Actually the first looks better to me, but shouldn't return anything (or return an encoded video object).

Usually we assume methods complete successfully without exceptional errors - if exceptional errors are encountered, we throw an exception.

Object oriented programming is fundamentally about organization. You can program in an OO way even without an OO language like C#. By grouping related functions and data together, it is easier to deal with increasingly complex projects.

You aren't necessarily doing something wrong. The question of what paradigm works best is highly debatable and isn't likely to have a clear winner as there are so many different ways to measure "good" code,e.g. maintainable, scalable, performance, re-usable, modular, etc.

It isn't necessary, but it can be useful in some cases. Take a look at various MVC examples to see OO code. Generally, OO code has the advantage of being re-usable so that what was written for one application can be used for others over and over again. For example, look at log4net for example of a logging framework that many people use.

The way your structure an OO program--which objects you use and how you arrange them--really depends on many factors: the age of the project, the overall size of the project, complexity of the problem, and a bit for just personal taste.

The best advice I can think of that will wrap all the reasons for OO into one quick lesson is something I picked up learning design patterns: "Encapsulate the parts that change." The value of OO is to reuse elements that will be repeated without writing additional code. But obviously you only care to "wrap up" code into objects if it will actually be reused or modified in the future, thus you should figure out what is likely to change and make objects out of it.

In your example, the reason to use the second set up may be that you can reuse the EncodedVideo object else where in the program. Anytime you need to deal with EncodedVideo, you don't concern yourself with the "how do I encode and use video", you just use the object you have and trust it to handle the logic. It may also be valuable to encapsulate the encoding logic if it's complex, and likely to change. Then you isolate changes to just one place in the code, rather than many potential places where you might have used the object.

(Brief aside: The particular example you posted isn't valid C# code. In the second example, the static method has no return type, though I assume you meant to have it return the EncodedVideo object.)

This is a design question, so answer depends on what you need, meaning there's no right or wrong answer. First method is more simple, but in second case you incapsulate encoding logic in EncodedVideo class and you can easily change the logic (based on incoming video type, for instance) in your Encoder class.

I think the first example seems more simple, except I would avoid using statics whenever possible to increase testability.

public class Encoder
{
    private string videoPath; 

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

    public bool Encode() {

        ...snip...

        return true;
    }
}

Is OOP necessary? No.

Is OOP a good idea? Yes.

You're not necessarily doing something wrong. Maybe there's a better way, maybe not.

OOP, in general, promotes modularity, extensibility, and ease of maintenance. This goes for web applications, too.

In your specific Encoder/EncodedVideo example, I don't know if it makes sense to use two discrete objects to accomplish this task, because it depends on a lot of things.

For example, is the data stored in EncodedVideo only ever used within the Encode() method? Then it might not make sense to use a separate object.

However, if other parts of the application need to know some of the information that's in EncodedVideo, such as the path or whether the status is successful, then it's good to have an EncodedVideo object that can be passed around in the rest of the application. In this case, Encode() could return an object of type EncodedVideo rather than a bool, making that data available to the rest of your app.

Unless you want to reuse the EncodedVideo class for something else, then (from what code you've given) I think your method is perfectly acceptable for this task. Unless there's unrelated functionality in EncodedVideo and the Encoder classes or it forms a massive lump of code that should be split down, then you're not really lowering the cohesion of your classes, which is fine. Assuming you don't need to reuse EncodedVideo and the classes are cohesive, by splitting them you're probably creating unnecessary classes and increasing coupling.

Remember: 1. the OO philosophy can be quite subjective and there's no single right answer, 2. you can always refactor later :p