Search This Blog

Thursday, 16 February 2023

Polymorphism In OOPs Paradigm

 Polymorphism can be visualized as a person who wears multiple disguises, at different times.

Technically, it means that a method / property behaves differently, at different times. These times could be captured at compile time / runtime

Polymorphism forms one of the most important pillars of OOPs paradigm. At an enterprise level, this principle is used on a day-in-and-out basis. There are 40 design patterns at the minimum that use the concept of polymorphism. The most common and obvious pattern is the "Factory" design pattern, which can be found even in the simplest and most complex enterprise projects.

In an interview, polymorphism questions come up in the first 5 questions.

There are two types of Polymorphism namely

  1. Compile-Time Polymorphism
    1. Overloading is the technique used to implement Compile-time polymorphism
  2. Run-Time Polymorphism
    1. Overriding is the technique used to implement Run-time polymorphism
    2. In overriding, the base class gives the permission to the derived classes to allow change in the implementation logic.
      1. This permission is given using special keywords
        1. virtual
        2. abstract
        3. interface

You can visualize Polymorphism in the following manner

OVERLOADING
  • Think of a person named "Kunal". Technically, "Kunal" is an object of the  "Person" class, right?!
  • A person can work. Hence, technically, "work" is a method inside the person class.
  • Now a person can work on a single task, sometimes the person may work on multiple tasks. Technically, it means we can have two flavours of "work" viz.
    • bool work(string task)
    • bool work(string[] tasks)
  • Both these methods are essentially having the same name and return type. The only change is the change in the parameter types and count. Also these methods are in the same class.
  • Hence, in this case we can say that Work() is an overloaded method.
OVERRIDING

  • Let's say the same Person "Kunal" is also an Employee.
  • Technically, it means there is an IS-A relationship between Employee and Person, both of which are classes.
    • For overriding, it is important that the classes involved are in an inheritance relationship.
  • In this case, the Person object "Kunal", when started working in a company also became an object of "Employee" class, right?!
  • The Person also works, and the Employee also works. This is a common behaviour between the two classes. But the way (implementation) work is done at office is different from the non-office environment. Both work on tasks, but the way they work and deliver is different.
  • Technically, the logic is different for work() in Person, and different for works() in Employee
  • work() is a method that returns bool. This declaration will remain the same whether the work is done at home or office, only the logic will differ.
  • Hence, we are "overriding" only the implementation for work(), when we instantiate "Kunal" as person Vs when we instantiate "Kunal" as an Employee.
  • In overriding, the method signature remains the same in both the base, derived classes. Only the logic is different.
  • There are three ways of implementing overriding
    • "virtual" keyword in base class --- "override" keyword in derived class
    • "abstract" keyword  in base class --- "override" keyword in derived class
    • Interfaces  also known as Code Contracts

SUMMARY WITH SYNTAX

1. Compile Time Polymorphism: Done by "overloading"

   Same class, same function name & return type, multiple flavours of method by changing parameters

class Person{

public void Works(){}

public void Works(string pTask){}

    }


2. Runtime Polymorphism: Done by "overriding"

   Pre-requisite: Inheritance relation between classes

a. Using virtual

Mark a method as "virtual" in base class

Use "override" keyword to change the logic in derived class

** A method marked as virtual can have default implementation logic

Eg: class Shape{

public virtual PrintDetails(){

...default logic

}

}

    class Circle : Shape{

public override PrintDetails(){

... different logic

}

}

        b. Using abstract

   Pre-requisite: Inheritance relation between classes

** Abstract means Incomplete

** A method / property can be marked as abstract

** If a method / property is marked as abstract, the class MUST be marked as abstract

** An abstract class can NEVER be instantiated

** Hence, use base = new derived() formula

i. Mark a method / property as abstract in base class.

ii. Mark the base class as abstract

iii. In derived class use "override" keyword

Eg: abstract class Shape{

public abstract void Draw();

}


    class Circle : Shape{

public override void Draw(){

...logic

}

}


Wednesday, 15 February 2023

Best Practices while writing code - Set 1

 Enterprise Best Practices to be used while working on labs. The first set of best practices are as follows.

If you are a student or a learner upgrading to a technology and are creating quick applications, then these first set of enterprise best practices are applicable to you.

1. Working in n-tier architecture
    - Separated the core logic from the presentation layer
    - Keep the entry point of Presentation Layer LEAN
    - Modularize the logic into separate files, classes or a BL project

