DEV Community: Huzaifa Rasheed

Valid Sudoku Algo - Leetcode

Huzaifa Rasheed — Tue, 21 Mar 2023 18:50:34 +0000

So the other day I was doing some leetcode and found the Valid Sudoku problem interesting. Also since I had not posted for a long time (missed it 😁), thought why not just write how I solved, so here it goes.

Algorithm (I followed)

1- Map over each row of the board, check if row has duplicate numbers
2- Map over each column of the board, check if column has duplicate numbers
3- Map over each row of the board, if that row is the start of a unique 3x3 matrix, then create three 3x3 matrices and check for duplicates

We can check for each test case in a single map

Implementation (JavaScript)

/**
 * @param {character[][]} board
 * @return {boolean}
 */
var isValidSudoku = function (board) {
    // map over each row
    for (let row = 0; row < board.length; row++) {
        // we will store and check for dup digits
        const foundRowDigits = [];
        const foundColDigits = [];

        // map over each column
        for (let col = 0; col < board.length; col++) {
            const rowDigit = board[row][col]
            if (rowDigit !== '.') { // we are ignoring periods '.'
                // check duplicates in row
                if (foundRowDigits.includes(rowDigit)) {
                    // oh uh, dup found -> invalid sudoku
                    return false
                }

                foundRowDigits.push(rowDigit) // store row digit for further comparison
            }

            const colDigit = board[col][row]
            if (colDigit !== '.') { // we are ignoring periods '.'
                // check duplicates in row
                if (foundColDigits.includes(colDigit)) {
                    // oh uh, dup found -> invalid sudoku
                    return false
                }

                foundColDigits.push(colDigit) // store row digit for further comparison
            }
        }


        if (row % 3 === 0) { // row is the start of 3 3x3 matrices
            let threeByThreeGrid = [] // we will store grid values to check dups
            let rowIndex = row

            for (let colIndex = 0; colIndex < 9; colIndex += 3) {
                // make 3x3 grid by taking a rowIndex and colIndex
                for (let gridRowIndex = rowIndex; gridRowIndex < rowIndex + 3; gridRowIndex++) {
                    for (let gridColIndex = colIndex; gridColIndex < colIndex + 3; gridColIndex++) {
                        const digit = board[gridRowIndex][gridColIndex]
                        if (digit !== '.') { // we are ignoring periods '.'

                            // check if there are duplicates in a 3x3 matrix
                            if (threeByThreeGrid.includes(digit)) {
                                // oh uh, dup found -> invalid sudoku
                                return false
                            }

                            threeByThreeGrid.push(digit) // store row digit for further comparison
                        }
                    }
                }

                threeByThreeGrid = [] // reset the grid
            }
        }
    }

    return true // if above test cases passed then sudoku is valid
};

Time complexity

O(n^2) - We have 2 nested for loops. The 3x3 subgrids only work in certain cases so going for the worst case we have O(n^2)

Space complexity

O(1)

Test Cases

A valid sudoku

const validSudoku = [
    ["5", "3", ".", ".", "7", ".", ".", ".", "."],
    ["6", ".", ".", "1", "9", "5", ".", ".", "."],
    [".", "9", "8", ".", ".", ".", ".", "6", "."],
    ["8", ".", ".", ".", "6", ".", ".", ".", "3"],
    ["4", ".", ".", "8", ".", "3", ".", ".", "1"],
    ["7", ".", ".", ".", "2", ".", ".", ".", "6"],
    [".", "6", ".", ".", ".", ".", "2", "8", "."],
    [".", ".", ".", "4", "1", "9", ".", ".", "5"],
    [".", ".", ".", ".", "8", ".", ".", "7", "9"]
]

console.log(isValidSudoku(validSudoku)) // true

A sudoku with dups in row

const sudokuWithRowDups = [
    ["5", "3", ".", ".", "7", ".", ".", ".", "5"],
    ["6", ".", ".", "1", "9", "5", ".", ".", "."],
    [".", "9", "8", ".", ".", ".", ".", "6", "."],
    ["8", ".", ".", ".", "6", ".", ".", ".", "3"],
    ["4", ".", ".", "8", ".", "3", ".", ".", "1"],
    ["7", ".", ".", ".", "2", ".", ".", ".", "6"],
    [".", "6", ".", ".", ".", ".", "2", "8", "."],
    [".", ".", ".", "4", "1", "9", ".", ".", "5"],
    [".", ".", ".", ".", "8", ".", ".", "7", "9"]
]

console.log(isValidSudoku(sudokuWithRowDups)) // false

A sudoku with dups in col

const sudokuWithColDups = [
    ["8", "3", ".", ".", "7", ".", ".", ".", "."],
    ["6", ".", ".", "1", "9", "5", ".", ".", "."],
    [".", "9", "8", ".", ".", ".", ".", "6", "."],
    ["8", ".", ".", ".", "6", ".", ".", ".", "3"],
    ["4", ".", ".", "8", ".", "3", ".", ".", "1"],
    ["7", ".", ".", ".", "2", ".", ".", ".", "6"],
    [".", "6", ".", ".", ".", ".", "2", "8", "."],
    [".", ".", ".", "4", "1", "9", ".", ".", "5"],
    [".", ".", ".", ".", "8", ".", ".", "7", "9"]
]

