Is Object Oriented Design necessary when building Symfony web apps? [closed]

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.

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.

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:

• http://en.wikipedia.org/wiki/Service-oriented_architecture
• http://en.wikipedia.org/wiki/Application_programming_interface

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