DEV Community: Shubham Zanwar

Design Patterns: Chain of Responsibility ⛓

Shubham Zanwar — Sat, 07 Nov 2020 18:08:05 +0000

The Chain of responsibility pattern is a behavioral design pattern that deals with breaking down a complex problem into sequentially occurring steps. At each step, there is a possibility of moving to the next step or exiting from the chain.

To understand this better, let's understand how a basic call center would work. Think of all the stages you'd go through when you ring up the customer care of an electronics store to get some help regarding a new product you bought.

Customer Care

A generic customer care you follow the following steps:

The user would start off by interacting with an automated voice assistant. The user can choose to continue or drop off.
Next, the user would be redirected to the call center associate. Based on the query, the associate can choose to resolve it or progress the user to the next level.
The final stage; the user is redirected to the manager - who can take care of almost anything.

There's also a special case, if the customer is a high priority customer, the system skips the conversation with the associate and directly connects the customer to the manager.

Let's imagine how we would code this. 🤔 A naïve approach would be to have a single function that the user enters and then based on the user's status and interactions, different sub-functions (voice assistant, associate or manager) are called.

However, as our system grows and we want to add more features, this approach would make the function difficult to manage and the sub-functions difficult to reuse. More importantly, this approach violates the SOLID programming principle of separating concerns. 🤕

As an alternative, we could design our sub-functions in such a way that they would immediately call the next step in the chain as soon as their execution is over. In that way, the functionality for every step is maintained in a separate function but also it's easier to swap pieces out from the chain/insert more steps in the chain 🔁

Let's check out the implementation for this in go:

type step interface {
    run(*customer)
    setNextStep(step)
}

type customer struct {
    name string
    isHighPriority bool
}

type voiceAssistant struct {
    next step
}

func (v *voiceAssistant) run(cust *customer) {
    fmt.Println("[Voice Assistant] Serving the customer: ", cust.name)
    v.next.run(cust)
}

func (v *voiceAssistant) setNextStep(next step) {
    v.next = next
}

type associate struct {
    next step
}

func (a *associate) run(cust *customer) {
    if cust.isHighPriority {
        fmt.Println("Redirecting customer directly to manager")
        a.next.run(cust)
        return
    }
    fmt.Println("[Associate] Serving the customer: ", cust.name)
    a.next.run(cust)
}

func (a *associate) setNextStep(next step) {
    a.next = next
}

type manager struct {
    next step
}

func (a *manager) run(cust *customer) {
    fmt.Println("[Manager] Serving the customer: ", cust.name)
}

func (a *manager) setNextStep(next step) {
    a.next = next
}

At this point, each link of our chain is now created. We need to arrange them properly so that they follow the desired workflow: Voice Assistant -> Associate(optional) -> Manager. Let's do this in our main function for two different customers and see the result

func main() {
    m := &manager{}

    assoc := &associate{};
    assoc.setNextStep(m)

    va := &voiceAssistant{};
    va.setNextStep(assoc);

    // Chain formation complete

    // Start chain execution for normal customer
    normalCust := &customer{
        name: "Bob"
    }

    va.run(normalCust);

    fmt.Println("===================")

    // Start chain execution for high priority customer
    highPriorityCust := &customer{
        name: "John",
        isHighPriority: true,
    }

    va.run(highPriorityCust)
}

This should give you the following output:

[Voice Assistant] Serving the customer:  Bob
[Associate] Serving the customer:  Bob
[Manager] Serving the customer:  Bob
===================
[Voice Assistant] Serving the customer:  John
Redirecting customer directly to manager
[Manager] Serving the customer:  John

That's the Chain of Responsibility pattern for you! 😁

You can find all the code for this tutorial on this this github repo

Cheers ☕️

Design Patterns: Flyweight Pattern ⚖️

Shubham Zanwar — Sat, 31 Oct 2020 13:39:43 +0000

Photo by Johann Walter Bantz on Unsplash

The Flyweight design pattern is a structural design pattern commonly used when we want to group similar data for multiple objects. The primary intent of this pattern is to store common data for multiple objects in a single place and hence optimise for memory usage.

Let's understand this pattern by taking the case of a sneaker store 👟

Sneaker Store

Imagine running an online sneaker store. You've noticed that your customers always have a lot of questions and so, you've maintained every little detail about each pair of sneakers you have on display! 🗃

You have the following data points on every single pair:

Name
Size
Color
Brand
Price
Materials Used
Description
Sample Image
laced

You soon realized that for a given type of pair, you're storing the same information again and again. Take the case of the Nike Air Force 1. For any two pairs, the only thing different is the size and the color. Everything else is duplicate information 😱

This definitely isn't the best way to store the details because it's super memory intensive ad costly. To solve this problem, you decide to create an object to store all the common details of the shoe and store only the size, color and a reference to the "common object" with every shoe instance.

If all of this is confusing, don't worry. Taking a look at the code should make things easier 😉

type SneakerDetails struct {
    name        string
    brand       string
    price       float64
    materials   []string
    description string
    image       string
    laced       bool
}

var NikeAirForceDetails = SneakerDetails{
    name:        "Nike Air Force 1",
    brand:       "Nike",
    price:       144.99,
    materials:   []string{"leather", "rubber"},
    description: "Originally released in 1982, the Nike Air Force 1 was the first Nike model to feature Air technology.",
    image:       "https://via.placeholder.com/50",
    laced:       true,
}

var AdidasSuperstarDetails = SneakerDetails{
    name:        "Adidas Superstar",
    brand:       "Adidas",
    price:       85.99,
    materials:   []string{"leather", "rubber"},
    description: "Originally made for basketball courts in the '70s.",
    image:       "https://via.placeholder.com/50",
    laced:       true,
}

const (
    NikeAirForce = "Nike Air Force 1"
    AdidasSuperstar = "Adidas Superstar"
)