console.log(isValidSudoku(sudokuWithColDups)) // false

A sudoku with dups in 3x3 matrices

const sudokuWith3x3GridDups = [
    [".", ".", ".", ".", "5", ".", ".", "1", "."],
    [".", "4", ".", "3", ".", ".", ".", ".", "."],
    [".", ".", ".", ".", ".", "3", ".", ".", "1"],
    ["8", ".", ".", ".", ".", ".", ".", "2", "."],
    [".", ".", "2", ".", "7", ".", ".", ".", "."],
    [".", "1", "5", ".", ".", ".", ".", ".", "."],
    [".", ".", ".", ".", ".", "2", ".", ".", "."],
    [".", "2", ".", "9", ".", ".", ".", ".", "."],
    [".", ".", "4", ".", ".", ".", ".", ".", "."]
]

console.log(isValidSudoku(sudokuWith3x3GridDups)) // false

It may not be perfect, and can always be improved. Let me know your thoughts and thanks for reading.

How to Avoid Default Props Render Trap in React

Huzaifa Rasheed — Sun, 20 Feb 2022 18:44:27 +0000

What is it?

Let's say we have a component with a default prop like this



import React, { useEffect, useState } from "react";

const RerenderChild = ({ value = [] }) => {
  const [valueFromProp, setValueFromProp] = useState([]);

  useEffect(() => {
    setValueFromProp(value);
  }, [value]);

  return (
    <div>
     {/* ...component */}
    </div>
  );
};

export default RerenderChild;

Whenever the value prop is nullish (not set by the calling component), the useEffect causes the component to render infinitely. This is the Default Props Render Trap. We get something like this in the browser console.

Why It Happens

When we don't provide the value for the value prop it takes the default value provided as argument, which in our case is []. This triggers the useEffect hook which updates the valueFromProp state. The state change causes the component to re-render.

Now when the component re-renders, it takes the new prop values which again are the default one's. This again triggers the useEffect and the whole cycle repeats. That's why we end up with an infinite loop.

The Solution

We have to make the default prop values a part of our component definition. We can do that in these ways.

1. Use defaultProps property.

We can set the default props value by using the component's defaultProps property. Our component now becomes



import React, { useEffect, useState } from "react";

const RerenderChild = ({ value }) => {
  const [valueFromProp, setValueFromProp] = useState([]);

  useEffect(() => {
    setValueFromProp(value);
  }, [value]);

  return (
    <div>
      {/* ...component */}
    </div>
  );
};

RerenderChild.defaultProps = {
  value: [],
};

export default RerenderChild;

2. Declare default props as constants.

We can declare constants outside of our component and set them as our default prop value.



import React, { useEffect, useState } from "react";

const DEFAULT_VALUE = [];

const RerenderChild = ({ value = DEFAULT_VALUE }) => {
  const [valueFromProp, setValueFromProp] = useState([]);

  useEffect(() => {
    setValueFromProp(value);
  }, [value]);

  return (
    <div>
      {/* ...component */}
    </div>
  );
};

export default RerenderChild;

Hope this helps you to avoid the infinite loop. Thanks 😊.

Running Batch Requests In Postman

Huzaifa Rasheed — Sun, 13 Feb 2022 12:59:30 +0000

I recently faced a situation where I had to run bulk/batch requests in postman. There are other ways to seed data like a custom script, but let's just focus on how to do it with postman.

Making Batch Requests in Postman

We will need some setup to demonstrate so let's create one.

1. Setup
I created a simple express server with 2 endpoints for creating and returning data. We will store the data in a variable and run the server at port 3000.



const express = require("express");
const bodyParser = require("body-parser");
const app = express();
const port = 3000;

// parse request data
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

let data = [];

app.get("/", (req, res) => res.json(data).status(200));

app.post("/", (req, res) => {
  data = [...data, req.body];
  res.json(req.body).status(201);
});

app.listen(port, () => console.log(`App listening on port ${port}`));

Now, let's move to postman and create a collection (I am calling it Data Endpoints)

Now let's create 2 requests in the collection (for the 2 endpoints from express server).

Get Data
Insert Data

We will be inserting this data. Let's save it in a file (seedData.json).



[
  {
    "id": 1,
    "first_name": "Gary",
    "last_name": "Ortiz"
  },
  {
    "id": 2,
    "first_name": "Albert",
    "last_name": "Williamson"
  },
  {
    "id": 3,
    "first_name": "Mildred",
    "last_name": "Fuller"
  },
  {
    "id": 4,
    "first_name": "Russell",
    "last_name": "Robinson"
  },
  {
    "id": 5,
    "first_name": "Laura",
    "last_name": "Harper"
  },
  {
    "id": 6,
    "first_name": "Larry",
    "last_name": "Sanders"
  },
  {
    "id": 7,
    "first_name": "Michael",
    "last_name": "Rice"
  },
  {
    "id": 8,
    "first_name": "Sara",
    "last_name": "Harris"
  },
  {
    "id": 9,
    "first_name": "Phyllis",
    "last_name": "Webb"
  },
  {
    "id": 10,
    "first_name": "Roger",
    "last_name": "Alvarez"
  }
]

