Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am primarily a software developer, and as such, I do a lot of reading on the subject of Object Oriented Design; the 5 SOLID principles, design patterns, composition over inheritance etc.

I currently work as a PHP developer building web applications in Symfony 2. Along with learning to use an Agile/BDD/TDD approach to building web applications, I try to incorporate some OOD by searching out the abstractions and jotting down some interfaces for classes to communicate with (dependency inversion).

I was recently tasked with building a small, in-house CMS for a small, static website. This seemed a great opportunity to create, for example, an abstract "content" class and derive different types of content from it, or an interface for persisting content to the database. As it turned out, I didn't need any of the OOD knowledge that I have spent hours amassing. I just created Entities for each content type (albeit they derived from a base Entity), and I used the Symfony Form API to render forms for User input. Symfony functionality, when combined with Doctrine, handled all of the persisting to the DB. All that was left was to retrieve from the DB, process it, and pass it to the Twig template.

So in consideration of this, I imagine that even had the application been much larger, it seems that the nature of most web applications is to take user input, process it, perhaps persist it, and render a view. None of this seems to require any OOD knowledge or design pattern knowledge. My question is whether my time is wasted learning OOD, or if I shouldn't place such importance on it, as perhaps modern web application development doesn't really fit that realm of "software" development.

NB: I am aware that if I was to build a framework such as Symfony 2, then the OOD principles would apply, as that is truely building software from the ground up. My question is more related to when we use the Symfony (or any other) framework.

Edit

A better way to rephrase my question: do the majority of web application developers, whilst being rich in the knowledge of OOD, find that they needn't apply a vast majority of this knowledge when building web applications, because today's frameworks shelter you from such low level design. Does anyone have any examples of modules they have built that required Object Oriented methodology?

share|improve this question

closed as primarily opinion-based by Robert Harvey, psr, Dynamic, World Engineer Apr 20 at 17:07

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
What is the alternative to applying OOD? If you're learning, I would hardly call that a waste of time. –  Elliott Frisch Apr 1 at 20:33
    
Frameworks won't write ur business logic. –  Songo Apr 1 at 23:34

4 Answers 4

Everything can be written without using any of the Object Oriented paradigms. You can also write code without comments, good variable names, subroutines...All kinds of stuff.

In the long run, however, you generally end up saving time if you do it the proper way.

share|improve this answer
    
My point is, there doesn't seem to be much opportunity to incorporate OOD, as frameworks seem to have all bases covered for most typical web applications. I managed to write a fairly detailed CMS doing it the 'Symfony' way, and as a result, I wrote only one custom class from scratch (excluding Controllers and Entities). –  Alex Apr 1 at 21:11
1  
I think it's a bit disingenuous to suggest object-oriented programming is the only "proper way" to do things, especially when functional programming is essentially a superset of OOP with saner defaults. –  Doval Apr 2 at 11:41

Using a framework while not understanding the basic concept of OO will eventually give you a hard time. Knowing about OO will give you insight into when to use which design pattern, how to properly differentiate functionality and assign them to different classes etc. So in fact by learning how a framework is set up will provide you with a benefit for the future.

For instance. If you would continue developing non-namespaced, non-classes style, so pure functions alone; which is possible in Symfony. You would eventually find your code hard to maintain.

And perhaps you can compare your question with the following; 'why would I need to understand SQL statements, injections and prepared statements, when I have been able to create a fully functional application using Wordpress'. In fact plenty of developers just "use" wordpress without the knowledge to create safe, compatible and quality code. As such the result in some future for any of that code is to cause issues.

Another thing to consider is, without understanding the basics you are locked to this framework. Whereas having the knowledge, will make a move to another framework, whether willingly taken, much easier.

share|improve this answer
    
Well put, thank you. I have no doubt that there is an advantage to be had by learning OOD. I am curious if there are web application developers who are rich in OOD knowledge, yet rarely apply it when building web applications. –  Alex Apr 2 at 6:25
    
