Please enable JavaScript.

Coggle requires JavaScript to display documents.

Java, DevOps and Cloud, REACT LEARNING PATH, Advanced Javascript - Coggle…

Java

Spring Boot

SPRING DATA

Java Persistence API

PROPERTIES

spring.jpa.hibernate.ddl-auto=create-drop
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.validator.apply_to_ddl=false
spring.jpa.properties.hibernate.check_nullability=true

Hibernate

Hibernate 5 Naming Strategy Configuration
Offical Link

 In Hibernate the default table name is the name of the class with the first letter capitalized. It's determined through the ImplicitNamingStrategy contract.

But we can change this behavior by implementing a PhysicalNamingStrategy interface

Dependencies

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core</artifactId>
    <version>5.4.24.Final</version>
</dependency>

Entity

Default Column Values in JPA

Remember that by using this solution, we won't be able to set a given column to null when saving the entity for the first time. If we don't provide any value, the default one will be set automatically.

@Column(columnDefinition = "varchar(255) default 'John Snow'")

 @Column(columnDefinition = "integer default 25")

JPA Entity Lifecycle Events

POINTS TO REMEMBER

 If we're using @GeneratedValue to automatically generate our primary keys, we can expect that key to be available in the @PostPersist method.

We should note that the @PreUpdate callback is only called if the data is actually changed

The @PostUpdate callback is called regardless of whether anything actually changed.

If any of our callbacks for persisting or removing an entity throw an exception, the transaction will be rolled back.

Two approaches for using the lifecycle event annotations

Annotating methods in the entity

 Annotating an EntityListener 
We might favor this approach over placing the methods in our entity if we have some operation we want to apply to all of our entities

Annotating the Entity

@Entity
public class User {
    private static Log log = LogFactory.getLog(User.class);

    @Id
    @GeneratedValue
    private int id;

    private String userName;
    private String firstName;
    private String lastName;
    @Transient
    private String fullName;

    // Standard getters/setters
}

public interface UserRepository extends JpaRepository<User, Integer> {
    public User findByUserName(String userName);
}

@PrePersist
public void logNewUserAttempt() {
    log.info("Attempting to add new user with username: " + userName);
}

@PostPersist
public void logNewUserAdded() {
    log.info("Added user '" + userName + "' with ID: " + id);
}

@PreRemove
public void logUserRemovalAttempt() {
    log.info("Attempting to delete user: " + userName);
}

@PostRemove
public void logUserRemoval() {
    log.info("Deleted user: " + userName);
}

@PreUpdate
public void logUserUpdateAttempt() {
    log.info("Attempting to update user: " + userName);
}

@PostUpdate
public void logUserUpdate() {
    log.info("Updated user: " + userName);
}

@PostLoad
public void logUserLoad() {
    fullName = firstName + " " + lastName;
}

Annotating an EntityListener

 public class AuditTrailListener {
    private static Log log = LogFactory.getLog(AuditTrailListener.class);

    @PrePersist
    @PreUpdate
    @PreRemove
    private void beforeAnyUpdate(User user) {
        if (user.getId() == 0) {
            log.info("[USER AUDIT] About to add a user");
        } else {
            log.info("[USER AUDIT] About to update/delete user: " + user.getId());
        }
    }

    @PostPersist
    @PostUpdate
    @PostRemove
    private void afterAnyUpdate(User user) {
        log.info("[USER AUDIT] add/update/delete complete for user: " + user.getId());
    }

    @PostLoad
    private void afterLoad(User user) {
        log.info("[USER AUDIT] user loaded from database: " + user.getId());
    }
}

@EntityListeners(AuditTrailListener.class)
@Entity
public class User {
    //...
}

JPA Basic vs Column

Attributes of the @Basic annotation are applied to JPA entities, whereas the attributes of @Column are applied to the database columns

@Basic annotation's optional attribute defines whether the entity field can be null or not; on the other hand, @Column annotation's nullable attribute specifies whether the corresponding database column can be null

We can use @Basic to indicate that a field should be lazily loaded

The @Column annotation allows us to specify the name of the mapped database colum

  @Basic(optional = false, fetch = FetchType.LAZY)

Difference Between Size, Length, and Column(length=value)

JSR-330‘s @Size annotation, Hibernate‘s @Length annotation, and JPA‘s @Column‘s length attribute.