var DetailsMap = map[string]SneakerDetails{
    NikeAirForce:    NikeAirForceDetails,
    AdidasSuperstar: AdidasSuperstarDetails,
}

func getShoeDetails(shoeType string) SneakerDetails {
    return DetailsMap[shoeType]
}

type Sneaker struct {
    shoeType string
    size int
    color string
}

func (s *Sneaker) describe() string {
    details := getShoeDetails(s.shoeType)
    return fmt.Sprintf("The %s is of size %d, color %s and costs %.2f. The Manufacturer is %s", details.name, s.size, s.color, details.price, details.brand)
}

Looking through the code written so far, we've created the details object for each type of shoe in our shop using a common struct. This way, we can add descriptions for more sneakers in the future 🤔

We've also created a map of the shoe type against the respective type. This way, every instance of the Sneaker struct can easily access the corresponding details.

Also notice that our Sneaker struct now only contains the size, color along with the shoeType that allows us to fetch it's other details.

Let's see this in action

func main() {
    sneaker1 := Sneaker{
        shoeType: NikeAirForce,
        size:     9,
        color:    "white",
    }

    sneaker2 := Sneaker{
        shoeType: AdidasSuperstar,
        size:     8,
        color:    "black",
    }

    fmt.Println(sneaker1.describe())
    fmt.Println(sneaker2.describe())
}

This should give the following output:

The Nike Air Force 1 is of size 9, color white and costs 144.99. The Manufacturer is Nike
The Adidas Superstar is of size 8, color black and costs 85.99. The Manufacturer is Adidas

That's about it for the Flyweight pattern! 😁

Note that one added benefit of this pattern (apart from memory efficiency) is also the fact that updating the common details, like price, for a type of sneaker would require you to make the change in only one place - the common details object as opposed to making the change in every individual instance of the sneaker

You can find all the code for this tutorial on this this github repo

Cheers ☕️

Your daily developer workflow with GitHub CLI 👨🏻‍💻

Shubham Zanwar — Wed, 21 Oct 2020 12:10:49 +0000

Cover photo by Brina Blum on Unsplash

If you're a software developer, there is a pretty high chance that you have used GitHub to host your code repositories. I'm sure you'll agree that it's an amazing place to host and showcase your projects💜. I'm also sure that you'll agree that visiting the website to review pull requests, create an issue or release a, well, release is sometimes very frustrating - simply because it calls for so much context switching between your editor/terminal to your browser😖.

That's just not how things should work! 😤

Well, (thankfully) it seems like the unicorns at GitHub recognized this problem and have released the official GitHub CLI v1.0.0

In this blog post, I'll walk through my daily tasks as a developer and how I'm completely shifting my GitHub workflow to the cli🤩.

What do I use GitHub for?

Let's go over the tasks you and I would use GitHub for, while working on a project:

Create issues
Assign issues
Create a PR that closes an issue
Review/merge a PR someone else has assigned to you
Create a release for your package

Let's now bring all these tasks to our terminal so we don't have to log onto GitHub through the browser every time.

Let's move to the CLI 🚀

First things first, let's download the cli on our local machine. I'm using a macbook pro so I'll follow the instructions for it, but you can find the instructions for your OS here

# Install with Homebrew
brew install gh

Once the download is complete, it's time to log into your account from the cli🔑. There are two ways of doing this. Either using a browser login, or by using a personal access token. I'll be showing the browser login, but the process it fairly simple for the personal access token too.

Run the following in your terminal:

gh auth login

This will fire up an interactive program in your terminal that will ask you for your username and authenticate you using your browser

Follow the steps shown in the below recording

You're all set to start using the gh-cli now 😁

Let's create our first repo on GitHub in which we'll perform all the other tasks. To do this, navigate to any git repo on your machine, in my case it is the gh-cli-demo repo, and run the below command

Make sure you add atleast one commit on your master branch and push that to github

gh repo create

You will be greeted by a set of questions like below. Choose the appropriate responses and you'll be set. (You can verify the repo creation by navigating to the link mentioned at the end of the interaction)

We are ready to start working on our project now. Let's create an issue that we'll use to track our progress📝 (In this case, our "dummy" issue will be addressed to adding a readme.md file for documentation)

gh issue create --title "Add documentation!!" --body "create a read me file describing what this repo is about" --assignee shubhamzanwar

In this case, we've used the title, body and the assignee flags. For the whole set, you can check out this page from the cli documentation

Well, we've created the issue and it is assigned to us. Let's get cracking with it and create a readme file. We'll then raise a PR to merge our documentation into the master branch🚀. This part is probably already familiar to you. we use the good old git for this.

git checkout -b documentation
echo "Demo repo to learn github cli" > readme.md
git add readme.md
git commit -m "adding documentation"
git push origin documentation

At this point, our documentation changes are in the documentation branch. We ned to merge this with master. So let's create a PR that also references issue #1. Run the below command to create this PR from your terminal.

gh pr create

This will prompt you for the PR title and the body and you can mention whatever is apt.

If you want to use GitHub automation, you can type "closes #1" in the body of this PR. That way, github will automatically close the issue #1 when this PR gets merged😎

Since we have created a PR, let's also play the role of out teammate and review/merge this PR. To do this, we can checkout to the PR locally, go through the code and then decide if we want to merge this or not.

gh pr checkout 2

Review the code now (well, in this case, it's your own code😂). Since everything is good, let's go ahead and merge this PR.

In case you have comments/changes to request, you still have to use the browser. Hope github comes up with a cli solution for this too in later updates of gh🤞🏽

gh pr merge 2

This again, opens up a prompt asking whether we want to squash/merge/rebase. Feel free to choose this according to your preference.

Yay! you've successfully merged your code into the master branch both locally and on remote without leaving your terminal. Cool, right? 🤘🏽

As a final step, let's create a new master release for our repo. (This is usually used by libraries, but since we're trying everything out for our dummy repo, why not?😉)

