Design Patterns – Do Frameworks Make Learning Design Patterns Unnecessary?

design-patternsframeworksjava-eespring

I don't want to say that is not necessary knowing design patterns. I just want to tell you my experience.

I've used Spring frameworks for four years and another frameworks (JSF, Mybatis, Hibernate, etc) in various projects where I've participated (I work as Java Developer). In all this time, I've used few design patterns. Knowing Design patterns haven't been necessary for building medium and inclusive large java web applications.

It's a few shameful saying that I only have used MVC, DAO and Factory patterns. Maybe, other two more…but I don't remember

I'm awareness that It's no good and I should improve (I'm trying to learn more about design patterns).

Firstly, I would like if someone has had the same experience that me. Secondly, if could you give information about Use of design patterns with frameworks Java (This is because is almost impossible I leave to use Java frameworks but I know I need to use design patterns for good practice).

Best Answer

Most frameworks already use a lot of known software design patterns. So you are using design patterns unknowingly.

That said, I would strongly suggest you to try learning at least the most common ones. It's funny.

In the other hand, in a framework, your classes "fall into place" within the design of the framework, but you have to code your business logic anyways. And, in that scope, design patterns do still apply. Patterns do not only apply at an "architechtural" level but also at the level of business logic. Chances are parts of your domain classes or controlers have to solve problems that benefit from some design patterns. The so called behavioral design patterns are most likely to be used in business logic, since most frameworks already take care of the creational and structural aspects.

So the bottomline would be, no. Working mostly with frameworks doesn't mean you can no longer benefit from knowing design patterns. And, as I said before, they are fun to learn and use. To my opinion.

Related Solutions

Maven and Spring – Organizing Maven Modules and Spring Profiles

I would not recommend to put multiple build targets in single Maven project and perform the app customization during build via Spring profiles. This solution is hard to support, because it has reduced visibility of the functionality belonging to specific application/execution context.

Plugin architecture would be better choice here, because it clearly separates the common code from the customer specifics. How can you do that?

Project structure

  project
    core
      pom.xml
    feature1
      pom.xml
    feature2
      pom.xml
    app1
      pom.xml
    app2
      pom.xml

Here you have common functionality in core module and two apps for different customers, that include the core and some of the features as dependencies. "mvn integration-test" of the root project compiles the core, the features and the source code of apps and runs tests, but does not assembly the apps. You can assembly the specific app by building its module.

Application architecture

The core module is an app that can run itself - it contains all necessary infrastructure and minimal functionality. It provides optional interfaces for plugins and configuration API, which allow customization per customer.

Every feature module from above example is a plugin, extending some of the core interfaces. You may use OSGi, but the simplest solution will be to use runtime discovery of Spring application context configurations (you can use web fragments from Servlet 3.0 or let your default configuration include all files from classpath located in, say, '/META-INF/my-spring-plugins'). There you can put all additional configuration and define plugin beans. Let's say for some customer you need a feature A, accessible via REST API as an action on some entity. You can define a component, that will collect list of actions from beans implementing IActionProvider interface. In feature A plugin you implement this interface and return the action definition for this feature.

The app module is a plugin too: it can extend the interfaces that control application branding, database configuration, enterprise integration configuration etc.

Java – Best Way to Deliver and Deploy JEE Applications to Clients

Swarm, Spring Boot, Dropwizard - they're just microcontainers, instead of packaging your app as a war and running that in a container you are packaging the AS tooling inside your app.

There's a good comparison here: https://github.com/simundi/micro-containers

Best Answer

Related Solutions

Maven and Spring – Organizing Maven Modules and Spring Profiles

Java – Best Way to Deliver and Deploy JEE Applications to Clients

Related Topic