@Size and @Length are similar. We can use either annotation to validate the size of a field. The former is a Java-standard annotation, while the latter is specific to Hibernate.

@Column, though, is a JPA annotation that we use to control DDL statements.

@Size makes the bean independent of JPA and its vendors, such as Hibernate. As a result, it's more portable than @Length.
@Size(min = 3, max = 15)

@Length is the Hibernate-specific version of @Size. We'll enforce the range for lastName using @Length:
@Length(min = 3, max = 15)

@Column to indicate specific characteristics of the physical database column. We'll use the length attribute of the @Column annotation to specify the string-valued column length:
@Column(length = 3)

JPA Embedded And Embeddable

JPA provides the @Embeddable annotation to declare that a class will be embedded by other entities.

The JPA annotation @Embedded is used to embed a type into another entity.

@Embeddable
public class ContactPerson {

    private String firstName;

    private String lastName;

    private String phone;

    // standard getters, setters
}

@Entity
public class Company {

    @Id
    @GeneratedValue
    private Integer id;

    private String name;

    private String address;

    private String phone;

    @Embedded
    private ContactPerson contactPerson;

    // standard getters, setters
}

we can use @AttributeOverrides and @AttributeOverride to override the column properties of our embedded type.

@Embedded
@AttributeOverrides({
  @AttributeOverride( name = "firstName", column = @Column(name = "contact_first_name")),
  @AttributeOverride( name = "lastName", column = @Column(name = "contact_last_name")),
  @AttributeOverride( name = "phone", column = @Column(name = "contact_phone"))
})
private ContactPerson contactPerson;

Hibernate NotNull vs Column(nullable = false)

Both of them essentially prevent storing null values in the underlying database, there are significant differences between these two approaches.

The @NotNull annotation is defined in the Bean Validation specification. This means its usage isn't limited only to the entities. On the contrary, we can use @NotNull on any other bean as well

to disable this Hibernate feature, all we need to do is to set hibernate.validator.apply_to_ddl property to false.

The @Column annotation is defined as a part of the Java Persistence API specification.

It's used mainly in the DDL schema metadata generation. This means that if we let Hibernate generate the database schema automatically, it applies the not null constraint to the particular database column.

Hibernate, however, is able to perform the validation of the entity against the possible null values, even if the corresponding field is annotated only with @Column(nullable = false).

In order to activate this Hibernate feature, we need to explicitly set the hibernate.check_nullability property to true:

As a rule of thumb, we should prefer the @NotNull annotation over the @Column(nullable = false) annotation. This way, we make sure the validation takes place before Hibernate sends any insert or update SQL queries to the database.

Also, it's usually better to rely on the standard rules defined in the Bean Validation, rather than letting the database handle the validation logic.

Defining Unique Constraints in JPA

 @Column(unique=true) and @UniqueConstraint

 Unique Constraints on a Referenced Table Column

 @Column(unique=true)

Whenever the unique constraint is based only on one field, we can use @Column(unique=true) on that column

@Column(unique=true)
private Long personNumber;

 @UniqueConstraint

To define a composite unique key, we can add constraints on the table instead of a column. JPA helps us achieve this using the @UniqueConstraint annotation.

@Table(uniqueConstraints = { @UniqueConstraint(columnNames = { "personNumber", "isActive" }) })

One point to note here is that if we don't specify a name, it's a provider-generated value. Since JPA 2.0, we can provide a name for our unique constraint:

@Table(uniqueConstraints = { @UniqueConstraint(name = "UniqueNumberAndStatus", columnNames = { "personNumber", "isActive" }) })

@Table(uniqueConstraints = {
   @UniqueConstraint(name = "UniqueNumberAndStatus", columnNames = {"personNumber", "isActive"}),
   @UniqueConstraint(name = "UniqueSecurityAndDepartment", columnNames = {"securityNumber", "departmentCode"})})

Entity Relationship

One-to-One Relationship in JPA

Implementing With a Foreign Key in JPA

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "id")
    private Long id;
    //... 

    @OneToOne(cascade = CascadeType.ALL)
    @JoinColumn(name = "address_id", referencedColumnName = "id")
    private Address address;

    // ... getters and setters
}

@Entity
@Table(name = "address")
public class Address {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "id")
    private Long id;
    //...

    @OneToOne(mappedBy = "address")
    private User user;

    //... getters and setters
}

