Creating & Destroying Objects

THIS Section concerns creating and destroying objects:

  • When and how to create them,
  • When and how to avoid creating them,
  • How to ensure they are destroyed in a timely manner, and
  • How to manage any cleanup actions that must precede their destruction.
Objects Management memory-map
Following Rules are described
  1. Consider static factory methods instead of constructors
  2. Consider a builder when faced with many constructor parameters
  3. Enforce the singleton property with a private constructor an enum type
  4. Enforce non-instantiability with a private constructor
  5. Prefer dependency injection to hard-wiring resources
  6. Avoid creating unnecessary objects
  7. Eliminate obsolete object references
  8. Avoid finalizers and cleaners
  9. Prefer try-with-resources to try-finally

Introduction to Effective Java:

Following Topics are described with best practices and rules around it in next sections:

  1. Creating and Destroying Objects
  2. Methods Common to all Objects
  3. Classes and Interface
  4. Generics
  5. Enum and Annotations
  6. Lambdas and Streams
  7. Methods
  8. General Programming
  9. Exceptions
  10. Concurrency
  11. Serialization
Progress
  1. Revisit Each Topic and complete a rule (in-progress)
    1. Creating and destroying objects (in-progress)

Objectives:

  1. Your thoughts on Why this topics? What is it about ?
    • As you go thought content verify if it matches what you thought if different what is it?
  2. Things that create Triggered point of realization for a concept
    • Words sentences worth remembering for reiteration in public or interview.
    • In general – 2 things in a text : message and presentation(points that gets your attention)
  3. Getting outcome applying things wither in code or in interview -knowledge sharing
  4. Application -where to apply in implementation
  5. Learning process — make it fast!!!

J2EE

Introduction

Java EE is the abstract specifications for developing enterprise applications. These specifications are implemented by the application server vendors like weblogic, websphere.

For example, JSP and Servlet are speciation for developing web applications. Obviously web applications deployed to the server. So, server vendors has to implement the specification.

Where as spring follows some of the specifications from Java EE and override with better options. It is a standalone framework built on top of the Java EE technology.


Servlet filter

https://www.journaldev.com/1933/java-servlet-filter-example-tutorial

ME[A/R/V]N Stack Introduction

ME[A/R/V]N abbreviates for and used for:

  • MongoDB – document database
  • Express(.js) – Node.js web framework
  • Node(.js) – the premier JavaScript web server
  • React(.js) – a client-side JavaScript framework.
  • Angular
  • Vue(.js)

MERN is one of several variations of the MEAN stack (MongoDB Express Angular Node), where the traditional Angular.js frontend framework is replaced with React.js. Other variants include MEVN (MongoDB, Express, Vue, Node), and really any frontend JavaScript framework can work.

Note: JavaScript(ECMAScript) and Typescript(Superset of JS) forms the base of most of mentioned technologies e.g React is a library of JS, Angular is based on TypeScript etc.

Express and Node make up the middle (application) tier. Express.js is a server-side web framework, and Node.js the popular and powerful JavaScript server platform. Regardless of which variant you choose, ME(RVA)N is the ideal approach to working with JavaScript and JSON, all the way through

How does the MERN stack work?

The MERN architecture allows you to easily construct a 3-tier architecture (frontend, backend, database) entirely using JavaScript and JSON.

Mern Stack

Generic Exception Handling in Web-services

Creating Generic Exception class for Web-services:

Step 1. Create a Generic class that extends ResponseEntityExceptionHandler.
Step 2. Annotate the class with @RestController(as it will send Exception response to client) & @ControllerAdvice (to intercept all controller’s exception).

Method Level Changes:
Step 3. Create method(s) signature similar to one in ResponseEntityExceptionHandler to handle Specific Exception . Mark it with annotation @ExceptionHandler(Exception.class) where the parameter is type of exception it will handle.

@ExceptionHandler(Exception.class)
public final ResponseEntity<Object> handleAllException(Exception ex, WebRequest request)

{

ExceptionResponse exceptionResponse = new ExceptionResponse(new Date(), ex.getMessage(),
request.getDescription(false));
return new ResponseEntity(exceptionResponse, HttpStatus.INTERNAL_SERVER_ERROR);

}


Step 4. methods return type is ResponseEntity with take body and status as parameter,
body is supplied form ExceptionType being thrown and status-code as per requirement(HttpStatus.CODE_NAME) .

Note : Syntax

ResponseEntity([header],[body],[status-code])

Project Reference:

Artifact – restful-web-services

Package – com.tutorial2implement.webservice.restfulwebservices.application.exception;

Note :

In earlier versions of Spring, extending ResponseEntityExceptionHandler and overriding its methods allowed developers to customize exception handling globally. However, with the release of Spring Framework 6.0, the design has evolved, and some of these methods are now final to promote a more flexible and configurable approach to exception handling.
solution - avoid extending as extends ResponseEntityExceptionHandler and use the method direcctly

System-Design Data-Intensive Application

Aims to bring out the optimal use of available technologies and tools for specific application in data-driven application .

  1. Part-1 : Foundation of Data-Systems
    1. Unit-1 : Reliable , Scalable and Maintainable [ R.S.M. ] code
    2. Unit-2 : Data Models and Query Languages
    3. Unit-3 : Storage and Retrieval
    4. Unit-4 : Encoding and Evolution
  2. Part-2 : Distributed Data
    1. Unit-5 : Replication
    2. Unit-6 : Partitioning
    3. Unit-7 : Transactions
    4. Unit-8 : The trouble with distributed system
    5. Unit-9 : Consistency and Consensus
  3. Part-3 : Derived Data
    1. Batch Processing
    2. Stream Processing
    3. The future of Data Systems

Exceptions

Memory Map

Objective

Following rules are described

  1. Item 69: Use exceptions only for exceptional conditions . . . . . . . 293
  2. Item 70: Use checked exceptions for recoverable conditions and
  3. runtime exceptions for programming errors . . . . . . . . . . 296
  4. Item 71: Avoid unnecessary use of checked exceptions . . . . . . . . 298
  5. Item 72: Favor the use of standard exceptions. . . . . . . . . . . . . . . . 300
  6. Item 73: Throw exceptions appropriate to the abstraction. . . . . . . 302
  7. Item 74: Document all exceptions thrown by each method. . . . . . 304
  8. Item 75: Include failure-capture information in detail messages. . 306
  9. Item 76: Strive for failure atomicity . . . . . . . . . . . . . . . . . . . . . . . 308
  10. Item 77: Don’t ignore exceptions . . . . . . . . . . . . . . . . . . . . . . . . . 310