gh release create v1.0.0

This will ask you a few set of questions about the title, release notes, etc. You can fill this up according to your release spec. In this case, I've left the release notes blank.

There you go!🎉 You've successfully learned how to create a repo, create issues, raise and merge PRs, close issues and create releases - all from your terminal, thanks to GitHub cli.

This tool (obviously) contains a lot more features and more flags/options for each feature. You can check out the documentation here

Hope you found this blog-post interesting. You can connect with me on twitter or github

Cheers ☕️

Design Patterns: Facade Pattern 🎭

Shubham Zanwar — Fri, 16 Oct 2020 15:25:06 +0000

Cover photo by Silvio Kundt on Unsplash

The facade pattern is a structural design pattern, commonly used when there is some interaction with a complex external library or service.

In this pattern, we create a class to encapsulate the interactions with the 3rd party library. This class is called the Facade. This allows us to expose a simpler interface to the rest of our application. Developers working on other parts of our system need not learn the 3rd party library; rather, they need to only interface with the facade class we create.

This serves a few crucial purposes:

In case the 3rd party system is super complex and requires multiple steps to perform a single action, we can encapsulate all of that in a single function in our facade.
We can easily switch out one 3rd party library for another and still maintain the same interface for our facade. This flexibility is one of the main selling points for the facade.
We can also filter out any extra functionality from the external service that we don't really require in our application. This is very common while using the facade pattern because external libraries can be very comprehensive and we may not require all the features offered.

Let's take an example of using the facade pattern

Amazon order system

Let's picture that you're building the module that deals with the placement of orders at Amazon. While building this, you have realized that there are several steps to placing an order; each step involving interactions with several other systems/modules.

Note: This probably is not how Amazon has implemented it's order system. This is just a simplistic representation of what it could be

Let's list out the steps:

Authenticate the user - Users service
Verify product's availability - Products service
Assign product to user - Products service
Make payment - Payments service
Send notification to dealer - Notification service

All of that on the click of a button 😱

Normally, if you were to directly integrate all the systems and services on the button's click, it would hamper the code's readability and would also make it a nightmare to switch one service for another (Imagine a case where you would revamp the products service)

To solve for all this, we can create a facade class that deals with all this and exposes a function called placeOrder that takes a productId and userId to complete all the above steps 👆🏽

Let's implement this solution in go

type orderFacade struct {
    userService UserService
    productService ProductService
    paymentService PaymentService
    notificationService NotificationService
}

func (o *orderFacade) placeOrder(userId string, productId string) {
    fmt.Println("[Facade] Starting order placement")

    userValid := o.userService.isUserValid(userId)
    productAvailable := o.productService.productAvailable(productId)

    if userValid && productAvailable {
        o.productService.assignProductToUser(productId, userId)
        o.paymentService.makePayment(userId, productId)
        o.notificationService.notifyDealer(productId)
    }
}

Let's also take a look at the other services' code

type UserService struct {}

func (u *UserService) isUserValid(userId string) bool {
    fmt.Println("[UserService] validating the user: ", userId);
    // Complex logic for checking validity
    return true
}

type ProductService struct {}

func (p *ProductService) productAvailable(productId string) bool {
    fmt.Println("[ProductService] checking availability of product: ", productId)
    // Complex logic for checking availability
    return true;
}

func (p *ProductService) assignProductToUser(productId string, userId string) {
    fmt.Printf("[ProductService] assigning product %s to user %s\n", productId, userId)
    // complex logic for product assignment
}

type PaymentService struct {}

func (p *PaymentService) makePayment(userId string, productId string) {
    fmt.Printf("[PaymentService] charging user %s for product %s\n", userId, productId)
    // complex logic for making payment
}

type NotificationService struct {}

func (n *NotificationService) notifyDealer(productId string) {
    fmt.Printf("[NotificationService] notifying dealer about sale of product %s\n", productId)
    // complex notification logic
}

Oooh, so now we have our dummy services and completely legit facade in place 💁🏻‍♂️ - It's time to test it out

func main() {
    orderModule := &orderFacade{
        userService:  UserService{},
        productService:  ProductService{},
        paymentService:  PaymentService{},
        notificationService:  NotificationService{},
    }

    userId := "test-user-id"
    productId := "test-product-id"


    orderModule.placeOrder(userId, productId)
}

When you run your program, you should see something like this in the output:

[Facade] Starting order placement
[UserService] validating the user:  test-user-id
[ProductService] checking availability of product:  test-product-id
[ProductService] assigning product test-product-id to user test-user-id
[PaymentService] charging user test-user-id for product test-product-id
[NotificationService] notifying dealer about sale of product test-product-id

You can notice from the code and the output that the facade only is the surface layer of the functionality. The actual action may happen in the external services and it is still abstracted away from the user of the facade by exposing a super simple interface.

That's the facade pattern in a gist 😁

You can find all the code for this tutorial on this this github repo

Cheers ☕️

Decorator Pattern 🎁

Shubham Zanwar — Tue, 06 Oct 2020 09:03:31 +0000

Cover photo by Silvio Kundt on Unsplash

The Decorator pattern is a structural design pattern that is used when we need to enhance the functionality of a given object without changing it's interface.

In this pattern, we usually have a base/bare-bones class that implements a certain interface. Along with this, we have multiple "wrapper" classes that allow users to enhance the methods of the base class without changing the interface.

This means that even the "Wrapper" classes implement the same interface

Let's consider an example to understand this better. We will discuss about a usecase that requires storing user information to a storage system and what happens when we need to encrypt some data before storing. 🗃

Storage system

Assume that you have a storage system for your websites audience that stores the users' data: email, in our case. Being a good developer, you had designed this module to be super generic and it is now being used by multiple teams in your organization. 😎

Everything sounds great? Here's the problem. You have a new requirement - Only your team needs to encrypt the users' data before storing it. 🤯

