Search This Blog

Showing posts with label Example. Show all posts
Showing posts with label Example. Show all posts

Wednesday, 23 July 2025

OOPs in Python

Python supports rich object-oriented programming (OOP) features that promote modularity, scalability, and readability. In this article, we’ll explore core OOP concepts using Python’s syntax and conventions—ideal for building GUI apps, REST APIs, and creative projects.

Classes: They are like a template to create new objects. Similar to the blueprint of a house plan created by the architect.


Constructor: 

Every class has a constructor. This ensures that the object is created and loaded in the application memory with its settings as provided in the constructor. This is similar to the architect of the house instructed the contractor how to lay the foundation with which material and how it needs to be placed etc.

This is done using python's built-in function __init__(self).
This is a special function which will be invoked by python at runtime. You can see the above example with the __init__(self, <parameters>)
where,
self : here indicates the current context of the object created

Inheritance
Inheritance lets one class absorb properties and behaviors of another.


Syntax: 

class Child(Parent):
            ... your code here ...

Let's take the example of senior developer:



** NOTE: Please note, the above class does not have __init__()

Here, we need to understand, that until the parent class is constructed the child class cannot be constructed. Hence order of construction of object in execution, in the case of inheritance is
1.  parent __init__() 
2. child __init__()

CASE: In case the parent constructor has parameters apart from self, then how can these be supplied in inhheritance case?

ANS: Use super().__init__(parent-parameter-values)

Hence the above code will be modified to call the parent class constructor as follows:



Access Specifiers:
The following conventions are used to specify access.


See the following example:
Here instance properties are created where values assigned are native to that specific object only.



Statics:These are shareable variables and function. They are invoked using

ClassName.<static_member>

See the following example:


Overriding: The concept of  changing the behaviour of a function (logic of the function) in the child class is known as overriding




Overloading: The concept of creating a function with the same name but different parameters is known as overloading. Python does not support overloading. This can be done by using *args, **kwargs kind of parametersin the function

Play around with the following trinket showing all the above explained operations as an example



Wednesday, 6 September 2023

Architecture Post - Information View archival and retention

One of the infrequently analyzed aspects during the analysis of  information for a product is about retention and archival policies.

Retention and archival policies are different from backup policies

Data Backup: When a copy of existing data for the purposes of protecting and recovery in case of loss or fatal conditions of failure is known as data backup. If there is a crash, this backup can be used for immediate recovery. 
Backup policies are usually a scheduled as recurring nightly process. Depending on the condition, either a full backup is taken or a differential backup is taken on a secondary  or passive machine

Data Archive: The intent here is to keep this data for long term and in a cold storage, away from the active storage. This is about data that is infrequently used, history data, aged data. The reasons for archival is usually reporting, predictive analysis, analytics etc.
Archival policies differ from Backup policies.

USECASE: A simple management system
PHASE: Discovery
Analysis View: Information
The following diagram, models information (not data) categories and its relationships.
Consider an information relationship diagram as follows

