• Pojo-based lightweight and least intrusive programming;

    If you’ve been programming In Java for a while, you’ve probably noticed (and probably used) that many frameworks tie applications to the framework by forcing them to inherit their classes or implement their interfaces. A classic example is stateless session beans from the EJB2 era. This intrusive approach to programming can be seen in earlier versions of Struts, WebWork, Tapestry, and countless other Java specifications and frameworks.

    Spring tries to avoid messing up your application code with its apis. Spring doesn’t force you to implement interfaces or classes that inherit from the Spring specification. Instead, applications built on Spring usually have classes that don’t show any evidence that you use Spring. The worst case scenario is that a class might use Spring annotations, but it’s still a POJO

    As you can see, this is a simple, plain Java class, POJO. Nowhere does it indicate that it is a Spring component. Spring’s non-intrusive programming model means that this class can play the same role in both Spring and non-Spring applications

    Although the form may seem simple, POJOs can be magical. One of the ways Spring brings magic to POJos is by assembling them through DI. Helps application objects remain loosely coupled to each other.

  • Loose coupling is achieved through dependency injection and interface orientation

    • The dependencies of the dependency injection objects are set when the objects are created by the third-party components in the system that coordinate the objects. Objects do not have to create or manage their dependencies themselves

    • Interface oriented programming

  • Declarative programming based on aspects and conventions;

    • Faceted DI allows for loose coupling between cooperating software components, while aspect-oriented Programming (AOP) allows you to separate functionality across your application into reusable components.

      Section-oriented programming is often defined as a technique that enables software systems to implement separation of concerns. A system consists of many different components, each responsible for a specific piece of functionality. In addition to fulfilling their core functions, these components often take on additional responsibilities. System services such as logging, transaction management, and security are often integrated into components that have their own core business logic. These system services are often referred to as crosscutting concerns because they span multiple components of the system.

      If you spread these concerns across multiple components, your code introduces a double layer of complexity.

      • The code that implements the functionality of the system concerns is repeated in multiple components. This means that if you want to change the logic of these concerns, you have to modify the relevant implementation in each module. Even if you abstract these concerns into a single module, and other modules just call its methods, the method calls are repeated in each module.
      • Components can become cluttered with code that has nothing to do with their core business. A method that adds an address entry to an address book should focus only on how to add the address, not whether it is secure or needs to support transactions.

      AOP can modularize these services and declaratively apply them to the components they need to affect. The result is that these components are more cohesive and focused on their own business, with no need to understand the complexities involved in system services.

      We can think of a slice as a shell covering many components. Applications are made up of modules that implement their respective business functions. With AOP, the core business layer can be wrapped with a variety of functional layers. These layers are applied declaratively so flexibly that your core application doesn’t even know they exist. This is a very powerful philosophy that separates security, transaction, and logging concerns from the core business logic

  • Reduce boilerplate code with cuts and templates.

    Spring aims to eliminate boilerplate code through template encapsulation. Spring’s JdbcTemplate, for example, makes it possible to avoid traditional JDBC boilerplate code when performing database operations. And many other XXxTemplates