Backend

@Entity

An entity is a lightweight persistence domain object. Typically an entity represents a table in a relational database, and each entity instance corresponds to a row in that table. The primary programming artifact of an entity is the entity class, although entities can use helper classes.

Exceptions

Exceptions in Java. An exception is an unwanted or unexpected event, which occurs during the execution of a program i.e at run time, that disrupts the normal flow of the program's instructions. Error: An Error indicates serious problem that a reasonable application should not try to catch.

Factory

In class-based programming, the factory method pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created. This is done by creating objects by calling a factory method—either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes—rather than by calling a constructor.

Serialization

In computer science, in the context of data storage, serialization (or serialisation) is the process of translating data structures or object state into a format that can be stored (for example, in a file or memory buffer) or transmitted (for example, across a network connection link) and reconstructed later (possibly in a different computer environment).[1] When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object. For many complex objects, such as those that make extensive use of references, this process is not straightforward. Serialization of object-oriented objects does not include any of their associated methods with which they were previously linked.

DAO

In computer software, a data access object (DAO) is an object that provides an abstract interface to some type of database or other persistence mechanism. By mapping application calls to the persistence layer, the DAO provides some specific data operations without exposing details of the database. This isolation supports the single responsibility principle. It separates what data access the application needs, in terms of domain-specific objects and data types (the public interface of the DAO), from how these needs can be satisfied with a specific DBMS, database schema, etc. (the implementation of the DAO). Although this design pattern is equally applicable to most programming languages, most types of software with persistence needs, and most types of databases, it is traditionally associated with Java EE applications and with relational databases (accessed via the JDBC API because of its origin in Sun Microsystems' best practice guidelines[1] "Core J2EE Patterns" for that platform).

Inheritance

In object-oriented programming, inheritance is the mechanism of basing an object or class upon another object (prototype-based inheritance) or class (class-based inheritance), retaining similar implementation. Also defined as deriving new classes (sub classes) from existing ones (super class or base class) and forming them into a hierarchy of classes. In most class-based object-oriented languages, an object created through inheritance (a "child object") acquires all the properties and behaviors of the parent object (except: constructors, destructor, overloaded operators and friend functions of the base class). Inheritance allows programmers to create classes that are built upon existing classes,[1] to specify a new implementation while maintaining the same behaviors (realizing an interface), to reuse code and to independently extend original software via public classes and interfaces. The relationships of objects or classes through inheritance give rise to a directed graph. Inheritance was invented in 1969 for Simula.[2]

Polymorphism

In programming languages and type theory, polymorphism is the provision of a single interface to entities of different types[1] or the use of a single symbol to represent multiple different types.[2] The most commonly recognised major classes of polymorphism are: Ad hoc polymorphism: defines a common interface for an arbitrary set of individually specified types. Parametric polymorphism: when one or more types are not specified by name but by abstract symbols that can represent any type. Subtyping (also called subtype polymorphism or inclusion polymorphism): when a name denotes instances of many different classes related by some common superclass.[3]

Abstraction

In software engineering and computer science, abstraction is: the process of removing physical, spatial, or temporal details[2] or attributes in the study of objects or systems in order to more closely attend to other details of interest[3]; it is also very similar in nature to the process of generalization; the abstract concept-objects which are created by keeping common features or attributes to various concrete objects or systems of study[3] — the result of the process of abstraction.

Dependency Injection

In software engineering, dependency injection is a technique whereby one object (or static method) supplies the dependencies of another object. A dependency is an object that can be used (a service). An injection is the passing of a dependency to a dependent object (a client) that would use it. The service is made part of the client's state.[1] Passing the service to the client, rather than allowing a client to build or find the service, is the fundamental requirement of the pattern.

N-Tier architecture

In software engineering, multitier architecture (often referred to as n-tier architecture) or multilayered architecture is a client-server architecture in which presentation, application processing, and data management functions are physically separated. The most widespread use of multitier architecture is the three-tier architecture. N-tier application architecture provides a model by which developers can create flexible and reusable applications. By segregating an application into tiers, developers acquire the option of modifying or adding a specific layer, instead of reworking the entire application. A three-tier architecture is typically composed of a presentation tier, a domain logic tier, and a data storage tier. While the concepts of layer and tier are often used interchangeably, one fairly common point of view is that there is indeed a difference. This view holds that a layer is a logical structuring mechanism for the elements that make up the software solution, while a tier is a physical structuring mechanism for the system infrastructure.[1][2] For example, a three-layer solution could easily be deployed on a single tier, such as a personal workstation.[3]

Singleton

In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one "single" instance. This is useful when exactly one object is needed to coordinate actions across the system. The term comes from the mathematical concept of a singleton.

Method Overriding

Method overriding, in object-oriented programming, is a language feature that allows a subclass or child class to provide a specific implementation of a method that is already provided by one of its superclasses or parent classes. The implementation in the subclass overrides (replaces) the implementation in the superclass by providing a method that has same name, same parameters or signature, and same return type as the method in the parent class.[1] The version of a method that is executed will be determined by the object that is used to invoke it. If an object of a parent class is used to invoke the method, then the version in the parent class will be executed, but if an object of the subclass is used to invoke the method, then the version in the child class will be executed.[2] Some languages allow a programmer to prevent a method from being overridden.

Microservices Architecture

Microservices are a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion.[1] It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.[2] It also allows the architecture of an individual service to emerge through continuous refactoring.[3] Microservices-based architectures enable continuous delivery and deployment.[4]

MVC

Stands for "Model-View-Controller." MVC is an application design model comprised of three interconnected parts. They include the model (data), the view (user interface), and the controller (processes that handle input).

Facade

The facade pattern (also spelled façade) is a software-design pattern commonly used in object-oriented programming. Analogous to a facade in architecture, a facade is an object that serves as a front-facing interface masking more complex underlying or structural code. A facade can: improve the readability and usability of a software library by masking interaction with more complex components behind a single (and often simplified) API provide a context-specific interface to more generic functionality (complete with context-specific input validation) serve as a launching point for a broader refactor of monolithic or tightly-coupled systems in favor of more loosely-coupled code

Concrete vs Abstract Class

The only real difference is that a concrete class can be instantiated because it provides (or inherits) the implementation for all of its methods. An abstract class cannot be instantiated because at least one method has not been implemented. Abstract classes are meant to be extended. If they provide any implementation detail, it can be reused by all child classes. A special case is the pure abstract class, which provides no implementation at all. These classes do not help with code reuse, which makes them fundamentally different. This difference is described by the two types of inheritance: Implementation inheritance - provides a mechanism for code reuse. Interface inheritance - provides a mechanism for subtyping. If Class B extends Class A, that does not necessarily mean that B is an A. It might just mean that B inherits some code from A. It's not always clear, and some languages conflate this with subtyping. Java is an example of a language that provides a different construct for subtyping, called an interface. Interfaces are basically pure abstract classes. If Class B implements Interface A, then B is an A. When a language decouples implementation inheritance from interface inheritance, it becomes possible to treat certain problems differently. For example: Java sidesteps the complexity of multiple inheritance by prohibiting a class from having two superclasses. However, a class is free to implement any number of interfaces. It's easier to follow the principle of favoring composition over inheritance. Extending too many classes can lead to complex class hierarchies, but implementing too many interfaces isn't as much of a problem. When it comes to tracing the flow of execution through a program, interfaces can't complicate the issue because they don't include any executable code.

prototype

The prototype pattern is a creational design pattern in software development. It is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. This pattern is used to: avoid subclasses of an object creator in the client application, like the factory method pattern does. avoid the inherent cost of creating a new object in the standard way (e.g., using the 'new' keyword) when it is prohibitively expensive for a given application. To implement the pattern, declare an abstract base class that specifies a pure virtual clone() method. Any class that needs a "polymorphic constructor" capability derives itself from the abstract base class, and implements the clone() operation.

@Column

https://codesjava.com/jpa-column-annotation

@manyToMany

https://docs.oracle.com/javaee/6/api/javax/persistence/ManyToMany.html

@manyToOne

https://docs.oracle.com/javaee/6/api/javax/persistence/ManyToOne.html

@oneToMany

https://docs.oracle.com/javaee/6/api/javax/persistence/OneToMany.html

eager vs lazy (@fetch)

https://howtoprogramwithjava.com/hibernate-eager-vs-lazy-fetch-type/

@Id

https://stackoverflow.com/questions/20603638/what-is-the-use-of-annotations-id-and-generatedvaluestrategy-generationtype

@Table

https://stackoverflow.com/questions/37729770/what-is-the-use-of-table-annotation-in-jpa

@fetch

https://stackoverflow.com/questions/43515949/what-is-fetch-annotation-in-hibernate

Spring Singleton

https://stackoverflow.com/questions/6205171/correct-way-of-making-a-singleton-a-spring-bean

Dependency Injection and Inversion of Control Spring

https://www.baeldung.com/inversion-control-and-dependency-injection-in-spring

Spring Rest Controller

https://www.baeldung.com/spring-controller-vs-restcontroller

Spring Controller

https://www.baeldung.com/spring-controllers

Inversion of Control (IoC)

n software engineering, inversion of control (IoC) is a programming principle. IoC inverts the flow control as compared to traditional control flow. In IoC, custom-written portions of a computer program receive the flow of control from a generic framework. A software architecture with this design inverts control as compared to traditional procedural programming: in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the framework that calls into the custom, or task-specific, code.