You obviously cannot modify the existing module. Too many teams are using it and they'll kill you if you do 🙃. You also cannot re-write everything from scratch. You don't have enough time for that and it also isn't the best way of solving this.

You remember a colleague telling you about the decorator pattern and you decide to put it into action 💡. Here's how it goes:

You have an interface, StorageSystem that contains two methods, writeInfo and readInfo.
The struct you had previously created by implementing StorageSystem is GenericStorageSystem - Assume that this just stores the information in memory.
To fulfill the requirement, you still need some struct to implement StorageSystem while also encrypting the data. Yes, I repeat, you can't just create a new struct from scratch. You need to use GenericStorageSystem.
You decide to create EncryptedStorageSystem. It wraps over the GenericStorageSystem and implements the writeInfo and readInfo which call writeInfo and readInfo of GenericStorageSystem respectively after encrypting/decrypting the data.

Voila! You've saved a bunch time and also have a scalable solution. Here, have a cookie for your efforts 🍪

Let's see how this looks in Go code:

type StorageSystem interface {
    writeInfo(info string)
    readInfo() string
}

type GenericStorageSystem struct {
    info string
}

func (g *GenericStorageSystem) writeInfo(info string) {
    // write information to file system as is.
    fmt.Println("Writing info to the file system: ", info)
    g.info = info
}

func (g *GenericStorageSystem) readInfo() string {
    // Return info from file system as is.
    fmt.Println("Reading info from the file system: ", g.info)
    return g.info
}

type EncryptedStorageSystem struct {
    storageSystem StorageSystem
}

func (e *EncryptedStorageSystem) writeInfo(info string) {
    fmt.Println("Encrypting the data")
    encryptedInfo := encrypt(info)
    e.storageSystem.writeInfo(encryptedInfo)
}

func (e *EncryptedStorageSystem) readInfo() string {
    info := e.storageSystem.readInfo()
    decryptedInfo := decrypt(info)
    fmt.Println("Decrypting info from the file system: ", decryptedInfo)
    return decryptedInfo
}

Let's also create dummy encrypt and decrypt functions. These just rotate the string in different directions

func encrypt (info string) string {
    return info[1:len(info)] + string(info[0])
}


func decrypt (info string) string {
    return string(info[len(info) - 1]) + info[0:len(info)-1]
}

Aaaand we're done 💃🏻. Let's check it out in action:

func main() {
    info := "kingslayer@gmail.com"
    genericStorage := GenericStorageSystem{}

    genericStorage.writeInfo(info)
    genericStorage.readInfo()

    fmt.Println("------------")

    encryptedStorage = EncryptedStorage{
        storageSystem: genericStorage,
    }

    encryptedStorage.writeInfo(info)
    encryptedStorage.readInfo()
}

You should see this in the output:

Writing info to the file system:  kingslayer@gmail.com
Reading info from the file system:  kingslayer@gmail.com
------------
Encrypting the data
Writing info to the file system:  ingslayer@gmail.comk
Reading info from the file system:  ingslayer@gmail.comk
Decrypting info from the file system:  kingslayer@gmail.com

Notice how the end result in both the cases are similar. You wrote a string, and got back the same string when you requested it. However, in the second case, the data was encrypted while storing and decrypted while reading - The most important part is that all of this is abstracted from the user.

There you have it - The decorator pattern 🎉

Now that you have a good understanding of the decorator pattern, let's discuss why it's a good thing:

Notice how you did not have to create a new storage from scratch. This saved a bunch of time and also didn't change the API for your storage system. Hence, no unhappy users.
Also notice that the EncryptedStorageSystem implements the StorageSystem interface and wraps around any StorageSystem; not just GenericStorageSystem. This is pretty powerful because you will be able to create multiple recursive wrappers. You can now, even compress your data after encrypting, if you're into that 💪🏽😁

Note: The Decorator pattern is different from the Adapter pattern because the adapter pattern converts one struct into another. Hence, there is a change in API. The decorator pattern, on the other hand, simply wraps around the existing struct without changing the API.

You can find all the code for this tutorial on this this github repo

Cheers ☕️

What's with the customer care numbers?

Shubham Zanwar — Mon, 05 Oct 2020 04:16:47 +0000

Does anyone around know why there are a bunch of people spamming customer care numbers as blog posts?
My feed is filled with them

I've started using dev.to actively only recently so please educate me if this is a thing

Electron alternative: Announcing vue-nodegui 🚀💚

Shubham Zanwar — Sat, 03 Oct 2020 12:39:44 +0000

In this blog post, we shall take a look at vue-nodegui, a newly-released JS library to create cross-platform native desktop applications using VueJS 💚

repo link: https://github.com/nodegui/vue-nodegui
documentation site: https://vue.nodegui.org

Why not electron?

Before we dive into vue-nodegui, let us discuss the most popular alternative out there: Electron ⚛️

Electron has been the most popular library for creating desktop applications using JS for a while now. While it is an amazing solution, it has some severe pain points by design:

Electron apps tend to be bloated because every Electron app ships a version of the Chromium browser in which it runs. Hence, it's not truly native.
Electron apps also suffer from excess CPU/memory utilization issues.

What's vue-nodegui? 💚

vue-nodegui is a custom vue3 renderer for nodegui, a native JS bindings library for Qt5. Below is an excerpt from the nodegui announcement last year:

"NodeGUI is powered by Qt5 💚 which makes it CPU and memory efficient as compared to other chromium based solutions like electron. NodeGui wants to incorporate everything that is good about Electron: The ease of development, freedom of styling, Native APIs, great documentation, etc. At the same time NodeGui aims to be memory and CPU efficient."

vue-nodegui allows developers to use the familiar Vue API to create their native desktop app - something that react-native does for react. Since vue-nodegui is ultimately powered by Qt5, it means that vue-nodegui does not require a browser environment to render in. Instead, the widgets in the app are truly native.