2. Boiler Plating code
    - While creating a project, always create the skeleton
      then fill in the logic in the right places

   - Example: 

          # Create the projects in the respective layers

          # Inside each project, create the classes with inheritance or association relations, with empty  

             properties and methods without logic

          # Compile your project. Compilation should succeed

          # Now, for the given set of requirements for a module, only add the logic in the relevant classes

             and methods

3. Exception Handling
    - The lower level tiers like DAL, BL should throw exceptions
      when such a case is encountered


           throw new Exception("exception message");


    - The higher level tiers like PL, must include the try--catch     
       block to catch any kind of exceptions which were thrown from     
       the lower tiers
        try{
            //suspecting code that could create issues
           }
        catch(Exception ex){
            //Print exception
            }

    - For exception handling, usually a custom strategy can be adopted, where third-party tools can be

       used to log the exceptions for further analysis, such as using log files or database. At the coding

       level, all exceptions should be thrown from the lower layers upwards towards the Presentation 

       Layer. At intermediate levels, specific exceptions can be added to error log files or database, while 

      at the Presentation Layer, a friendly message indicating something has gone wrong could be given 

      with a link to contact support.

Tuesday, 7 February 2023

The Modern Monolithic N-Tier distributed deployment Architecture used Today

 

The N-TIER Architecture and its Deployment Perspective for Web Apps

 

 




The N-Tier architecture above is used in most enterprise applications even today. The presentation Layer of an application has different forms of presentation such as presenting the product UI as a desktop App, as Mobile App and as a Web App at the same time. All these three presentation forms of the product are deployed on different servers but are in sync with the same Business Logic Layer and replications of the Database (Data Storage in above diagram)

This introduces a neutral layer known as the Services layer which become the common point of communication between the different presentation layers and the common server-side business logic.

The Presentation layer is also become complex owing to the usage of different client-side technologies that are built on architecture patterns such as MVC, MVP, MVVP, Prototype etc.

Hence the presentation layer gets further divided into n-tiers, namely the

1.       Html / UI Layer: Has dedicated UI developers who work on HTML based Languages (Polymer, JSX, React) & CSS Based Languages (LESS, SASS)

2.       Presentation Business Logic Layer: Has dedicated Front-end developers who work on Object Oriented Javascript based technologies

3.       Presentation Services Layer: Has dedicated Front-end developers who write client service classes to consume server side services-layer

When the N-Tier architecture is analysed from the deployment perspective, then it results in deployment architectures such as

1. Monolithic

2. Microservices

3. Micro-Kernel

and so on.

Let's stick to transforming the above n-tier architecture into a hybrid or enhanced monolith deployment.

Here, it looks similar to a distributed architecture of deployment, but the reason one can say its enhanced monolith is because, even with additional releases the total number of servers used in the deployment stay constant.

The current age monolithic architecture, is hybrid, considering the Presentation Layer becoming polyglotic, meaning the presentation layer uses more than one technology stacks, frameworks, languages.

A lot of times, our product has multiple UI interfaces like Web UI, Mobile App (Android, iOS, TvOS), Desktop App. All these UI apps could be synchronized to the same database data, the same business logic.

When the presentation layer becomes polyglotic, the deployment cannot be done on a single server always. Eg: The mobile App requires to be deployed to the respective vendor's cloud store, while the desktop app should be deployed on individual customer workstations, while the web app could be deployed on the enterprise's  own servers. 

Irrespective of the above, all of the data is synced with the same business logic and database. In this case, a pure monolithic architecture cannot be used as a pattern for deployment.

Converting the above development view of N-Tier Architecture to the Deployment View, of a modified / enhanced monolithic. The total number of servers in this distributed monolith will always be constant, even with additional releases of the product.



For each deployed node (server), today, a secondary node is attached, so that it eases managing failures and deploying the parts of the product. Hence to every node (active or primary) a secondary node is attached.


When a deployment is made, the deployment is done to the secondary node, and then synced with the primary node. The secondary node is made active for a few seconds until the primary node is synced with the latest deployment. After this a smooth switch is made so that the primary node now becomes active.

Hence for every server on which deployment is done, a secondary server is always attached, but is not active. This node is used for seamless switch while deployments are done and when the primary node for some reason fails.

A standard architectural solution for this is High Availability, which helps in the seamless switch after the new deployments are done on the primary and secondary node, such that the end customer / user using your app, is not affected.


Hope this helps you in your quest!