Now, our setup is complete. Next we will run the actual batch requests.

2. Running Batch Requests
We will be inserting data, so we will need to modify our 'Insert Data' request to allow dynamic data. Something like this

Then, we will need to run the collection.

And select our seedData.json file along with the 'Insert Data' request (then click the 'Run Data Endpoints' button).

It will run the batch requests and give us the results, something like this.

We can use the Get Data request to re-validate data insertion.
.

And that's it. Hope this helps you in your Projects. Thanks 😉

Add Google reCAPTCHA v2 to plain HTML

Huzaifa Rasheed — Sat, 12 Feb 2022 19:10:08 +0000

What is it?

A CAPTCHA is a test that helps to tell the difference between a bot and a human.

The reCAPTCHA is Google's implemenation of a CAPTCHA. Its very easy to integrate, without any third party libraries.

What's The Purpose?

A reCAPTCHA can keep malicious software/bots from engaging in abusive activities on your website while allowing legitimate users access to your site.

How to Integrate?

We will be using the v2 version.

1. Create a site key
You can create a site key from Google reCAPTCHA Admin Page.

You also will need to add a site domain, where you would deploy the site. For testing you can add localhost and use the loopback address (127.0.0.1) or use a key from reCAPTCHA automated tests guide. One of those keys is

6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI

which we will use in our example.

2. Add Widget to Markup
The only thing we will need to add to our HTML is

<div
  class="g-recaptcha"
  data-sitekey="6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI"
>
</div>

this can be added to a form or used without one, depending on the use case. Source

We will also need to add a cdn link to the head tag.

<script src="https://www.google.com/recaptcha/api.js" async defer>
</script>

We can listen to callbacks from the widget and register our own handlers.

<div
  class="g-recaptcha"
  data-sitekey="6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI"
  data-callback="onRecaptchaSuccess"
  data-expired-callback="onRecaptchaResponseExpiry"
  data-error-callback="onRecaptchaError"
>
</div>

these callbacks can be used to validate or invalidate our form or whatever we want to do.

I made a simple form that submits successfully when the reCAPTCHA validates successfully, its here. I also added some basic styling to have a decent look and feel.

Hope this helps you in your Projects. Thanks for reading 😉.

How do abstract Socket.IO connections in your SPA.

Huzaifa Rasheed — Thu, 10 Feb 2022 18:49:58 +0000

When working with socketIO client in your SPA, it may become very hard to manage the socket instance, events emitters, and work with the callbacks in different places of the app. Especially when there are multiple different servers to connect with. What can be done?

Solution

We can create a closure that takes event callbacks as functions and return event emitters, to abstract socketIO implementation in a single file (let's call it SocketManager.js).

Example

import io from "socket.io-client";

const SocketManager = ({
  onCallback = () => {},
}) => {
  const socket = io(/* server url to connect */);

  // Callbacks
  socket.on('callback-event-name', (payload) => {
    onCallback && onCallback(payload);
  });

  // Emitters
  const emitEvent = (eventPayload) => {
    socket.emit('emit-event-name', eventPayload);
  };

  return {
    socket,
    emitEvent
  };
};

export default SocketManager;

then we can use this in our React code like this

import React from "react";
import SocketManager from "./SocketManager.js";

const SocketConsumer = () => {
  const { emitEvent } = SocketManager({
    onCallback: handleCallback,
  });

  const handleCallback = (payload) => {
    /** Do something with the payload */
  };

  return <button onClick={emitEvent}>Fire Event</button>;
};

export default SocketConsumer;

Hope this helps you in your projects. Thanks 🙂

Regex? The Minimum You Need To Know.

Huzaifa Rasheed — Tue, 06 Apr 2021 21:59:35 +0000

You might have noticed when filling out an online form for email or password, you sometimes get validation errors like email must be valid or password must be 8 digits long. Something like this 👇

These are places where REGEX is used.

What Is Regex?

Regex is short for Regular Expressions.

A sequence of characters that specifies a search pattern. These patterns are mostly used by string-searching algorithms to find or find and replace character/s. Thus they can be used for validations and mostly you will be using Regex for them.

How To Use Regex?

You can use different functions for matching regex with your data. In PHP there are functions starting with preg_ that mostly match regex (see Regex for Php) while In JavaScript, regex are also objects. You can see some of the regex functions for JavaScript on Javascript Regex Guide.

Basic Validations

There are a number of online regex engines that you can use to quickly test out your regex expression. I mostly use Regex101 because I like it. The following examples are tested on Regex101.

Email

/^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/

Password

Minimum eight characters, at least one uppercase letter, one lowercase letter, and one number

/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)[a-zA-Z\d]{8,}$/