Simply put, whoever owns the foreign key column gets the @JoinColumn annotation.

Using a Shared Primary Key

In this strategy, instead of creating a new column address_id, we'll mark the primary key column (user_id) of the address table as the foreign key to the users table:

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "id")
    private Long id;

    //...

    @OneToOne(mappedBy = "user", cascade = CascadeType.ALL)
    @PrimaryKeyJoinColumn
    private Address address;

    //... getters and setters
}

@Entity
@Table(name = "address")
public class Address {

    @Id
    @Column(name = "user_id")
    private Long id;

    //...

    @OneToOne
    @MapsId
    @JoinColumn(name = "user_id")
    private User user;

    //... getters and setters
}

The mappedBy attribute is now moved to the User class since the foreign key is now present in the address table. We've also added the @PrimaryKeyJoinColumn annotation, which indicates that the primary key of the User entity is used as the foreign key value for the associated Address entity.
`

We still have to define an @Id field in the Address class. But note that this references the user_id column, and it no longer uses the @GeneratedValue annotation. Also, on the field that references the User, we've added the @MapsId annotation, which indicates that the primary key values will be copied from the User entity.

Using a Join Table

One-to-one mappings can be of two types: optional and mandatory. So far, we've seen only mandatory relationships.

The strategies that we have discussed until now force us to put null values in the column to handle optional relationships.

Typically, we think of many-to-many relationships when we consider a join table, but using a join table in this case can help us to eliminate these null values:

@Entity
@Table(name = "employee")
public class Employee {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "id")
    private Long id;

    //...

    @OneToOne(cascade = CascadeType.ALL)
    @JoinTable(name = "emp_workstation", 
      joinColumns = 
        { @JoinColumn(name = "employee_id", referencedColumnName = "id") },
      inverseJoinColumns = 
        { @JoinColumn(name = "workstation_id", referencedColumnName = "id") })
    private WorkStation workStation;

    //... getters and setters
}

@Entity
@Table(name = "workstation")
public class WorkStation {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "id")
    private Long id;

    //...

    @OneToOne(mappedBy = "workStation")
    private Employee employee;

    //... getters and setters
}

- - - - :check: The container will invoke the constructor with arguments each representing a dependency that we want to set i.e, all the dependencies are declared in one step. This helps in understanding whether the class depends on too many services. Constructor injection is the best practice to inject dependencies.
    - - :check: The container will call the setter methods of our class. The objects of the class will have setters. The Inversion of Control(IoC) container will use these setters to provide the resource at run-time after invoking a no-argument constructor or no-argument static factory method to instantiate their bean. Setter injection is used for optional dependencies.
    - - We use Autowire annotation to inject the dependency
    - - .
        
        :check: In constructor injection, partial injection is not allowed whereas it is allowed in setter injection.
        
        :check: The constructor injection doesn’t override the setter property whereas the same is not true for setter injection.
        
        :check: Constructor injection creates a new instance if any modification is done. The creation of a new instance is not possible in setter injection
        
        :check: In case the bean has many properties, then constructor injection is preferred. If it has few properties, then setter injection is preferred
        
        .
        :check: The IoC container makes sure that all the arguments provided in the constructor are available before passing them into the constructor. This helps in preventing the infamous NullPointerException.
        
        :check: Constructor injection helps us to identify if our bean is dependent on too many other objects. If our constructor has a large number of arguments this may be a sign that our class has too many responsibilities. We may want to think about refactoring our code to better address proper separation of concerns.
        
        :check: Constructor injection helps in creating immutable objects because a constructor’s signature is the only possible way to create objects. Once we create a bean, we cannot alter its dependencies anymore. With setter injection, it’s possible to inject the dependency after creation, thus leading to mutable objects which, among other things, may not be thread-safe in a multi-threaded environment and are harder to debug due to their mutability.
  - - - :check: Spring Framework introduced key features as part of new Java configuration support. This makes use of the Configuration annotated classes and Bean annotated methods.
      - Bean annotation has the same role as the <bean/> element
      - :check: Classes annotated with Configuration allow to define inter-bean dependencies by simply calling other Bean methods in the same class.
    - - :check: The bean configurations and their dependencies are specified in XML configuration files
      - <bean id="interviewBitBean" class="org.intervuewBit.firstSpring.InterviewBitBean">
        <property name="name" value="InterviewBit"></property>
        </bean>
    - - :check: Instead of the XML approach, the beans can be configured into the component class itself by using annotations on the relevant class, method, or field declaration.
        :check: Annotation wiring is not active in the Spring container by default. This has to be enabled in the Spring XML configuration file as shown below
      - <beans>
        <context:annotation-config/>
        
        </beans>
- - - - The scope of bean definition while using this would be a single instance per IoC container.
    - - The scope for a single bean definition can be any number of object instances.
    - - The scope of the bean definition is an HTTP request.
    - - The scope of the bean definition is HTTP-session.
    - - The scope of the bean definition here is a Global HTTP session.

Inteview Question :question:

What Are the Benefits of Using Spring?
Lightweight

– There is a slight overhead of using the framework in development.

Inversion of Control (IoC)

 – Spring container takes care of wiring dependencies of various objects instead of creating or looking for dependent objects.

Aspect-Oriented Programming (AOP)

 – Spring supports AOP to separate business logic from system services.

IoC container

 – manages Spring Bean life cycle and project-specific configurations

MVC framework

 – used to create web applications or RESTful web services, capable of returning XML/JSON responses

Transaction management

 – reduces the amount of boilerplate code in JDBC operations, file uploading, etc., either by using Java annotations or by Spring Bean XML configuration file

Exception Handling

 – Spring provides a convenient API for translating technology-specific exceptions into unchecked exceptions.

What Is a Spring Bean?

The Spring Beans are Java Objects that are initialized by the Spring IoC container.

What Is the Default Bean Scope in Spring Framework?

By default, a Spring Bean is initialized as a singleton.

How to Define the Scope of a Bean?

In order to set Spring Bean's scope, we can use @Scope annotation or “scope” attribute in XML configuration files. Note that there are five supported scopes:

Singleton
Prototype
Request
Session
Global-session
Official Link

Are Singleton Beans Thread-Safe?

No, singleton beans are not thread-safe, as thread safety is about execution, whereas the singleton is a design pattern focusing on creation. Thread safety depends only on the bean implementation itself.

- - - - ArrayList Class
        Non-synchronized in nature
        Contains ordered elements
        May Include duplicate
        
        Support the index base search, random access but elements can be easily inserted irrespective of position
        Increase size by 1/2 of the ArrayList
      - LinkedList Class
      - Vector
        Synchronized in nature
        Vector contains many methods that are not part of the collections framework
        Increase size by double of the ArrayList
      - Stack
    - - Array Queue
      - LinkedList Queue
      - Priority Queue
      - Deque Interface
    - - EnumSet
      - HashSet
      - LinkedHashSet
      - TreeSet
      - SortedSet Interface
      - NavigableSet Interface
- - - - :check: OutOfMemoryError
        :check:StackOverFlowError
    - - Other Exception (Checked)
        
        :check: ClassNotFoundException
        :check: IOException
        :check: FileNotFoundException
        :check: SQLException
        :check: NoSuchMethodException
      - Runtime Exception (Unchecked)
        
        :check: NullPointerException
        :check: IllegalArgumentException
        :check: ArithmeticException
        :check: IndexOutOfBoundException
  - - - To create a custom exception, we have to extend the java.lang.Exception class.
        
        import java.util.ArrayList; import java.util.Arrays; // create a checked exception class class CustomException extends Exception { public CustomException(String message) { // call the constructor of Exception class super(message); } } class Main { ArrayList<String> languages = new ArrayList<>(Arrays.asList("Java", "Python", "JavaScript")); // check the exception condition public void checkLanguage(String language) throws CustomException { // throw exception if language already present in ArrayList if(languages.contains(language)) { throw new CustomException(language + " already exists"); } else { // insert language to ArrayList languages.add(language); System.out.println(language + " is added to the ArrayList"); } } public static void main(String[] args) { // create object of Main class Main obj = new Main(); // exception is handled using try...catch try { obj.checkLanguage("Swift"); obj.checkLanguage("Java"); } catch(CustomException e) { System.out.println("[" + e + "] Exception Occured"); } } }
        Run Code
        OUTPUT
        Swift is added to the ArrayList
        [CustomException: Java already exists] Exception Occured
    - - To create a custom unchecked exception, we need to extend the java.lang.RuntimeException class:
        
        import java.util.ArrayList; import java.util.Arrays; // create a unchecked exception class class CustomException extends RuntimeException { public CustomException(String message) { // call the constructor of RuntimeException super(message); } } class Main { ArrayList<String> languages = new ArrayList<>(Arrays.asList("Java", "Python", "JavaScript")); // check the exception condition public void checkLanguage(String language) { // throw exception if language already present in ArrayList if(languages.contains(language)) { throw new CustomException(language + " already exists"); } else { // insert language to ArrayList languages.add(language); System.out.println(language + " is added to the ArrayList"); } } public static void main(String[] args) { // create object of Main class Main obj = new Main(); // check if language already present obj.checkLanguage("Swift"); obj.checkLanguage("Java"); } }
        Swift is added to the ArrayList
        Exception in thread "main" CustomException: Java already exists
        at Main.checkLanguage(Main.java:21)
        at Main.main(Main.java:37)
  - - - :check: Introduced in Java 1.7
        :check: Instead of closing the resources in the finally block, we can open the resource in the try() parentheses and the try block will take care of closing the resource.
        :check: EX: try(BufferReader br = new BufferReader(new InputStreamReader(System.in)))
        :check: Resource Closing Order -> Resources that were defined/acquired first will be closed last. Let's look at an example of this behavior:
        :check: A try-with-resources block can still have the catch and finally blocks, which will work in the same way as with a traditional try block.
      - A Custom Resource With AutoCloseable
        
        :check: To construct a custom resource that will be correctly handled by a try-with-resources block, the class should implement the Closeable or AutoCloseable interfaces and override the close method:
        
        public class MyResource implements AutoCloseable{
        Override
        public void close() throws Exception{
        S.O.P("Closed MyResource");
        }
        }
      - Java 9 – Effectively Final Variables
        
        :check: Before Java 9, we could only use fresh variables inside a try-with-resources block:
        try (Scanner scanner = new Scanner(new File("testRead.txt"));
        PrintWriter writer = new PrintWriter(new File("testWrite.txt"))) {
        // omitted
        }
        
        :check: As of Java 9 and as part of JEP 213, we can now use final or even effectively final variables inside a try-with-resources block:
        final Scanner scanner = new Scanner(new File("testRead.txt"));
        PrintWriter writer = new PrintWriter(new File("testWrite.txt"))
        try (scanner;writer) {
        //ommited
        }
        :check: Put simply, a variable is effectively final if it doesn't change after the first assignment, even though it's not explicitly marked as final.
        :check: The scanner variable is declared final explicitly, so we can use it with the try-with-resources block. Although the writer variable is not explicitly final, it doesn't change after the first assignment. So, we can to use the writer variable too.
    - - Its always executed irrespective of exception occurred.
        Except in case System.exit() is called.
- - - - :check: Encapsulation is data hiding(information hiding) while Abstraction is detail hiding(implementation hiding).
        :check: While encapsulation groups together data and methods that act upon the data, data abstraction deals with exposing the interface to the user and hiding the details of implementation.
        :check:Abstraction solves the problem at the design level whereas encapsulation solves the problem at the implementation level.
        :check:Abstraction is implemented in Java using Interface and Abstract class whereas encapsulation is implemented using private and protected access modifiers.
        :check:Abstraction is used to hide the unwanted data and giving relevant data whereas encapsulation is used for hiding data and code in a single unit to prevent access from outside.
        :check:The real-time example of Abstraction is TV Remote Button whereas the real-time example of Encapsulation is medical medicine.
    - - Does reflection violates encapsulation in Java?
        :check: Reflection violates encapsulation because it reveals the internal data structures.
      - Explain design pattern based on encapsulation in java?
  - - - :check: Method overriding is one of the ways in which Java supports Runtime Polymorphism
        :check: Dynamic method dispatch is the mechanism by which a call to an overridden method is resolved at run time, rather than compile time.
        :check: In Java, we can override methods only, not the variables(data members), so runtime polymorphism cannot be achieved by data members
      - Upcasting
        
        :check: A superclass reference variable can refer to a subclass object. This is also known as upcasting
      - Advantages of Dynamic Method Dispatch
        
        :check: Dynamic method dispatch allows Java to support overriding of methods which is central for run-time polymorphism.
        :check: It allows a class to specify methods that will be common to all of its derivatives while allowing subclasses to define the specific implementation of some or all of those methods.
        :check: It also allows subclasses to add their specific methods subclasses to define the specific implementation of some.
      - Is achieved using Overriding
        :check: Dynamic polymorphism: Same method is overridden with same signature in different classes.
      - Tricky Question :question:
        
        Can we load parent class static method :question:
        
        Can we override final static method of parent:question:
      - Rules of method overriding in Java
        There are few rules which needs to be followed while overriding any method in Java, failure to follow these rules results in a compile-time error Java.
        Refe
        
        The first and most important rule regarding method overriding in Java is that you can only override a method in a subclass. You can not override the method in the same class.
        
        A second important rule of method overriding in Java that name and signature of the method must be the same in Super class and Sub class or in the interface and its implementation.
        
        The third rule to override a method in Java is that the overriding method can not reduce the accessibility of the overridden method in Java. For example, if the overridden method is public then the overriding method can not be protected, private or package-private;
        But the opposite is true overriding method can increase the accessibility of the method in Java, i.e. if the overridden method is protected then The overriding method can be protected or public.
        
        Another worth noting rule of method overriding in Java is that the overriding method can not throw checked Exceptions is higher in the hierarchy than the overridden method. This means if the overridden method throws IOException then the overriding method can not throw java.lang.Exception in its throws clause because of java.lang.Exception comes higher than IOException in the Exception hierarchy.
        This rule doesn't apply to RuntimeException in Java, which is not even needed to be declared in a throws clause in Java.
        
        You can not override private, static and final the method in Java. private and static method are bonded during compile time using static binding in Java and doesn't resolve during runtime. the overriding the final method in Java is a compile-time error. Though private and static methods can be hidden if you declare another method with the same and signature in the subclass.
        
        The overridden method is called using dynamic binding in Java at runtime based upon the type of Object. As shown in the following example of method overriding in Java.
        
        If you are extending the abstract class or implementing the interface then you need to override all abstract methods unless your class is not abstract. an abstract method can only be used by using method overriding.
        
        Always use Override annotation while the overriding method in Java. Though this is not a rule it's one of the best Java coding practices to follow. From Java 6 you can also use Override annotation on a method inherited from the interface as well. If you are not familiar with annotations in Java then you can also check out these free Java Programming courses to learn Java from scratch.
    - - Is achieved using Overloading
        :check: Static polymorphism : Same method name is overloaded with different type or number of parameters in same class (different signature).
      - Tricky Questions :question:
        
        Can we overload static method :question:
        We can declare static methods with the same signature in the subclass, but it is not considered overriding as there won’t be any run-time polymorphism. Hence the answer is ‘No’.

SQL

Tricky Questions :question:

What are the 4 SQL command categories

1. DML (Data Manipulation Language) which provides data manipulation features
2. DDL (Data Definition Language) which is used to manipulate database structures
3. TCL (Transaction Control Language) that takes in charge data transaction verification and error handling
4. DCL (Data Control Language) are security statements that feature user restrictions and data access permissions to promote security of your data

- - - - Associate-level AWS certification
        
        Solutions Architect - Professional
        
        DevOps Engineer - Professional
        
        Professional-level AWS certification
        
        Security - Specialty
        
        Machine Learning - Specialty
        
        Database - Specialty
        
        Data Analytics - Specialty
        
        Specialty AWS certification
        
        Advanced Networking - Specialty
      - Solutions Architect - Associate
      - Developer - Associate
      - SysOps Administrator - Associate
- - - - 2. Prototypal Inheritance
      - Higher Order Functions
      - 1. Closures
      - Functions vs Objects
      - Scheme + Java
      - Composition vs Inheritance
        
        Object Oriented Programming
        
        Private vs Public
        
        Prototype
        
        Java
        
        Inheritance
        
        this keyword
        
        new keyword
        
        4 Principles of OOP
        
        ES6 Classes
        
        Object.create()
        
        Error Handling
        
        Modules in Javascript
        
        AMD
        
        CommonJS
        
        UMD
        
        IIFE
        
        Native ES Modules
        
        Asynchronous Javascript
        
        Microtask Queue (Job Queue)
        
        Event loop
        
        Promises
        
        Task Queue (Callback Queue)
        
        Async/Await
        
        Web APIs
        
        Callbacks
        
        Functional Programming
        
        Curry
        
        Referential Transparency
        
        Partial Application
        
        Compose
        
        Pipe
        
        Pure Functions