%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20value%3D%22Company%22%20style%3D%22shape%3Ddocument%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BboundedLbl%3D1%3Bdashed%3D0%3BflipH%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-580%22%20y%3D%2255%22%20width%3D%22100%22%20height%3D%2270%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%223%22%20value%3D%22Designation%22%20style%3D%22shape%3Ddocument%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BboundedLbl%3D1%3Bdashed%3D0%3BflipH%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-790%22%20y%3D%22260%22%20width%3D%2280%22%20height%3D%2250%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%224%22%20value%3D%22Subsystems%22%20style%3D%22shape%3Ddocument%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BboundedLbl%3D1%3Bdashed%3D0%3BflipH%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-460%22%20y%3D%22155%22%20width%3D%22100%22%20height%3D%2270%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%225%22%20value%3D%22Employee%22%20style%3D%22shape%3Ddocument%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BboundedLbl%3D1%3Bdashed%3D0%3BflipH%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-680%22%20y%3D%22155%22%20width%3D%22100%22%20height%3D%2270%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%226%22%20value%3D%22HRMS%22%20style%3D%22label%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3Bimage%3Dimg%2Fclipart%2FGear_128x128.png%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-290%22%20y%3D%22210%22%20width%3D%22110%22%20height%3D%2240%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%227%22%20value%3D%22Payroll%22%20style%3D%22label%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3Bimage%3Dimg%2Fclipart%2FGear_128x128.png%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-300%22%20y%3D%22115%22%20width%3D%22110%22%20height%3D%2240%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%228%22%20value%3D%22Assets%22%20style%3D%22shape%3Ddocument%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BboundedLbl%3D1%3Bdashed%3D0%3BflipH%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-670%22%20y%3D%22260%22%20width%3D%2280%22%20height%3D%2250%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%229%22%20value%3D%22Projects%22%20style%3D%22shape%3Ddocument%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BboundedLbl%3D1%3Bdashed%3D0%3BflipH%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-553%22%20y%3D%22265%22%20width%3D%2293%22%20height%3D%2240%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2210%22%20value%3D%22Has%22%20style%3D%22endArrow%3Dopen%3BendSize%3D12%3Bdashed%3D1%3Bhtml%3D1%3Brounded%3D0%3BexitX%3D0.69%3BexitY%3D0.729%3BexitDx%3D0%3BexitDy%3D0%3BexitPerimeter%3D0%3BentryX%3D0.38%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3BentryPerimeter%3D0%3B%22%20edge%3D%221%22%20source%3D%222%22%20target%3D%225%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%22160%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-460%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-300%22%20y%3D%22250%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2211%22%20value%3D%22Use%22%20style%3D%22endArrow%3Dopen%3BendSize%3D12%3Bdashed%3D1%3Bhtml%3D1%3Brounded%3D0%3BexitX%3D0.22%3BexitY%3D0.971%3BexitDx%3D0%3BexitDy%3D0%3BexitPerimeter%3D0%3BentryX%3D0.83%3BentryY%3D0.014%3BentryDx%3D0%3BentryDy%3D0%3BentryPerimeter%3D0%3B%22%20edge%3D%221%22%20source%3D%222%22%20target%3D%224%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%22160%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-460%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-300%22%20y%3D%22250%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2212%22%20value%3D%22Has%22%20style%3D%22endArrow%3Dopen%3BendSize%3D12%3Bdashed%3D1%3Bhtml%3D1%3Brounded%3D0%3BexitX%3D0.55%3BexitY%3D0.871%3BexitDx%3D0%3BexitDy%3D0%3BexitPerimeter%3D0%3BentryX%3D0.75%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%225%22%20target%3D%223%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%22160%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-460%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-300%22%20y%3D%22250%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2213%22%20value%3D%22Has%22%20style%3D%22endArrow%3Dopen%3BendSize%3D12%3Bdashed%3D1%3Bhtml%3D1%3Brounded%3D0%3BexitX%3D0.46%3BexitY%3D0.957%3BexitDx%3D0%3BexitDy%3D0%3BexitPerimeter%3D0%3BentryX%3D0.413%3BentryY%3D-0.02%3BentryDx%3D0%3BentryDy%3D0%3BentryPerimeter%3D0%3B%22%20edge%3D%221%22%20source%3D%225%22%20target%3D%228%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%22160%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-460%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-300%22%20y%3D%22250%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2214%22%20value%3D%22Has%22%20style%3D%22endArrow%3Dopen%3BendSize%3D12%3Bdashed%3D1%3Bhtml%3D1%3Brounded%3D0%3BexitX%3D0.19%3BexitY%3D0.957%3BexitDx%3D0%3BexitDy%3D0%3BexitPerimeter%3D0%3BentryX%3D0.624%3BentryY%3D0.05%3BentryDx%3D0%3BentryDy%3D0%3BentryPerimeter%3D0%3B%22%20edge%3D%221%22%20source%3D%225%22%20target%3D%229%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%22160%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-460%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-300%22%20y%3D%22250%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2215%22%20value%3D%22Is-A%22%20style%3D%22html%3D1%3BverticalAlign%3Dbottom%3BendArrow%3Dblock%3Bcurved%3D0%3Brounded%3D0%3BexitX%3D0%3BexitY%3D0.5%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.02%3BentryY%3D0.414%3BentryDx%3D0%3BentryDy%3D0%3BentryPerimeter%3D0%3B%22%20edge%3D%221%22%20source%3D%227%22%20target%3D%224%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%2280%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-360%22%20y%3D%22180%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-280%22%20y%3D%22180%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2216%22%20value%3D%22Is-A%22%20style%3D%22html%3D1%3BverticalAlign%3Dbottom%3BendArrow%3Dblock%3Bcurved%3D0%3Brounded%3D0%3BexitX%3D0%3BexitY%3D0.5%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0%3BentryY%3D0.629%3BentryDx%3D0%3BentryDy%3D0%3BentryPerimeter%3D0%3B%22%20edge%3D%221%22%20source%3D%226%22%20target%3D%224%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%2280%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-420%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-340%22%20y%3D%22250%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E