Features 💎

Access to new Vue3 features (setup, composition api, etc)
🧬 Cross platform. Should work on major Linux flavours, Windows and MacOS
📉 Low CPU and memory footprint. Current CPU stays at 0% on idle and memory usage is under 20mb for a hello world program.
💅 Styling with CSS (includes actual cascading). Also has full support for Flexbox layout (thanks to nodegui and Yoga).
✅ Support for all node_modules (compatible with Node v12 and above)
🎪 Native widget event listener support. supports all event available from Qt / NodeJs.
💸 Can be used for Commercial applications.
📚 Good documentation and website.
🧙‍♂️ Good documentation for contributors.
🦹🏻‍♀️ Good support for dark mode (Thanks to QT).

Requirements 📝

Below are the general requirements for systems to create vue-nodegui apps:

Only supported on 64bit OS.
CMake 3.1 and up (Installation instructions can be found here: https://cmake.org/install/)
Make, GCC v7
NodeJS v12.x and above

You can find the detailed installation steps for each of the requirements and troubleshooting guide on the Getting started page.

Let's try it out 🤩

To get started, let's first clone the starter repo:

git clone https://github.com/nodegui/vue-nodegui-starter hello-world
cd hello-world
npm install
npm run dev

Let's create a basic hello-world project with a counter

Clear out the contents of App.vue and write the below code in it

<template>
  <vn-view :styleSheet="styles">
    <vn-text id="header">Hello world</vn-text>
    <vn-view id="row">
      <vn-button @clicked="decrement">-</vn-button>
      <vn-text id="count">{{count}}</vn-text>
      <vn-button @clicked="increment">+</vn-button>
    </vn-view>
  </vn-view>
</template>

<script>
import { ref } from 'vue';

export default {
  setup() {
    const count = ref(0);
    const increment = () => {
      count.value += 1;
    }

    const decrement = () => {
      count.value -= 1;
    }

    const styles = `
      #header {
        padding: 10px;
        background: #36495e;
        width: 200px;
        color: #fff;
        qproperty-alignment: AlignCenter;
      }
      #row {
        width: '100%';
        flex-direction: 'row';
        justify-content: 'center';
      }
      #count {
        padding: 5px;
        qproperty-alignment: AlignCenter;
      }
    `

    return {
      count,
      decrement,
      increment,
      styles
    }
  }
};
</script>

After running npm run dev to fire up the app in your terminal, the output should look like the screenshot below

As you can see, we have created a basic counter application by using the very familiar Vue API. 🚀🤘🏽

However you may have notices new tags: <vn-view>, <vn-button>, <vn-text> These are what we call native-tags in vue-nodegui. To create any vue-nodegui application, you will have to use these. You can check out the entire catalog of widgets here

Contributions and Support ☃️

If you went through the vue-nodegui repo, you would have realized that even though it is an awesome project, it is still in it's infancy. Some more work on creating widgets and an ecosystem around it would be required before we can use it in production apps. This is where you all come in! 🚪

We wholeheartedly welcome any kind of contributions for vue-nodegui - code, documentation, sister libraries (animation, testing, components) in the form of pull-requests. We have also opted into the #Hacktoberfect to encourage these contributions! 🥳

If you liked the project, please show your support by starring ⭐️⭐️ the repo

If you are able to support financially, kindly feel free to sponsor 💵💵 this project

Super excited to build something magnificent together! ♥️

Cheers ☕️

Bridge Pattern 🌉

Shubham Zanwar — Thu, 01 Oct 2020 11:17:58 +0000

The bridge is a structural design pattern that helps in splitting up a complex piece of code into multiple parts so that each part can be developed, scaled and maintained independently.

You will commonly see this employed when you have classes in your code that have multiple tangential functionalities. In such a case, it is better practice to split the functionalities up into smaller classes and build a mechanism (a bridge, maybe?) to connect them

Let us take a look at an example to understand better

This tutorial uses go. You can find the implementation here. However, if you read through it, I'm confident that you will be able to implement it in any programming language 🤗

Employee Management system

Assume that your workplace needs an employee management system. As part of this requirement, you need to categorize your workforce by gender and their function/department.

Currently, you have the following genders and department:

Genders

Male
Female

Department

Developer
Product manager (PM)
Human Resources (HR)

A naive way of approaching this problem would be to implement multiple structs, like, MaleDeveloper, FemaleDeveloper, MalePM, FemalePM, and so on. This is fine if we have already defined a set of genders and departments. However, that's never realistically the case.

We can always grow departments to include more functions and we can always onboard employees who identify as non-binary (let's not be ignorant 🏳️‍🌈). The problem that would arise then is that, for every new gender we onboard, we would have to create 3 new structs - one for each combination of the new gender and existing departments.

This number would only increase as our organization grows and it's going to be a nightmare to maintain these structs 😨

Note: Go does not have classes. Structs are a way of implementing classes in golang. If you're working with another programming language, think classes every time I say structs

Enter, the Bridge pattern. According to the Bridge pattern, we should separate the different dimensions of a struct into separate sub structs. In this case, we would have separate structs for each gender and separate structs for each department.

Let's take a look at this:

type Gender interface {
    describePerson() string
}

type Department interface {
    getDepartmentName() string
}

Now that we have the two interfaces defined, we can expect any future departments/genders to implement them. Currently, though, let's implement the existing struct we know using these interfaces:

// male.go

type Male struct {
    name string
    age int
    department Department
}

func (m *Male) describePerson() string {
    description := fmt.Sprintf("%s is a %d years old man\n", m.name, m.age)
    description  = description + fmt.Sprintf("He works in the %s department", m.department.getDepartmentName())
    return description
}

// female.go

type Female struct {
    name string
    age int
    department Department
}

func (f *Female) describePerson() string {
    description := fmt.Sprintf("%s is a %d years old woman\n", f.name, f.age)
    description  = description + fmt.Sprintf("She works in the %s department", f.department.getDepartmentName())
    return description
}

// departments.go

type Developer struct { }
type PM struct { }
type HR struct { }

func(d Developer) getDepartmentName() string {
    return "software development"
}

func (pm PM) getDepartmentName() string {
    return "product management"
}

func (hr HR) getDepartmentName() string {
    return "human resources"
}

As you can see, we have successfully separated the functionalities by gender and department. Notice however, that we have a department key in both the gender structs. This key is, in fact, the bridge between the two dimensions, gender and department.

Now, every time we need to create a new gender or department, we only have to create one additional class and the bridge takes care of the rest.

Time to test our code out 🧪

//main.go

func main() {
    maleDeveloper := Male{
        name: "John",
        age: "22",
        department: Developer{},
    }

    fmt.Println(maleDeveloper.describePerson())
    fmt.Println("-------------")

    femalePM := Female{
        name: "Natalie",
        age: "24",
        department: PM{},
    }

    fmt.Println(femalePM.describePerson())
}

The output of this program should look like this

John is a 22 years old man
He works in the software development department
-------------
Natalie is a 24 years old woman
She works in the product management department

That's the bridge pattern for you 😉

You can find all the code for this tutorial on this github repo

Cheers ☕️

Adapter Pattern 🔌

Shubham Zanwar — Thu, 01 Oct 2020 11:17:46 +0000

The Adapter pattern is a structural design pattern. It allows 2 or more incompatible objects to interface with each other.

The first thing that comes to mind it probably the adapters for wall-sockets that allow your Indian phone charger to fit into European wall sockets! 😂 That's exactly what adapters are. They are wrapper classes written around non-uniform classes so that the end result exposes a uniform API.

In case this is difficult to grasp, the following example should help:

This tutorial uses go. You can find the implementation here. However, if you read through it, I'm confident that you will be able to implement it in any programming language 🤗

Translator example

Consider that you're a regular english speaking person who has just migrated to Spain. 🇪🇸
Your neighbour is a pleasant looking person and you'd like to be friends with this individual. However, there's one problem. 😨

Every one in your neighbourhood speaks Español exclusively. Oh, also, you don't speak Spanish 😞

In order to communicate with your potential friend, you would need some sort of translator to help convert your speech from English to Spanish. In programming terms, this translator is what we call an adapter!

Let's understand at how this would look in code.

As a first step, let's create the interface that a normal Spanish-speaking person would implement along with the structs for both, the Spanish and the English speaking person.

type SpeakSpanish interface {
    greetInSpanish() string
}

// Notice that the SpanishSpeaker already implements the
// SpeakSpanish interface
type SpanishSpeaker struct {}

func (s *SpanishSpeaker) greetInSpanish() string {
    return "¡Hola!"
}

type EnglishSpeaker struct {}

func (e *EnglishSpeaker) greetInEnglish() string {
    return "Hello there!"
}

As you can see, the SpanishSpeaker already implements the SpeakSpanish interface. However, the EnglishSpeaker does not have a greetInSpanish function and hence, doesn't implement the SpeakSpanish interface.

Let's use the adapter pattern to write a wrapper over the EnglishSpeaker that would give it the ability to greet in spanish.

type EnglishToSpanishAdapter {
    speaker EnglishSpeaker
}

func (a *EnglishToSpanishAdapter) greetInSpanish() string {
    const englishMessage = a.speaker.greetInEnglish();
    return translate(englishMessage)
}

func translate(engMessage string) spanishMessage string {
    // *insert complex translation logic*
    spanishMessage = "¡Hola!"
    return
}

Closely observing the adapter will show you that since it is a struct and has the greetInSpanish method, it implements the SpeakSpanish interface. This is good because once we wrap our english speaker in this adapter, we essentially get a Spanish speaker.

Also notice that we have a translation function as a util along with the adapter. Normally, you would use some service, like google translate, to translate the messages

Now, our Adapter module is complete. Amazing! 🔥🤘🏽

Let's test it out and see it in action.

func main() {
    espanol := SpanishSpeaker{}
    englishwoman := EnglishSpeaker{}

    fmt.Println("Without translation:")
    fmt.Println("Español says: ", espanol.greetInSpanish())
    fmt.Println("English Woman says: ", englishwoman.greetInEnglish())

    adaptedEnglishwoman := EnglishToSpanishAdapter{
        speaker: englishwoman,
    }

    fmt.Println("------------")
    fmt.Println("With translation:")
    fmt.Println("Español says: ", espanol.greetInSpanish())
    fmt.Println("English Woman says: ", adaptedEnglishwoman.greetInSpanish())
}

As a result of this, you should see something like this in the terminal:

Without translation:
Español says:  ¡Hola!
English Woman says:  Hello there
------------
With translation:
Español says:  ¡Hola!
English Woman says:  ¡Hola!

Hurray! The translation worked; the english woman and Spanish dude can now be friends! 👩🏻‍🤝‍👨🏾

Design patterns save the day, yet again 🚀😁

You can find all the code for this tutorial on this github repo

Cheers ☕️

Builder Pattern 👷🏽‍♂️

Shubham Zanwar — Thu, 01 Oct 2020 11:17:08 +0000

The builder pattern is a creational design pattern. It is used when the creation of a product involves multiple, independent steps.

What's the one thing that immediately comes to your mind when you think of something that requires multiple steps to be "built"? That's right, subway!! 🥙🤤
You choose your bread, you choose if you want cheese, you choose your toppings and finally your sauces!

I'm sure you understand the process of creating a sub. Let's see what it would look like if we coded it using the Builder pattern:

Subway Example

Let us assume that we have 2 different types(recipes) for a sub - Veggie Delight and Chicken Teriyaki. Each of these would have a "Builder" dedicated to them.

The interface that these builders implement will be the same - That way, we can easily add more types(recipes) to our menu.

type sub struct {
    bread string
    hasCheese bool
    toppings []string
    sauces []string
}

type iSubBuilder interface {
    setBread()
    setCheese()
    setToppings()
    setSauces()
    getSub() sub
}

type veggieDelightBuilder struct {
    sub
}

func (v *veggieDelightBuilder) setBread() {
    v.sub.bread = "parmesan oregano"
}

func (v *veggieDelightBuilder) setCheese() {
    v.sub.hasCheese = false
}

func (v *veggieDelightBuilder) setToppings() {
    v.sub.toppings = []string{"olives", "tomatoes", "onions", "jalapeños"}
}

func (v *veggieDelightBuilder) setSauces() {
    v.sub.sauces = []string{"south west"}
}

func (v *veggieDelightBuilder) getSub() sub {
    return v.sub
}

type chickenTeriyakiBuilder struct {
    sub
}

func (c *chickenTeriyakiBuilder) setBread() {
    c.sub.bread = "italian"
}

func (c *chickenTeriyakiBuilder) setCheese() {
    c.sub.hasCheese = true
}

func (c *chickenTeriyakiBuilder) setToppings() {
    c.sub.toppings = []string{"roasted chicken", "olives", "onions", "jalapeños"}
}

func (c *chickenTeriyakiBuilder) setSauces() {
    c.sub.sauces = []string{"chilli", "bbq"}
}

func (c *chickenTeriyakiBuilder) getSub() sub {
    return c.sub
}

We've successfully created the sub and the builders. As you may have observed, we can easily create another recipe and have it implement all the functions.

Now, let's create an optional director struct that would accept accept a builder and then build subs for us.

The director is not always part of the builder pattern. You could look at it as an added layer of abstraction for cleaner code

type director struct {
    builder iSubBuilder
}

func (d *director) setBuilder(builder iSubBuilder) {
    d.builder = builder
}

func (d *director) buildSub() sub {
    d.builder.setBread()
    d.builder.setCheese()
    d.builder.setToppings()
    d.builder.setSauces()

    return d.builder.getSub()
}

Aaand we're done 🎉

Let's see it in action:

func describeSub(sub sub) {
    fmt.Printf("bread: %s, cheese: %t, toppings: %s, sauces: %s\n", sub.bread, sub.hasCheese, strings.Join(sub.toppings, ", "), strings.Join(sub.sauces, ", "))
}

func main() {
    veggieDelight := &veggieDelightBuilder{}
    director := &director {
        builder: veggieDelight,
    }
    veggieDelightSub := director.buildSub()
    describeSub(veggieDelightSub)

    fmt.Println("------------")

    director.setBuilder(&chickenTeriyakiBuilder{})
    chickenTeriyakiSub := director.buildSub()

    describeSub(chickenTeriyakiSub)
}

Running this program should get you this in your terminal

bread: parmesan oregano, cheese: false, toppings: olives, tomatoes, onions, jalapeños, sauces: south west
------------
bread: italian, cheese: true, toppings: roasted chicken, olives, onions, jalapeños, sauces: chilli, bbq

You can find all the code for this tutorial on this github repo

Hope this made understanding the Builder pattern easier 🚀

Cheers ☕️

Abstract Factory Pattern 🏭

Shubham Zanwar — Thu, 01 Oct 2020 11:16:52 +0000

Abstract Factory pattern is a creational design pattern. It is used when we need to create multiple families of similar products.

Let us understand this pattern using the example of a pizza chain

Pizza Shops

Assume that you are the head of a business that opens up pizza stores around town. One of your many responsibilities is to maintain all food items (in this case, pizzas and garlic bread) in a given store to belong to the same brand - either dominos or pizza hut.

There are multiple ways you could go about it. One of the simplest that comes to mind is to create a factory for creating pizzas of either pizza hut or dominos type and another similar factory for garlic bread.

Note: If you're not sure about how normal factories work, you can take a look at this example

The drawback of having separate factories is that now we trust the user, at a given store, to choose the correct type of pizza, garlic bread they want. If they ever make the mistake of serving a dominos pizza with a pizza hut garlic bread, your customers are going to be mad and you'd also be violating your make-believe contract with each of these chains.

Don't worry. There's a simpler way

Instead of creating a factory over each individual product (pizzas and garlic bread), you could create a factory for each individual brand. Enforce both these factories to have provision for creating a pizza and creating a garlic bread.

Then, while setting up the store, you could give the store manager either a pizza hut factory or a dominos factory and then confidently rest that they won't be accidentally mixing-and-matching products.

Let's translate this to code:

Before we begin writing the factories, let's first create the products:

Generic Pizza

type iPizza interface {
    GetPrice() float64
    GetName() string
    GetToppings() []string
}

type pizza struct {
    name     string
    price    float64
    toppings []string
}

func (p *pizza) GetName() string {
    return p.name
}

func (p *pizza) GetPrice() float64 {
    return p.price
}

func (p *pizza) GetToppings() []string {
    return p.toppings
}

Branded Pizzas

type pizzaHutPizza struct {
    pizza
}

type dominosPizza struct {
    pizza
}

Generic Garlic Bread

type iGarlicBread interface {
    GetPrice() float64
    GetName() string
}

type garlicBread struct {
    name  string
    price float64
}

func (g *garlicBread) GetName() string {
    return g.name
}

func (g *garlicBread) GetPrice() float64 {
    return g.price
}

Branded Garlic Bread

type pizzaHutGarlicBread struct {
    garlicBread
}

type dominosGarlicBread struct {
    garlicBread
}

We have created both our products. They both implement a common interface, making it easier for the end user to consume them. Pun intended 😉

Let's now look at how we can create the factories for each of these:

Generic Factory

type iPizzaFactory interface {
    createPizza() iPizza
    createGarlicBread() iGarlicBread
}

Now, both, PizzaHutFactory and DominosFactory can implement this interface to ensure that they expose uniform functionality

Branded Factories

type PizzaHutFactory struct {}

func (p *PizzaHutFactory) createPizza(): iPizza {
    return &pizzaHutPizza{
        pizza{
            name:     "pepperoni",
            price:    230.3,
            toppings: []string{"olives", "mozzarella", "pork"},
        },
    }
}

func (p *pizzaHutFactory) createGarlicBread() iGarlicBread {
    return &pizzaHutGarlicBread{
        garlicBread{
            name:  "garlic bread",
            price: 180.99,
        },
    }
}

type dominosFactory struct{}

func (d *dominosFactory) createPizza() iPizza {
    return &dominosPizza{
        pizza{
            name:     "margherita",
            price:    200.5,
            toppings: []string{"tomatoes", "basil", "olive oil"},
        },
    }
}

func (d *dominosFactory) createGarlicBread() iGarlicBread {
    return &dominosGarlicBread{
        garlicBread{
            name:  "cheesy bread sticks",
            price: 150.00,
        },
    }
}

We can now choose between either of the factories and then continue creating either pizzas or garlic bread and be absolutely sure that any product from a factory will always belong to the same family/brand of products.

We're almost there. Let's wrap this up by creating a factory that will return the factory of our choice. Confusing? 🤯 Give it a minute and read that sentence again 😋

Basically, think of our factories as just another object. Now, based on what type or pizza store we want to set up, (pizza hut or dominos), we can make request for that particular factory (just another object). To automatically get these "objects", we can create another factory that would return one of these.

Some code to help you out:

Factory of factories

func getPizzaFactory(chain string) (iPizzaFactory, error) {
    if chain == "P" {
        return &pizzaHutFactory{}, nil
    }
    if chain == "D" {
        return &dominosFactory{}, nil
    }
    return nil, fmt.Errorf("Enter a valid chain type next time")
}

Maybe this makes more sense 💡😁

The main point to remember is this: The abstract factory pattern implements a factory of factories. These inner factories can be used to create products that belong to a particular kind.

You can find all the code for this tutorial on this github repo

Cheers ☕️

Factory Pattern 🏭

Shubham Zanwar — Thu, 01 Oct 2020 11:16:35 +0000

Factory pattern is a commonly used creational design pattern. It is normally used when the user is expected to choose between multiple options.

Let's take an example to understand.

Pet store

Let's take a scenario of how this would work in a pet store. To understand this completely, we'll look at the implementation from both, the view of the shop-owner(developer creating the factory) and the customer (user using the interface)

Owner's perspective

Assume that you're the owner of a dog store (you only put little doggos up for adoption). Since you're in the software world, every dog is an instance of a Dog class that you have. Now, when a customer arrives, you simply create a new instance of Dog and let them adopt that.🐶

Lately, however, the customers have started requesting for variety. They're looking for options to adopt cats too.😼

Being a clever shop-owner, you've identified that this demand can only keep getting more varied. People will continue expecting more variety.😨😤

You need a robust, scalable system to generate new pets for customers
Enter, the factory pattern

You make a list of all the common traits (features) of your pets. They allow you to get the name, get the sound they make and get their age. This list allows you to create an interface with the following functions:

type Pet interface {
    GetName() string
    GetAge() int
    GetSound() string
}

Now, you can create any number of pets that have the same features (implement the same interface). You could have cats, dogs, fish, parrots, anything - as long as the implement the Pet interface!😯 As of now, let's create the Dog and the Cat:

// pet is a struct that implements Pet interface and
// would be used in any animal struct that we create.
// See `Dog` and `Cat` below
type pet struct {
    name  string
    age   int
    sound string
}

func (p *pet) GetName() string {
    return p.name
}

func (p *pet) GetSound() string {
    return p.sound
}

func (p *pet) GetAge() int {
    return p.age
}

type Dog struct {
    pet
}

type Cat struct {
    pet
}

An additional thing you would require is a factory that would return a different pet (dog/cat) based on the user's request. Simply put, if the user asks for a dog, give them a cute doggo, duh.🙄🦮

func GetPet(petType string) Pet {
    if petType == "dog" {
        return &Dog{
            pet{
                name:  "Chester",
                age:   2,
                sound: "bark",
            },
        }
    }
    if petType === "cat" {
        return &Cat{
            pet{
                name:  "Mr. Buttons",
                age:   3,
                sound: "meow",
            },
        }
    }
}

Notice how the GetPet function only tells that it returns a Pet - Not a Dog or a Cat explicitly. Hence, this function is open to extension (by writing more structs that implement the Pet interface). Adding more Pet types will not affect the existing users who just want Dogs anyway.

Congratulations! you've created a Pet shop using the factory pattern🎉❤️

Customer's perspective

Let's look at it from the perspective of the user. All they would need to do is call the GetPet function with whatever config (in this case, type) they want. In return, all they know is that they are getting a Pet.🤔 This may sound bizarre in the real world sense of things, but when it comes to code, it's better to maintain abstraction.😌

The users can freely go about "using" the Pet as they like. This "usage" would remain the same irrespective of what type of pet they got back (because all pets implement the common interface!!)

Let's test it out

func describePet(pet Pet) string {
    return fmt.Sprintf("%s is %d years old. It's sound is %s", pet.GetName(), pet.GetAge(), pet.GetSound())
}

func main() {
    petType := "dog"

    dog := GetPet(petType)
    petDescription := describePet(dog)

    fmt.Println(petDescription)
    fmt.Println("-------------")

    petType = "cat"
    cat := GetPet(petType)
    petDescription = describePet(cat)

    fmt.Println(petDescription)
}

The output should look like:

Chester is 2 years old. It's sound is bark
-------------
Mr. Buttons is 3 years old. It's sound is meow

You can find all the code for this tutorial on this github repo

Hope this made understanding the factory pattern easier 🚀

Cheers ☕️