For more password validations, Check out the answer on stackoverflow

Numbers Only

To match 0 or many numbers
/^[0-9]*$/

To match 1 or many numbers
/^[0-9]+$/

To match exactly 1 number
/^[0-9]$/

If you add one more number in the test string, the validation will fail.

Phone Numbers Only

This is a little difficult to explain as different countries have different phone numbers, codes, etc., you know what I am talking about.

For my number, and I have an 11 digit number(Pakistani Phone Number), I use the following regex
/^((\+92)|(0092))-{0,1}\d{3}-{0,1}\d{7}$|^\d{11}$|^\d{4}-\d{7}$/

It validates the phone number with and without the country code like the following do pass

00923000000000
+923000000000
03000000000

I would suggest that for a good reference, check out Google's Library for validating international phone numbers. This is not regex but it gets the job done if are on the run.

Characters Only

To match for 1 or many characters
/^[A-Za-z]+$/

To match 0 or many characters you can use /^[A-Za-z]*$/
To match exactly 1 character you can use /^[A-Za-z]$/

Of course, there are other combinations you can explore.

URL Matching

The following will mostly match the URLs you want to
^(?:(?:https?|ftp):\/\/)(?:\S+(?::\S*)?@)?(?:(?!(?:10|127)(?:\.\d{1,3}){3})(?!(?:169\.254|192\.168)(?:\.\d{1,3}){2})(?!172\.(?:1[6-9]|2\d|3[0-1])(?:\.\d{1,3}){2})(?:[1-9]\d?|1\d\d|2[01]\d|22[0-3])(?:\.(?:1?\d{1,2}|2[0-4]\d|25[0-5])){2}(?:\.(?:[1-9]\d?|1\d\d|2[0-4]\d|25[0-4]))|(?:(?:[a-z\u00a1-\uffff0-9]-*)*[a-z\u00a1-\uffff0-9]+)(?:\.(?:[a-z\u00a1-\uffff0-9]-*)*[a-z\u00a1-\uffff0-9]+)*(?:\.(?:[a-z\u00a1-\uffff]{2,}))\.?)(?::\d{2,5})?(?:[/?#]\S*)?$

This however does not match port numbers, Like it would not match https://regex101:9000.com/?page=1. So you should have a general idea of what type of URL you want to match.

I suggest seeing Regex For URL that has different implementations of Php and Js that you can play with.

Which Language Supports Regex?

Almost every major language has support for regex.

To be more clear, implementations of regex functionality are called a regex engine, and a number of libraries are available for reuse which different languages do use.

Regex syntax may vary slightly between languages but for the most part, it is the same.

Now Some Theory.

Fun is over guys, now we are moving towards the theory. Jokes aside, Most of you don't need to know everything about regex in detail, the same with a programming language, we can't learn everything about them.

But you should know that 👇

A Regex can have

Tokens
Anchors
Meta Sequences
Quantifiers
Group Constructs
Character Classes
Flag/Modifiers
Substitution

If you want to learn and practice them at the same time then I would again suggest, goto Regex101. It has a good reference for the regex operators. 👇
and I think I don't need to explain more 😉

Fun Part While Writing The Article

I found a regex from StackOverflow that was matching non-ASCII characters and it matched every word I tried of any language. Even in my native language Urdu it matched اِسلامی جمہوریہ پاكِستان

I don't know if it's useful or not, but I will add it in the comments.

Tip

More like a best practice. You should do regex validations on both the frontend and backend of your code. Just in case someone tries to manipulate the frontend, your backend will not validate the invalid data.

Note: You can also use HTML5 Input Types for validating some form fields on the frontend, but for the backend you need regex.

Conclusion

So did you use regex for a complex match sometime or you just got to know about it? Also, give a 💖 or a 🦄 if you like the article.

Solid. Is It Still Useful In 2021?

Huzaifa Rasheed — Sat, 03 Apr 2021 22:52:30 +0000

Why Even Bother?

In the software development world, there are 2 extremes.

People who don't follow best practices.
People who follow them to the extreme.

If you are lazy like me you mostly don't follow best-practices because YAGNI(You aren't gonna need it) but if you are like me you mostly do follow best-practices like SOLID Design Principles.

Wait. Why am I on both sides? Because I follow both depending on what I am doing. If it's simple, limited/scoped, and predictable then who needs to overthink about best practices but if it's complex, may-become-complex, should be scalable and maintainable then yeah, we need best practices.

If you are building a system that would need changes in the future then you are going to be happy about how SOLID can make your life easy.

What is SOLID?

SOLID is an acronym for 5 principles

S. 👉 Single Responsibility
O. 👉 Open/Close
L. 👉 Liskov Substitution
I. 👉 Interface Segregation
D. 👉 Dependency Inversion

They aim to make your code manageable, maintainable, and scalable along with other benefits.

Note

They are not Rules, but best practices.

The Person Behind SOLID

This was in the year 2000. Robert C. Martin first introduced SOLID as a subset of different design principles in his paper Design Principles and Design Patterns.

Design principles and patterns are different, SOLID are principles.

So What Do The Principles Mean?

Each SOLID principle aims to achieve a certain goal by following a certain rule.

1. Single Responsibility Principle

It aims to separate behaviors or concerns. Meaning that every piece of code should have a specific purpose of existence and it should be used for that purpose only.

Example

The following function should only validate a user given their id.

function validateUser(userId){
    // will validate user with their userId
}

For a complete reference, check out the Single Responsibility Principle in detail.

2. Open/Close Principle

The goal is to prevent those situations in which changing a piece of code from a module also requires us to update all depending modules. Basically, we don't allow new code to make changes to our old code.

We can extend code but not modify it. One real-life use case is of those softwares that have backward compatibility.

Example

A typescript example

interface PaymentMethod {
  pay() : boolean
}

class Cash implements PaymentMethod {
  public pay(){
    // handle cash pay logic here
  }
}

function makePayment(payMethod: PaymentMethod) {
  if(payMethod.pay()){
    return true;
  }
  return false;
}

In the above code if we want to add credit card payment all we have to do is add the following code (along with the actual implementation) and it will work just fine

class CreditCard implements PaymentMethod {
  public pay(){
    // handle credit pay logic here
  }
}

For a complete reference, check out my other article on Open/Close Principle.

3. Liskov Substitution Principle

What this principle tells us is that if we replace an instance of a child class with a parent class, our code should still work fine without breaking or having side effects.

Example

class Printer{
    function changeSettings(){
        // common functionality
    }

    function print(){
        // common functionality
    }
}

class LaserPrinter extends Printer{
    function changeSettings(){
        // ... Laser Printer specific code
    }

    function print(){
        // ... Laser Printer specific code
    }
}

class _3DPrinter extends Printer{
    function changeSettings(){
        // ... 3D printer specific code
    }

    function print(){
        // ... 3D printer specific code
    }
}

This principle however has its limitations some of which I discussed in its own separate article. See Liskov Substitution Principle for an example of its limitations.

4. Interface Segregation Principle

This principle aim's to use role interfaces (or role modules in general) which are designed for a specific purpose and should only be used for those. It says

Clients Should Not Be Forced To Depend Upon Interfaces That They Do Not Use.

This principle solves some of the issues with the Interface Segregation Principle like the Bird example I mentioned in my article on Liskov Substitution Principle

Example

This is a typescript example but still not too difficult to understand.

interface BirdFly{
    fly(): void;
}

interface BirdWalk{
    walk(): void;
}

class Duck implement BirdFly, BirdWalk{
    fly(){
        // Duck can fly
    }   
    walk(){
        // Duck can walk
    }
}

class Ostrich implement BirdWalk{
    walk(){
        // Ostrich can walk
    }
}

For a complete reference, check out the Interface Segregation Principle in detail.

5. Dependency Inversion Principle

It focuses on using abstraction or facade/wrapper patterns to hide details of low-level modules from their high-level implementation.

We basically create wrapper classes that sit in between high-level and low-level modules. This helps a lot if the low-level implementations are different from each other.

Example

Again a typescript example

interface Payment {
    pay(): boolean
}

// (Wrapper/Abstraction around cash payment)
class CashHandler implements Payment {
    constructor(user){
        this.user = user
        this.CashPayment = new CashPayment();
    }

    pay(amount){
        this.CashPayment.pay(amount)
    }
}

// (low-level module)
class CashPayment {
    public pay(amount){
        // handle cash payment logic
    }
}

// (High-level Module)
function makePayment(amount: number, paymentMethod: Payment){
    if(paymentMethod.pay(amount)){
        return true;
    }
    return false;
}

For a complete reference, check out the Dependency Inversion Principle in detail.

When To Use What And Avoid What

Now that we know a brief about each principle, we will look at when to use and avoid them.

	Use	Avoid
Single Responsibility	For Scalable and Maintainable Code.	When too much Fragmentation occurs without predictable future changes.
Open Close	To prevent old code from breaking due to a new one.	When over-engineering.
Liskov Substitution	Parent/Child used interchangeably without breaking.	When substitutions do not make sense. (Bird example)
Interface Segregation	For Role-specific interfaces.	When difficult to aggregate (due to a lot of modules) from segregation.
Dependency Inversion	For different low-level implementations.	When different implementations of a low-level module are not needed, like the String class in most languages are not changed because it's not needed to mostly.

These are mostly the reasons and you can disagree but it all comes down to what you are dealing with.

Is SOLID Still Useful in 2021?

Ask yourself. Is there a language that does everything with one line of code?

do_everything();

I guess not, unless you or someone makes a language that uses less code than python and does everything with one line of code, you do need SOLID design principles.

Of course, there are extremes and cases where it's just not possible to implement SOLID, but if you are comfortable and can use SOLID then you probably should.

Conclusion

So, what's your take on this? Do you follow an approach similar to mine? Be sure to give this article a 💖 if you like it.

Why The Dependency Inversion Principle Is Worth Using

Huzaifa Rasheed — Thu, 01 Apr 2021 22:13:51 +0000

Dependency Inversion is the D of SOLID, and you may wonder, what is SOLID?

SOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.

Rules and Conventions have their place. In code, the SOLID design is considered a convention/best-practice.

Now what is Dependency Inversion?

Basically

High-Level Modules Should Not Depend Upon Low-Level Modules. Both Should Depend Upon Abstractions.

Not too difficult. Right? Here is more

Abstractions Should Not Depend Upon Details. Details
Should Depend Upon Abstractions.

Too confusing? This might help

What This Means

✔️ Both High-level and Low-level modules should depend on the same Abstraction.
✔️ High-level modules should implement abstractions that implement Low-Level modules and vice-versa.
✔️ Abstractions can implement different details of the operation.
❌ High-level modules can implement details surpassing abstractions.

Goal

Follow an abstract/facade/wrapper pattern.
Hide Low-Level implementation from High-Level Implementation.

A Simple Use Case

We will continue with the payment example from Open/Close Principle. But for this example at the moment we only accept cash payment.

interface Payment {
    pay(): boolean
}

class CashPayment implements Payment {
    public pay(amount){
        // handle cash payment logic
    }
}

function makePayment(amount: number, paymentMethod: Payment){
    if(paymentMethod.pay(amount)){
        return true;
    }
    return false;
}

In this particular example, makePayment() is a high-level module and CashPayment is a low-level module. It clearly has no wrapper/abstraction layer.

Now, what if we want to add credit card payment? We might modify our code like this

interface Payment {
    pay(): boolean
}

// (low-level module)
class CashPayment implements Payment {
    constructor(user){
        this.user = user
    }

    public pay(amount){
        // handle cash payment logic
    }
}

// (low-level module)
class CreditCardPayment implements Payment {
    constructor(user){
        this.user = user
    }

    public pay(amount, creditCardId){
        // handle creditCard payment logic
    }
}


// (High-level Module)
function makePayment(amount: number, paymentMethod: Payment){

    if(paymentMethod instanceof CashPayment){
        if(paymentMethod.pay(amount)){
            return true;
        }
    }

    if(paymentMethod instanceof CreditCardPayment){
        if(paymentMethod.pay(amount,paymentMethod.user.creditCardId)){
            return true;
        }
    }

    return false;
}

This clearly violates the Dependency Inversion principle since the high-level module is implementing details for low-level modules. It also violates the Single Responsibility Principle.

Using Dependency Inversion, we will make wrapper classes or abstractions around cash and credit payment implementations.

interface Payment {
    pay(): boolean
}

// (Wrapper/Abstraction around cash payment)
class CashHandler implements Payment {
    constructor(user){
        this.user = user
        this.CashPayment = new CashPayment();
    }

    pay(amount){
        this.CashPayment.pay(amount)
    }
}

// (low-level module)
class CashPayment {
    public pay(amount){
        // handle cash payment logic
    }
}


// (Wrapper/Abstraction around credit card payment)
class CreditCardHandler implements Payment {
    constructor(user){
        this.user = user
        this.CreditCardPayment = new CreditCardPayment();
    }

    pay(amount){
        this.CreditCardPayment.pay(amount, this.user.creditCardId)
    }
}

// (low-level module)
class CreditCardPayment {
    public pay(amount, creditCardId){
        // handle creditCard payment logic
    }
}


// (High-level Module)
function makePayment(amount: number, paymentMethod: Payment){
    if(paymentMethod.pay(amount)){
        return true;
    }
    return false;
}

As we can see now our high-level modules are separated by an abstract layer hiding the details of low-level implementation. We inverted the dependencies.

Why Dependency Inversion is Worth Using?

Consider This

We want to add PayPal and WireTransfer Payment Options to our existing code (the example we just did). It can be done easily without touching our existing code. We only have to add low-level and wrapper implementations for PayPal and WireTransfer Payments. Thus, our High-level implementations never break since we are not touching it.

Also

We create resilient and reusable code.
Code that is easier to maintain.
Easier to test individual code components.
We prevent code breakages by not touching high-level implementation

The pattern for other SOLID principles like Interface Segregation and Liskov Substitution is much similar in terms of code breakages i.e : Avoid Them in the long run.

Here it is guys. Do you use Dependency Inversion? Be sure to tell me your opinion in the comments and give this article a Heart 💖 if you liked it.

Is It Practical To Use Interface Segregation Principle?

Huzaifa Rasheed — Wed, 31 Mar 2021 18:05:02 +0000

SOLID is a very popular design concept in programming. Interface Segregation is part of SOLID Design. You may ask, what is SOLID?

SOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.

In code, you have best-practices and rules. SOLID designs are like best-practices.

Interface Segregation

It says

Clients Should Not Be Forced To Depend Upon Interfaces That They Do Not Use.

Pretty straightforward.

What This Means

✔️ Create smaller and specific interfaces (role interfaces).
❌ Classes can implement interfaces they don't use.

Why do this?

Consider

A client depends upon a class that contains interfaces the client does not use, but other clients do use, then the first client will be affected by the changes other clients force upon the class used by the first client.

The Goal of this principle is to avoid these situations.

The pattern for other SOLID principles like Single Responsibility and Open Close is much similar : To avoid code breakages in the long run.

A Simple Use Case

Using the Bird example much similar to that discussed in Liskov Substitution.

interface Bird {
  fly(): void;
  walk(): void;
}

class Duck extends Bird{
    fly(){
        // Duck can fly
    }   
    walk(){
        // Duck can walk
    }
}

class Ostrich extends Bird{
    fly(){
        // Ostrich cant fly... throw some error
    }   
    walk(){
        // Ostrich can walk
    }
}

Here fly() is enforced to an Ostrich class by the Duck class, since both implement the same interface and Duck does use fly(). It is a clear violation of the Interface Segregation Principle.

Using the Interface Segregation Principle we refactor our code to be

interface BirdFly{
    fly(): void;
}

interface BirdWalk{
    walk(): void;
}

class Duck extends BirdFly, BirdWalk{
    fly(){
        // Duck can fly
    }   
    walk(){
        // Duck can walk
    }
}

class Ostrich extends BirdWalk{
    walk(){
        // Ostrich can walk
    }
}

We have now made role-specific interfaces and there is no inadvertent coupling.

Is It Practical?

Definitely, It is best to follow this principle whenever possible. However, if your requirements are satisfied and you can work around the inadvertent coupling, then sure you can avoid this principle.

Do you use Interface Segregation? Be sure to tell me your opinion in the comments.

What's Next

Why The Dependency Inversion Principle Is Worth Using.

2 Simple Tips To Clean Nested IF/ELSE Conditions.

Huzaifa Rasheed — Tue, 30 Mar 2021 18:43:40 +0000

There might be a time when you have your if/else conditions like this

if(age>0){
    if(age < 18){
        return "Not an Adult"
    }
    else if (age >= 18 && age<60){
        return "An Adult"
    }
    else{
        return "Senior Citizen"
    }
}
else{
    return "Age must be a valid number"
}

This is however a simple example, this can get messy as your code logic gets complex.

To add more, Multiple nested if/else increases Cyclomatic complexity and it is better to avoid it whenever possible.

Cyclomatic complexity is a software metric used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program's source code. Thomas J. McCabe, Sr.

So what can you do to avoid it? Simple, Try to have fewer branches of if/else conditions achievable with the following tips.

The Tips

Guard Clauses
Ternary Operators

There are others like Switch Statement, Dictionaries, Jump Tables, etc. but those are beyond this article's scope.

1. Guard Clauses

In simple terms, return early if a condition is not met. Again taking our previous code, we can modify it like this

// Guard clause
if(age <= 0){
    return "Age must be a valid number" 
}

if(age < 18){
    return "Not an Adult"
}
else if (age < 60){
    return "An Adult"
}

return "Senior Citizen"

Or you could even do this

// Guard clause
if(age <= 0) return "Age must be a valid number"

if (age < 18) return "Not an Adult"
else if (age < 60)  return "An Adult"
else return "Senior Citizen"

Use brackets or not, scoped only to clean code.

2. Ternary Operators

Most of you already use them, but anyways. Modifying our last code

if(age <= 0) return "Age must be a valid number"

var res = (age < 18 ? "Not an Adult" 
        : (age < 60) ? "An Adult" 
        : "Senior Citizen")

return res

if(age <= 0) return "Age must be a valid number"

return (age < 18 ? "Not an Adult" : (age < 60) ? "An Adult" : "Senior Citizen")

Disclaimer: Clean code doesn't always mean Performant code or Simple Code. Sometimes you have to decide between one or the other. There is however a limit to how clean you can make your code.

So here it is guys, do you use any other method to clean nesting? Be sure to tell me in the comments.

Is The Liskov Substitution Principle Really Useful?

Huzaifa Rasheed — Mon, 29 Mar 2021 18:15:10 +0000

Liskov Substitution is part of SOLID Design. SOLID?

SOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.

Think of them as best practices.

Now What is Liskov Substitution

You see the L in SOLID stands for this principle.

It says

Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T. Barbara Liskov

Honestly, Too scientific.

In simple terms

Replacing an instance of a class with its child class should not produce any negative side effects or broken codebase.

Meaning

✔️ Can use the subclass of a parent class just the same as using the parent class without breaking anything.
✔️ Subclasses can modify/override parent class methods.
❌ Subclasses can modify the parent's method signature like arguments, return type, and exceptions.
❌ Subclasses can define a new function not present in the parent class.
❌ Parent class can be modified.

Why do this?

The Goal of this principle is to basically prevent our old codebase from breaking due to new code. This is also in line with the Single Responsibility and the Open Close Principle.

We will use a simple example for explanation.

A Simple Use Case

The following example violates the rule.

class Animal{
    function eat(){
        // common functionality
        return "Eating Now" // return type string
    }

    function sleep(){
        // common functionality
        return "I am sleeping"  // return type string
    }
}

class Cat extends Animal{
    function eat(){
        // ... cat specific code
        return "Meow, whatever human"   // return type string
    }

    function sleep(){
        // ... cat specific code

        //  voilating LSP: parnet sleep() does not return boolean
        return true 
    }
}

class Dog extends Animal{
    function eat(){
        // ... dog specific code
        return "Woof, It was tasty."    // return type string
    }

    function sleep(){
        // ... dog specific code

        //  voilating LSP: parent sleep() doesn't use Error Exception
        throw Error('I just slept') 
    }
}

With the Liskov Substitution Principle, we would modify our code as follow

class Animal{
    function eat(){
        // common functionality
        return "Eating Now" // return type string
    }

    function sleep(){
        // common functionality
        return "I am sleeping"  // return type string
    }
}

class Cat extends Animal{
    function eat(){
        // ... cat specific code
        return "Meow, whatever human"   // return type string
    }

    function sleep(){
        // ... cat specific code
        return "I am already sleeping"  // return type string
    }
}

class Dog extends Animal{
    function eat(){
        // ... dog specific code
        return "Woof, It was actually tasty."   // return type string
    }

    function sleep(){
        // ... dog specific code
        return "Zzzzzzzz"   // return type string
    }
}

With this approach, we can swap parent and child classes without breaking the code.

So Is it Helpful?

It is in most cases, but there are those cases where you might want to add some more that does not quite fit in like the Birds example below

class Bird{
    function fly(){}
}

class Duck extends Bird{}

class Ostrich extends Bird{} // Duck can fly but ostrich cant:

So yeah, it really depends. If it's getting over-complicated/over-engineered or is not making sense(like bird example) then it's best to do your own thing.

Tip

It's easy to extend old code with new code. You just have to make a new class and extend it with parent/base class without the fear of breaking the already working code. We also get this benefit from Dependency Inversion principle.

So how do you see this? Do you think it's really useful? Be sure to tell me your opinion in the comments.

Explained: OPEN/CLOSE Principle In 2 Minutes

Huzaifa Rasheed — Sun, 28 Mar 2021 22:17:18 +0000

Before we begin.

Ever heard about SOLID ?.

SOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.

They are more like best practices than rules. Open/Close is a principle of SOLID Design.

So What Is It?

Open/Close is the O of SOLID.

It says

Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. Bertrand Meyer

Like you should not re-write your existing code to be compatible with the newer one.

Meaning

✔️ Can add more code.
✔️ Can Extend functionality to old code by adding new code
❌ Can Modify old code used by other modules.

Goal

Get the system to a point where you can never break the core of your system. You can add more functionality but not modify the one used by other modules.

It is easier to follow this principle if you already follow the Single Responsibility Principle and it really comes in handy once you also follow the Liskov Substitution Principle.

This prevents those situations in which changing one class also requires you to update all depending classes.

We will use inheritance to demonstrate an example.

A SIMPLE USE CASE

Let's say someone is paying for items bought from an E-commerce store. This is what it might look like in payment.ts (ignore the syntax)

class Payment {
  public payWithCash(){
    // handle cash pay logic here

  public payWithCredit(){
    // handle credit pay logic here
  }
}

function makePayment(payMethod: string) {
  const payment = new Payment();

  if(payMethod === 'cash'){
    payment.payWithCash();
  } else if(payMethod === 'credit'){
    payment.payWithCredit();
  }
}

⚠️ What if we want to add a new payment type? We would have to add a new method and modify our code.

class Payment {
  public payWithCash(){
    // handle cash pay logic here

  public payWithCredit(){
    // handle credit pay logic here
  }

  public payWithCoupon(){
    // handle coupon pay logic here
  }
}

function makePayment(payMethod: string) {
  const payment = new Payment();

  if(payMethod === 'cash'){
    payment.payWithCash();
  } else if(payMethod === 'credit'){
    payment.payWithCredit();
  } else if(payMethod === 'coupon'){
    payment.payWithCoupon();
  }
}

This is not in line with the Open/Close Principle.

With the Open/Close Principle we would modify our code payment.ts as follows.

interface PaymentMethod {
  pay() : boolean
}

class Cash implements PaymentMethod {
  public pay(){
    // handle cash pay logic here
  }
}

class CreditCard implements PaymentMethod {
  public pay(){
    // handle credit pay logic here
  }
}

function makePayment(payMethod: PaymentMethod) {
  if(payMethod.pay()){
    return true;
  }
  return false;
}

Now if we, later on, want to add a new payment option like wire transfer then we only need to add a new class, no changes needed to the existing code.

class WireTransfer implements PaymentMethod {
  public pay(){
    // handle wire transfer pay logic here
  }
}

Since we are using the interfaces, be sure to check out if you are following Interface Segregation principle of SOLID.

Should You Use It?

You should use Open/Close if you want clean code but there are situations in which you should just go ahead and do your own stuff. It really depends on what you are doing.

Tip

You can get away with modifying your existing unit tests and just write a new one for the code you added.

So here it is. Do you like the article? Be sure to leave a comment.

What's Next

Why The Dependency Inversion Principle Is Worth Using.