I am rich in OO knowledge and use Laravel and an in-house framework now. First is very OO, latter is somewhat OO. Even then, for small app's I still use the basics of OO without a framework, because sometimes it's just not necessary to use a whole "stack" (please allow me to abuse this term here) for a simple page or two with fixed jobs. –  Luceos Apr 2 at 7:45

In many applications, the 'web app' is one part of the project alongside many other apps with many other non-website purposes.

A trivial app could, for example, obtain input from a user, save it to a database, and redirect to a new page.

A more complex app might access several other internal applications, and perform additional business logic and background processes based on user input.

All of those systems typically reside "outside of the web app", where the emphasis is not on the web, but on representing the business processes and data that is served to that web app. Web Framework knowledge will not help here, instead the success of the project will depend on the domain modeling and implementation (OOP/FP/Architectural) skills of the team.

Related Concepts:

share|improve this answer

As @Songo's comment points out: "Frameworks won't write ur business logic". Once you get beyond simply processing a form and saving the information to a database right away, you'll most likely need some of the OOD knowledge to help you implement features in a maintainable, well structured way that future developers won't want to burn you at the sake for.

Let's take a look at common feature you might see in a CMS, in both a more-or-less procedural style and an object oriented style, as an example of the use of object oriented design in web application development.

File upload processing

Users can upload files alongside textual content. The CMS will process these files to determine whether it will allow them to be uploaded, and if so perform some further operations; for example removing exif data from images to protect privacy or adding some appropriate metadata to a PDF (like publisher, publish date etc).

Procedural style

class UploadController {
    public function uploadAction($filePath) {
        $handle = fopen($filePath);
        $fileType = $this->getFileTypeOfHandle($handle);

        try{
            switch($fileType){
                case "image/jpeg":
                    if($this->sizeOfHandle($handle) > 20000){
                        throw new FileRejectedException($ex)
                    }
                    $this->removeExifFromJpeg($handle);
                    break;

                case "image/png": 
                    // ..
                    break;
            }
        }
        catch(FileRejectedException $ex){
            $this->render("FileNotAllowed.twig.html");
            return;
        }

        $this->render("FileUploaded.twig.html");
    }
    // .. private functions ..
}

In the procedural style, you have all of your business logic for all types of files sitting in the controller method. Not only does this violate SRP by adding to the responsibilities of the controller, combining it all in one place makes it difficult to test in isolation; especially for operations like determining the type of an uploaded file, which can be quite complex.

Let's take a look at how we might better build this

Object oriented style

Here, private variables are injected dependencies. In this style you can clearly see the separation of concerns between the controller and the domain service MyUploadService, and then again inside the service between the handling of uploaded files and the determining of a file's type. Naturally, this separation of concerns makes the whole thing easier to test, extend etc.

Controller

class UploadController {
    private $myUploadService;

    public function uploadAction($filePath){
        $file = $this->getFileInstanceFromPath($filePath);
        try {
            $this->myUploadService->processUploadedFile($file);
        }
        catch(FileRejectedException $ex){
            $this->render("FileNotAllowed.twig.html");
            return;
        }

        $this->render("FileUploaded.twig.html");
    }
    // .. private functions ..
}

Service

class MyUploadService {
    private $fileTypeFinder;
    private $fileProcessorFactory;       

    public function processUploadedFile(\My\File $file){
        $type = $this->fileTypeFinder->determine($file);
        $processor = $this->fileProcessorFactory->create($type);

        if(!$processor->aceeptsFile($file)){
            throw new FileRejectedException();
        }

        $processor->process($file);
        $this->finaliseUploadedFile($file);
    }
}

Factory

class FileProcessorFactory {
    public function create($type){
        switch($type){
            case "image/jpeg":
                return new JpegFileProcessor();
                break;

            case "application/pdf":
                return new PdfFileProcessor();
                break;
            // ...
        }
    }
}
share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.