After this stage, we usually convert the information categories into data producing ER-Diagrams

An important consideration that is usually ignored is, what happens when a product is up and running for a sample period Eg. 5yrs where CRUD operations especially deletions take place.

Some standard practices are unwritten principles, 
  • if ACTION = DELETE, default it to soft-deletion keeping it in active storage. 
  • Deciding to push data to cold storage for archival if primary storage has grown considerably, 
  • Elimination process of data ageing based on years of inactivity.

At the discovery phase of the Information view, if it is feasible, it is a good idea to strategize solutioning data ageing conditions whether backup Vs archival as is or differentially or transform data to suit purposes of learning or analytics.

How do we know if this analysis is feasible?
a. If the product has CRUD transactions, management of data as part of activities done, then thinking about retention and archival can be solutioned at this stage

b. If the product is has extensive realtime processing such as creation of algorithms, then the benchmarking for information that become candidates for archival, could be arrived only after a couple of pilot tests.

For the given use case, let's try to think of ways to archive
Information categories and strategies for archival for the Simple management system
1. Company: CASE ACTIVE, then in active storage
                     CASE DELETED, then soft-deleted but in active storage
                               DELETED, PERIOD > 1yr, then data required for reporting archived, without violating IP
                                                     Eg: Company Name, Company Id, Total Employees, Subsystems used, Highly used Subsystems / day / year

 

2. Employee: CASE ACTIVE, then in active storage
                      CASE DELETED, PERIOD < 1yr, move to cold storage info as is
                      CASE DELETED, PERIOD > 5yrs, then transform data to be archived for analytics purpose
                                                                     Eg: Emp name, Emp Id, Performance index, last designation, total years in employment, compliants or non-compliances etc

 

3.  Designation & Department: CASE ACTIVE, then in active storage
                                                   CASE DELETED, soft-delete but in active storage

 

4. Subsystems: CASE ACTIVE, then in active storage
                         CASE DELETED, PERIOD > 1yr, then cold storage as is

Thursday, 9 March 2023

C# Basic Boiler plating code for absolute beginners

 The following syntaxes are helpful in boiler-plate coding of any application. Here, we shall focus on the C# language. Please note, we are speaking of the common syntaxes that are used in every application. This is not a cheatsheet of all possible C# syntaxes.

We have seen in the post: Coding Best Practices - Part 1 article, about writing boiler-plate code.

Boiler-plate code is just creating the structure of an application, without a logic.

In .Net, everything is an object, hence the basic operating paradigm happens to be OOPs.

C# is a modern language created for .Net and also operates on OOPs.

In any application developed using the OOPs paradigm, following entities become very important

  • Namespaces: Logical grouping of code entities such as class, interface, enum, delegate, events
  • Class: A blueprint of a real-world object
    • Properties: Special variables with getters, setters. The main purpose is to share information with other classes, assemblies (executable version of a project)
    • Methods: Functions that contain logic.
  • Interface: A code contract, that is agreed upon by classes as required
  • Relationships:
    • Inheritance: Parent-Child Relations. In C#, we use ":" to indicate an inheritance / contract implementation
      • Eg: class Circle : Shape{...}
        • Here Shape is a normal class
      • Eg: class Circle: Shape, IPaintContract{...}
        • Here, IPaintContract is an interface
    • Association: Here one class contains a property, parameter of another class
      • class Circle

        {

           //Property of type Compass. Here Compass is a class

           public Compass DrawingTool {get; set;}

        }

         

        Class Compass{ ... }

Lets take an example of an application such as Employee Management System

  • It would contain
    • Classes like Person, Employee, Project, Department etc.
    • Namespaces for grouping a category of classes
    • Relationships
    • Contracts like IEmployeeContract

Here are the syntaxes for

  • Namespace: Syntax: namespace <namespace_name>{ ... }

    • namespace EMP

      {

      }

  • Class: Syntax: <access-specifier> class <class_name>{ ... }

    • Here, <access-specifier> can be one out of
      • public
        • Shareable and accessible in a given assembly and across different assemblies
      • private
        • Not shareable / accessible outside the class scope
      • protected
        • Shareable / accessible only to classes related through inheritance
      • internal
        • Shareable and accessible only within the assembly where it is created.

    • public class Person {

                         

       }

       

      public class Employee {

                         

       }

       

  • Interface

    • interface IEmpContract

      {

      }

       

  • Relationship. In this case, the relationship of inheritance

    • Class Employee : Person, IEmpContract{

      ...

      }