From healthcare to finance, robust software systems power our daily operations, making good software design essential to avoid inefficiencies and bottlenecks. This involves not just writing code but also designing systems that are easy to scale, maintain, and debug, while allowing others to contribute effectively.

Inefficient or ineffective software design can lead to significant issues, like scope creep, miscommunication within teams, project delays, resource misallocation, and complex systems that are difficult to maintain or understand. Without a strong design, teams often accumulate technical debt, which hinders long-term progress and increases maintenance costs.

This article will introduce you to key software design elements that will help you and your team address these challenges and guide you in building efficient, scalable systems. By understanding and applying these elements correctly, you can set up a project for both short-term and long-term success.

Prerequisites

I’ll explain these concepts through examples, but a basic understanding of programming in any language is required for this article (knowledge of Python will be especially beneficial).

Scope

The article will introduce key software design elements and explain them using an example. While I won’t provide a full software design for the example problem, I will include enough details to effectively illustrate each design element.

Table of Contents

• Overview of Key Software Design Elements

• A Walkthrough of the Software Design Process

  • Problem Statement

  • Use Cases

  • Requirements

  • High Level System Architecture

  • Detailed Software Design and Component Breakdown

• Conclusion: The Value of Thoughtful Software Design

Overview of Key Software Design Elements

To fully understand the benefits of the software design process, you’ll need to understand some key elements and their scope.

Once you have a good grasp of these, the next step is to define them for the specific problem at hand. Accurately defining these elements reduces risks and simplifies the implementation phase.

Doing this groundwork before implementation helps prevent late discoveries, minimizes the need for rewriting, and makes sure that the design can handle constraints and corner cases.

Now let’s briefly go over the key elements of the software design process:

1. Creating a problem statement: This step involves creating a clear and concise description of the problem that needs to be solved, along with its scope. The scope is essential because it focuses on the exact problem to be addressed and includes assumptions that must be considered during design.

2. Identifying use cases: This step outlines all possible user interactions with the software to achieve the desired outcome. It is a critical input to the architecture, as it helps create a design that addresses both general and edge-case use cases.

3. Stating requirements: This step defines the expectations of the software, such as its limitations, behaviors, and capabilities for different use cases.

4. Designing the architecture: This step provides a high-level structure of the software design, focusing on how to meet the requirements. The architecture typically includes components, how they interact, and how data flows through the system.

5. Drafting a detailed design: This step refines the high-level architecture into detailed, component-specific designs, ready for implementation.

In addition to these core elements, there are two important factors you need to consider throughout the design phase.

First, you’ll need to identify and state any assumptions you have. Assumptions can be present at any stage in the design process. Making correct assumptions increases the likelihood of success, improves focus, and reduces complexity in the design.

Second, you’ll need to create good documentation. Documentation is one of the most important elements in the software design process. It’s essential to document each stage as you go along. Documentation serves as the only formal record of the software design and is invaluable for presentations to management, for onboarding new team members, and for anyone returning to the project after a break. It saves valuable time and ensures continuity, as we often overestimate our own memory.

The figure below provides a visual summary of the key software design elements discussed in this section.

Next, we’ll apply these key software design elements to a practical example, demonstrating how each element contributes to building a robust and scalable system.

A Walkthrough of the Software Design Process

In any well-structured software project, clearly defining the problem is the first crucial step before diving into design and implementation. A well-defined problem ensures that the software meets user needs, remains maintainable, and scales effectively over time.

For this walkthrough, we will focus on designing a financial expense categorization system that processes and analyzes transaction data. This system is a part of a larger financial management solution and needs to be easy to debug, maintain, and scale.

Problem Statement

The problem statement provides a high-level goal for the software that we’ll design.

For this example, here’s our statement: Design a software solution that categorizes monthly expenses and generates a report from a list of transactions.

Define the scope

Defining the scope clarifies the smaller tasks that must be accomplished to meet the high-level goal. It outlines the focus of the software design and includes some assumptions.

Includes:

1. Implementing a parser to process a list of transactions provided as input.

2. Filtering transactions for a given month.

3. Analyzing, categorizing, and generating a report for each expense category.

Excludes:

Performance and memory optimization (excluded due to the limited scope of this article). While performance and memory optimizations are not the primary focus here, it’s important to keep future scalability in mind. Small design choices made now, such as selecting data structures, can help avoid significant refactoring later when the system grows.

Assumptions:

1. The list of transactions will be provided as a CSV file in the following format:
   Columns: "Date, Description, Amount, Type, Category Label".

2. Expense categories will be provided as input through a JSON file.

3. The software will run in a shell environment, and inputs will be taken as command-line arguments.

Now that the scope is clear, let’s examine how users will interact with the system through various use cases.

Use Cases

Use cases define how users will interact with the system to accomplish specific goals. Identifying accurate and valid use cases is critical to creating comprehensive requirements. Failing to capture enough use cases can lead to a design that is incomplete and lacks robustness. This may result in the need for redesigns, which increases time and resource consumption.

On the other hand, identifying too many use cases without considering their feasibility can lead to overly complex designs that are difficult to maintain and implement in the short term.

For our specific problem, the user will need to provide the following inputs while running the software in a shell:

1. A CSV file containing a list of transactions.

2. A month number.

3. A JSON file containing expense categories.

We need to consider all possible ways the user can interact with the script to achieve the desired outcome. For each of the three inputs, there are two possibilities: valid input or invalid input. This gives us 8 potential use cases (2 possibilities per input: valid and invalid). It's important to define what constitutes valid and invalid inputs for this problem:

• CSV File: Valid if it is in the format described in Assumption 1 (columns: "Date, Description, Amount, Type, Category Label").

• Month Number: Valid if the value is between 1 and 12.

• JSON File: Valid if it contains expense categories in the correct JSON format.

An input is invalid if it doesn't meet these definitions or if the input is absent.

It’s also crucial to consider the correlation between inputs when evaluating the feasibility of certain use cases, as they may interact with each other in unforeseen ways. Based on these use cases, we can now define the specific requirements that the system must meet.

Requirements

Now, let’s define the expected behaviors, limitations, and capabilities for each use case. Requirements serve as the foundation for architecture, specifications, and implementation. Based on our problem statement, the software will need to accomplish the following tasks:

1. The script shall take three inputs: a CSV file of transactions, a month number, and a JSON file of expense categories.

2. The script shall verify all inputs.

3. The script shall throw an error and exit if the CSV file cannot be opened or if it does not match the format in Assumption 1.

4. The script shall throw an error and exit if the JSON file cannot be opened.

5. The script shall throw an error if the month number is not between 1 and 12.

6. The script shall parse each transaction and load it into a data structure.

7. The script shall filter transactions by the specified month.

8. The script shall load the expense categories from the JSON file into a data structure.

9. The script shall categorize transactions based on the category label provided in the CSV file.

10. The script shall throw an exception if a category label in the CSV file is not present in the expense categories.

11. The script shall use a categorizing function to assign transactions to categories from the JSON file.

12. A class shall encapsulate categorized transactions, providing APIs to modify or access them.

13. The script shall support statistics calculation and report generation for categorized transactions.

With the requirements in place, we can now design a high-level architecture to meet those needs.

High Level System Architecture

In this stage, we will design the system at a high level, much like creating a master plan. Architecture involves organizing the software's functions into distinct components, illustrating how they interact, and mapping the flow of control and data through the system. While designing the architecture in this tutorial, we’ll incorporate good design principles.

For this example, the high-level requirements include:

1. Loading inputs and verifying them.

2. Applying time-based filtering.

3. Categorizing transactions based on category labels and descriptions.

4. Managing categorized transactions in a finance registry.

5. Generating reports from the categorized data.

One important component of software architecture is telemetry. Telemetry gathers data on the software's behavior, which is invaluable for debugging and performance assessment in real-world environments.

For smaller systems, simpler logging mechanisms may be sufficient to track basic errors and monitor performance. The decision to implement telemetry should depend on the complexity of the system and operational requirements.

Since telemetry provides such a helpful feedback loop for improving the design in future iterations, we’ll add it to the list of components here.

We’ll build our system architecture around a Test-Driven Development (TDD) approach. We’ll design each component with testing in mind to ensure it meets our requirements.

Just keep in mind that while TDD is a strong practice for ensuring code quality, it may not be the best fit for all projects. In scenarios where you need rapid prototyping or exploratory development, testing might be prioritized after initial iterations. Balancing between TDD and other methodologies depends on the project context and team preferences.

Our architecture will follow a modular structure, meaning the system will be divided into self-contained components. Each component will be responsible for specific functionality, making the system easier to test, maintain, and scale.

To achieve this, the architecture will emphasize loose coupling between components. Each component will interact with others through well-defined interfaces or APIs, ensuring minimal dependencies. We’ll abstract and encapsulate internal implementation details, exposing only the necessary information for interaction. Also, each component will handle its own errors and exceptions to ensure robustness and fault isolation.

But it is also important to consider a centralized error-handling strategy in some cases. Centralizing error handling can reduce redundancy, improve consistency, and make maintenance easier. The choice between local and centralized error handling should depend on the system's complexity and how components interact. This will contribute to the overall scalability and maintainability of the system.

Below is a summary of each component's functionality in this architecture:

• Load and verify input: This component will take the CSV file, JSON file, and month number as input, verify their validity, and load the data into structures.

• Time-based filter: This component will filter transactions based on the input month and store the filtered transactions in a data structure.

• Label-based categorization: This component will categorize transactions based on the category label in the CSV file.

• Description-based categorization: This component will categorize transactions using an algorithm based on the transaction description.

• Finance registry: This component will store all categorized transactions for further processing. It isolates the post-processing of categorized transactions from the categorization process and provides methods for updating or retrieving datasets.

• Report generation: This component will generate expense reports from the categorized transaction data.

• Telemetry: This component will monitor the performance of other components. It will track the flow of transactions, ensuring that all transactions are categorized either by label or description. Additional parameters can be added as needed to monitor specific functionalities.

The diagram below demonstrates the flow of data through these components:

Detailed Software Design and Component Breakdown

While we won't cover the full system design, this section will highlight key components and their specifications. For this example, I will assume the role of both the designer and implementer of the software.

Software design and specifications depend on several factors, including the designer's knowledge, skill set, available time, and resources. We’ll define some of the design details for the system, starting with the choice of the implementation language.

Choosing the right language is based on several important factors:

1. The language must meet the software requirements.

2. It should be stable, and have strong support from an active developer community.

3. Additional considerations include performance (speed and memory), scalability (ability to grow with future requirements), and platform support (ability to run on all major operating systems).

If you’re the one implementing this design, you’ll need to be familiar with and confident using that programming language. For this project, I chose Python because it meets all the project requirements, has a robust developer community for support, it’s stable, and I’m confident in using it to complete the implementation successfully.

Data Structures

Now, let’s look at the fundamental data structures that we’ll use in the design. We need to load the contents of the CSV file into a data structure for further analysis and processing. In Python, the Pandas DataFrame from the Pandas library is ideal for analyzing and processing tables, so we will use it to store the transactions.

For generating report, we will encapsulate categorized transactions along with relevant statistics, such as the total number of transactions, mean amount, and maximum amount, within a dedicated dataset class. This approach ensures a clear separation of concerns, where the dataset class manages data processing, while the reporting component focuses on presentation.

By structuring the system this way, we enhance reusability, maintainability, and scalability, making it easier to extend and modify in the future.

This dataset class will include:

• Member variables: category name, category description, a Pandas DataFrame for transactions, total number of transactions, mean amount, and max amount of transactions.

• Member functions: set/get DataFrame, save dataset to CSV (useful for debugging).

Here’s an example of a Dataset class in Python for structured data management and processing:

import pandas as pd  # Import Pandas for data handling

class Dataset:
    """
    A class representing a structured dataset with a name, predefined keys, 
    and a Pandas DataFrame.
    """

    def __init__(self, name, keys):
        """
        Initializes the Dataset object.

        Parameters:
        name (str): The name of the dataset.
        keys (list): A list of expected column names for the dataset.

        Attributes:
        self.name (str): Stores the dataset name as a string.
        self.keys (list): Stores the expected column names for data organization.
        self.mean_amt (float): Tracks the mean (average) transaction amount.
        self.max_amt (float): Tracks the maximum transaction amount.
        self.count (int): Stores the total number of transactions in the dataset.
        self.dataframe (pd.DataFrame): A Pandas DataFrame initialized with the specified column names.
        """
        self.name = str(name)  # Convert and store dataset name as a string
        self.keys = keys  # Store expected column names for consistency
        self.mean_amt = 0  # Initialize mean transaction amount to zero
        self.max_amt = 0  # Initialize max transaction amount to zero
        self.count = 0  # Initialize transaction count to zero
        self.dataframe = pd.DataFrame(columns=keys)  # Initialize empty DataFrame with predefined columns

    def getName(self):
        """
        Returns the name of the dataset.

        Returns:
        str: The name of the dataset.
        """
        return self.name  # Fixed: Removed incorrect parentheses

    def getValue(self, key):
        """
        Retrieves a specific column from the DataFrame.

        Parameters:
        key (str): The column name to retrieve.

        Returns:
        pandas.Series or None: The column data if the key exists, otherwise None.
        """
        if key in self.dataframe.columns:
            return self.dataframe[key]
        else:
            print(f"Warning: Key '{key}' not found in DataFrame.")
            return None  # Prevents KeyError

    def getKeys(self):
        """
        Returns the list of expected keys (column names) of the dataset.

        Returns:
        list: The keys defining the dataset.
        """
        return self.keys

    def setDataFrame(self, dataframe):
        """
        Sets the dataset's DataFrame while ensuring it contains only expected keys.

        Parameters:
        dataframe (pandas.DataFrame): The DataFrame to assign to the dataset.
        """
        if not isinstance(dataframe, pd.DataFrame):
            raise TypeError("Provided data is not a valid pandas DataFrame.")

        # Ensure only the expected columns are included
        self.dataframe = dataframe[self.keys].copy() if set(self.keys).issubset(dataframe.columns) else dataframe.copy()

    def getDataFrame(self):
        """
        Returns the DataFrame associated with the dataset.

        Returns:
        pandas.DataFrame: The dataset's DataFrame.
        """
        return self.dataframe

    def save_to_csv(self, file_name):
        """
        Saves the dataset's DataFrame to a CSV file.

        Parameters:
        file_name (str): The name of the CSV file to save.
        """
        self.dataframe.to_csv(file_name, mode='w', index=False)  # Save the DataFrame to CSV

In the previous section, we outlined the high-level system architecture, detailing the core components and their interactions. Now, let’s dive into the detailed design of some of the individual components, specifying how we’ll implement each one and how it’ll function within the system. We’ll also break down the components to explain how they work together to process the input and generate the report.

Below, you can see the flow diagram for the software, illustrating the interaction between the core components and the flow of data through the system.

Category Label-Based Filtering Component

The Category Label-Based Filtering Component classifies transactions by matching their "Category Label" with predefined expense categories from a JSON file. Transactions with valid category labels are stored in the finance registry, while unmatched ones remain for further processing.

• Input: DataFrame of time-filtered transactions, expense categories from JSON.

• Libraries used: Pandas DataFrame.

• Software design: Filters transactions based on the "Category Label" column and assigns them to corresponding categories. Transactions that cannot be categorized remain for further processing.

• Output: DataFrame of remaining transactions with empty values in the "Category Label" field.

• Component tests: Validate handling of valid, invalid, and missing category labels.

Finance Registry Component

The Finance Registry Component manages categorized transactions by storing them as datasets for each expense category. It maintains a structured collection of DataFrames, each containing transactions and summary statistics such as total count, max amount, and mean amount.

• Input: Expense categories from JSON.

• Libraries used: Pandas DataFrame.

• Software design: Implements a class that organizes datasets for all expense categories, providing methods to set and retrieve DataFrames.

• Component tests: Validate dataset creation, ensuring correct storage and retrieval of categorized transactions.

Here’s a simple and efficient Finance Registry implementation in Python for managing categorized financial datasets:

from Dataset import Dataset
import pandas as pd  # Ensure Pandas is imported if used elsewhere

# Define column structure for datasets
KEYS = ("Date", "Description", "Amount", "Transaction Type", "Category", "Account Name", "Labels", "Notes")

# Define dataset names for different financial categories
EXAMPLE_DATASET_NAMES = ("Investment", "Expense", "Savings")

class FinanceRegistry:
    """
    A class to manage categorized financial datasets, including investment, expense, and savings datasets.
    This registry allows structured access to transaction data and maintains aggregated financial metrics.
    """

    def __init__(self):
        """
        Initializes the FinanceRegistry object.

        Attributes:
        self.example_dataset (dict): A dictionary storing Dataset objects for financial datasets.
        """
        self.example_dataset = {name: Dataset(name, KEYS) for name in EXAMPLE_DATASET_NAMES}  # Create datasets for categories

    def setExampleDatasetToRegistry(self, name, dataframe):
        """
        Merges a new dataframe into the existing dataset for a given financial category.

        Parameters:
        name (str): The category name (e.g., "Investment", "Expense", or "Savings").
        dataframe (pd.DataFrame): The new data to be added.

        If the dataset already contains data, it concatenates the new dataframe to the existing one.

        Raises:
        ValueError: If the provided name is not a valid dataset category.
        """
        if name not in self.example_dataset:
            raise ValueError(f"Invalid dataset name: '{name}'. Expected one of {EXAMPLE_DATASET_NAMES}")

        df = self.example_dataset[name].getDataFrame()  # Get existing dataset

        if not dataframe.empty:  # Ensure the new dataframe is not empty
            dataframe = pd.concat([df, dataframe], axis=0, ignore_index=True)  # Append new data

        self.example_dataset[name].setDataFrame(dataframe)  # Update dataset in registry

    def getExampleDatasetFromRegistry(self, name):
        """
        Retrieves the dataset for a given financial category.

        Parameters:
        name (str): The category name (e.g., "Investment", "Expense", or "Savings").

        Returns:
        Dataset: The dataset corresponding to the given name.

        Raises:
        ValueError: If the provided name is not a valid dataset category.
        """
        if name not in self.example_dataset:
            raise ValueError(f"Invalid dataset name: '{name}'. Expected one of {EXAMPLE_DATASET_NAMES}")

        return self.example_dataset[name]

The diagram below illustrates how the Finance Registry organizes these datasets for further processing in the Report Generation component.

Report Generation Component

The Report Generation Component processes categorized transaction datasets from the finance registry and generates summary statistics. It calculates key financial metrics such as maximum amount, mean amount, and total transaction count. It also provides functionality to display categorized transactions in a structured format within the shell.

• Input: Datasets of categorized transactions from the finance registry.

• Libraries used: Numpy for calculations, Tabulate for formatted shell output (if needed).

• Software design: Implements a class with methods to compute financial statistics and display transaction summaries per expense category.

• Component tests: Validate correct calculation of mean, max, and total transactions, and ensure accurate display of categorized datasets in the shell.

Here’s a function to compute transaction statistics, including mean, max, and count, from a dataset in the report generation component:

from Dataset import Dataset
import numpy as np

def calculateStats(dataset):
    """
    Computes statistical metrics for a given dataset.

    Parameters:
    dataset: The dataset containing transaction data.

    Updates:
    - dataset.mean: Mean transaction amount.
    - dataset.max: Maximum transaction amount.
    - dataset.count: Number of transactions.
    """

    # Return early if the dataset has no transactions
    if dataset.dataframe.empty:
        return

    # Extract transaction amounts as a list
    tx_amount_list = dataset.dataframe['Amount'].astype(float).round(2).tolist()

    # Adjust transaction amounts based on "Transaction Type"
    for i, tx_type in enumerate(dataset.dataframe['Transaction Type']):
        if tx_type == 'debit':
            tx_amount_list[i] *= -1  # Convert debit transactions to negative values

    # Compute statistical metrics
    dataset.mean = round(np.mean(tx_amount_list), 2)
    dataset.max = max(tx_amount_list)
    dataset.count = len(tx_amount_list)

This concludes the design section, where we explored key software design elements with a practical example. The next step, implementation, is beyond the scope of this article. But it's crucial to recognize that new challenges often emerge during development, requiring updates to requirements, architecture, and specifications.

The purpose of this article is not to provide a full implementation, but to teach you some basic software design principles through an example. The focus is on understanding how to structure software, define clear requirements, and create scalable architectures, all before writing code.

By following a structured design process, you can shift complex problem-solving from implementation to the architecture phase, where you can explore solutions more effectively using flowcharts, block diagrams, and documentation. This makes the development process more organized, efficient, and maintainable, a crucial skill for real-world software engineering.

If you're learning to code, remember that good design is just as important as writing code itself!

Conclusion: The Value of Thoughtful Software Design

With well-defined problem statements, scope, requirements, specifications, and design, even complex problems can be solved and maintained in a sustainable way.

The steps we went through in this article can help you break down any problem, regardless of its complexity, into smaller, actionable tasks that you and your team can efficiently tackle.

Without proper planning, projects are often plagued by scope creep, wasted time and resources, miscommunication between teams, overly complicated designs, technical debt, and frequent redesigns.
Good design is often simple design, but achieving simplicity is difficult without thorough planning.

Approaching each problem with the mindset of defining a Problem Statement, Scope, Use Cases, Requirements, Architecture, and Specifications helps cultivate a strong software design mindset. This mindset is crucial for developing software that is scalable, maintainable, and high quality.

Wireframes are visual representations of the structure, layout, and functionality of a website, application, or other digital product.

You typically create them during the early stages of the design process, and they provide a simplified and focused view of the user interface and user experience.

You can create a wireframe using a variety of tools, including paper and pencil, whiteboards, or specialized digital software. They usually consist of basic shapes, lines, and text, and aim to communicate the hierarchy of information, the placement of interactive elements, and the flow of user interactions.

Wireframes serve as a blueprint for the design process. They allow designers and stakeholders to quickly iterate and refine ideas before investing time and resources into creating a fully functional prototype or final product. They are an essential tool for creating effective and user-friendly digital experiences.

Why is Wireframing Important?

Wireframing is an important process in web and app design because it helps designers to plan and communicate the layout and functionality of a website or application before it is built. Here are some reasons why wireframing is important:

1. Wireframing helps stake holders visualize the structure of the design: Wireframing allows designers to create a visual representation of the website or application's structure. This includes the layout of pages, navigation, and the placement of various elements.
2. It helps designers focus on functionality: With wireframing, designers can focus on the functionality of the website or application without getting distracted by colors, typography, and other design elements.
3. It saves time and money: Wireframing can save time and money in the long run by identifying potential problems and making necessary changes early on in the design process, rather than during the development phase.
4. It's an easy way to gather feedback: Wireframes are a great way to gather feedback from stakeholders and users, as they provide a clear and simple representation of the design without distracting visual elements.
5. Plan for responsive design: Wireframing is essential when designing for different screen sizes and devices. It allows designers to plan for responsive design and ensure that the website or application works well on all devices.

Types of Wireframes

Everyone has a specific way of doing wireframes. Some designers go from paper sketches to high fidelity wireframes or from low-fidelity wireframes to high-fidelity wireframes.

It all depends on the particular project the designer is working on, what they intend to achieve, and the timeframe they have.

Paper Sketches

I begin my wireframing process by doing paper sketches first, because it allows me put out my ideas really fast without having to bother about neatness and quality. It also saves time when designing – you just think of quick solutions and put them on paper.

Some Techniques for Paper Sketching

• Crazy Eights

In the design world, "Crazy Eights" is a quick sketching exercise that helps designers to quickly generate a variety of design ideas and explore different solutions to a problem, in a short amount of time.

Here's how to do Crazy Eights in design:

1. Start with a blank sheet of paper and fold it in half, then in half again, and one more time so that you end up with 8 rectangles on the page.
2. Set a timer for 8 minutes.
3. Within the first rectangle, sketch out an idea for the design problem you're working on. It doesn't need to be perfect, just get the basic idea down on paper.
4. When the timer goes off, move on to the next rectangle and sketch a new idea. Keep going until you've filled all 8 rectangles.
5. Once you've completed all 8 sketches, take a few minutes to review your ideas and identify the strongest ones.
6. Use the strongest ideas as a starting point for your design, and continue refining and iterating until you have a final product.

You'll see an example of this in a bit when I walk you through my wireframing process.

• 20 Second Sketches

Set a timer for 20 seconds and sketch a simple object or scene. Repeat this exercise multiple times, trying to capture as much detail as possible in each sketch.

• Collaborative Sketching

Pair up with another person and take turns adding to a sketch. Each person has a set amount of time to add their own unique element to the drawing. This exercise encourages collaboration and improvisation.

Low-Fidelity Wireframing

Low-fidelity wireframing is a technique of creating a rough visual representation of a design using simple shapes, lines, and text. Low-fidelity wireframes are the most basic of wireframes. This type of wireframing is typically done with pen and paper, or with a digital tool that allows for quick, low-detail sketches.

Mostly, they focus on the core content and structure of the interface, and are simple and straightforward. Low-fidelity wireframes are a useful tool for designers to quickly explore and iterate on different layout and content options, without getting bogged down in details that can distract from the overall design direction.

Advantages of Low Fidelity Wireframing

• Speed: Low-fidelity wireframes can be created quickly and easily, allowing designers to explore multiple ideas in a short amount of time.
• Flexibility: Low-fidelity wireframes are easy to modify and change as the design evolves, allowing designers to iterate quickly.
• Focus: By focusing on the structure and layout of a design, low-fidelity wireframing helps designers avoid getting distracted by details that may not be relevant.
• Collaboration: Low-fidelity wireframes can be easily shared and discussed with other team members, allowing for greater collaboration and feedback.

Disadvantages of Low Fidelity Wireframing

• Lack of Detail: Low-fidelity wireframes may not provide enough detail to fully convey the intended design, which can lead to misunderstandings and miscommunications.
• Limited Interactivity: Low-fidelity wireframes are static and do not allow for interaction, which can make it difficult to test usability and user flow.
• Limited Realism: Unlike high fidelity wireframes, low-fidelity wireframes may not accurately represent the final product, which can make it difficult to communicate the design to stakeholders who may not be familiar with wireframes.

Why You Might Want to Use Low-Fidelity Wireframes

• For early-stage conceptualization: Low-fidelity wireframes are great for early-stage conceptualization. Because they allow you to quickly iterate and experiment with different layout options without getting caught up in the visual details, low-fidelity wireframes are extremely useful during the initial stages of your design.
• For Time and Resource Efficiency: In situations where time is of great essence, low-fidelity wireframes helps to make changes more rapidly, saving time when needed. Also, it requires fewer resources, which is ideal for situations where resources are scarce.
• For User Testing and Feedback: Low-fidelity wireframes provide a clear representation of the overall structure of your design, allowing for easier feedback from stakeholders and team members. Low-fidelity wireframes are also important during user testing sessions, as it helps you collect valuable insights on the fundamental structure and functionality of a design, before investing significant effort in visual design.

Mid-Fidelity Wireframing

Mid-fidelity wireframing refers to wireframes that are created with a moderate level of detail and design elements. These wireframes typically focus on the overall structure of a product and may include basic typography and design elements.

Advantages of Mid-Fidelity Wireframing

• Efficient Design Process: Mid-fidelity wireframing can be completed quickly and efficiently, allowing designers to iterate and test their designs faster.
• Cost-effective: Mid-fidelity wireframes are less expensive to create than high fidelity wireframes, making them a more cost-effective option for design projects.
• Usability Testing: Mid-fidelity wireframes can be used for usability testing, providing insights into user behaviour and interaction with the product.
• Flexibility: Definitely one of the most importnat advantages of mid-fidelity wireframes. Mid-fidelity wireframes are less detailed than high fidelity wireframes, making it easier to make changes and pivot design direction during the design process.

Disadvantages of Mid-Fidelity Wireframing

• Less Realistic: Mid-fidelity wireframes may not accurately represent the design's final look, which can impact stakeholder and client expectations.
• Limited Visual Details: Mid-fidelity wireframes do not provide as much detail as high fidelity wireframes, making it difficult to communicate the final design vision to stakeholders.
• User Experience Limitations: Because mid-fidelity designs do not have enough visual details to test the user experience effectively, leading to potential usability issues.

You'll see an example of this below when we walk through my process.

Why You Might Want to Use Mid-Fidelity Wireframes

• For Refining Structure and Content: When you need to refine the structure, content and layout of your design, mid-fidelity wireframes are beneficial. They allow you add more detail to your wireframes while being relatively quick to create and modify.
• Information Architecture: Mid-fidelity wireframes provide a clearer structure and visual representation of the design, showing off the userflow better than low-fidelity wireframes.
• Stakeholder Presentation and Approvals: Mid-fidelity wireframes are more polished and appealing than low-fidelity wireframes. This makes them a more effective tool when presenting design ideas to stakeholders and clients.
• Design Consistency: By adding more visual details to the wireframes, a consisent design language can be established across multiple screens or pages.

High-Fidelity Wireframing

High fidelity wireframing refers to the creation of detailed, visually-rich wireframes that closely resemble the final product or website.

These wireframes are often created using tools like Adobe XD or Figma and include elements like typography, color schemes, and detailed user interface elements.

Advantages of High-Fidelity Wireframing

Some advantages of high-fidelity wireframes include:

• Detailed Representation: High fidelity wireframes provide a more detailed representation of the final product, making it easier to communicate the design vision to stakeholders.
• Efficient Testing: High fidelity wireframes can be used for testing purposes, helping designers identify any usability issues before the development phase begins.
• Better Visuals and User Experience: High fidelity wireframes are aesthetically pleasing and provide a more realistic view of the final product which helps users visualize the design better. It gives the users better understanding of how to interact with the product.

Disadvantages of High-Fidelity Wireframing

• Time-consuming: High fidelity wireframes take longer to create than low-fidelity wireframes. It can be challenging to complete high fidelity wireframes withing tight project timelines.
• Cost: High fidelity wireframes can be expensive to create, as it requires a significant amount of skill and effort from the design team.
• Limited Flexibility: High fidelity wireframes are not as flexible as low-fidelity or mid-fidelity wireframes. They are detailed and specific, which makes it challenging to change the design direction once they are completed.

You'll see an example of this in a moment during my process walkthrough.

Why You Might Want to Use High-Fidelity Wireframes

• Hand-off to Development: High-fidelity wireframes provide accurate visuals, detailed specifications, and design assets that facilitate the handoff process to developers.
• High Visual Realism: High-fidelity wireframes closely resemble the final visual design and provides a realistic representation of the user interface, to potential users and stakeholders.
• User Experience Validation: High-fidelity wireframes allow you to test and validate the user experience more accurately. With realistic visuals, you can simulate user interactions, flows and transitions, enabling users to provide meaningful feedback and uncover potential usability issues before development.
• Design Consistency: By including more visual elements than the mid-fidelity wireframes, high-fidelity wireframes helps establish a consistent visual hierarchy and design language that can be carried over to the final product.
• Style Guide Creation: High-fidelity wireframes play a crucial role in developing a style guide for your design. They establish the visuals and design assets that will be used till the launch of the product.

My Wireframing Process

I worked on a mobile app to help pregnant mothers through their pregnancy journey. I started with paper sketches, moved on to mid fidelity wireframes, and then did my high fidelity wireframes.

Step 1 – Paper Sketches

For my paper sketches, I used the Crazy Eights(8s) method, which is a very quick way to put out ideas and inspirations.

Basically, I took out my drawing book, drew 8 identical phone frames and sketched out how I wanted my design to look using a pen. The sketches were more elaborate than usual, because I wanted to move straight to doing mid-fidelity wireframes.

Crazy Eights sketches

Step 2 – Moving to Mid Fidelity Wireframes

Next up, I opened a new Figma file on my laptop and transferred my sketches on paper to phone mockups on Figma.

First, I chose the frame I wanted to use for the designs – Iphone 13 pro.

Choose the phone you want to use

Then I used my sketches as a guide. It was mostly replicating what I already had on paper, digitally.

Next I used rectangles to denote images, and lorem ipsum (dummy text) for parts of the design which needed long texts.

Adding rectangles and dummy text

Prior to this, I had created a style guide. So I just got the icons from the style guide.

My Mid-fidelity Wireframes

Step 3 – Creating High Fidelity Wireframes

This was the last phase of my wireframing. Here, I added colours, images, and real text to my designs.

1. I started by adding colours to the mid-fidelity screens.
2. I also wrote out real text for the screens, making sure the copy matched the branding and purpose of the app.
3. Lastly, I added illustrations and images where needed, helping users relate to the design.

Example of high fidelity wireframing

In high-fidelity wireframing, once the overall structure is in place, you can start adding more details and refining the design. This includes adding visual elements such as images, icons, and typography, as well as defining interactions and transitions.

Share the high-fidelity wireframe with stakeholders, users, or other team members, and gather feedback. Use this feedback to refine the design and make any necessary changes.

Once the wireframe has been approved and refined, finalize it by adding annotations, notes, and any other necessary documentation. The wireframe should be detailed enough to provide a clear understanding of the design to developers, but not so detailed that it hinders the design process.

Completed High Fidelity Wireframes

Note that you can use any type of wireframe you would like to, depending on the specific project you're working on, the stage of the project and your objectives. You should also consider the complexity of the design, the available time and resources, and the needs of the stakeholders and users when determining the appropriate fidelity level for your wireframes.

Conclusion

Wireframing is an essential step in the design process that helps ensure a successful outcome. It enables designers to visualize the layout and functionality of a platform before investing significant time and resources into coding and development.

Incorporating wireframing into your design process can lead to more efficient, effective, and user-friendly designs.

They were introduced by Robert C. Martin in his 2000 paper “Design Principles and Design Patterns” to help developers write software that is easy to understand, modify, and extend.

These concepts were later built upon by Michael Feathers, who introduced us to the SOLID acronym.

The SOLID acronym stands for:

• Single Responsibility Principle (SRP)
• Open-Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

These principles provide a way for developers to organize their code and create software that is flexible, easy to change, and testable. Applying SOLID principles can lead to code that is more modular, maintainable, and extensible, and it can make it easier for developers to work collaboratively on a codebase.

In this tutorial, we will explore each of the SOLID principles in detail, explain why they are important, and provide examples of how you can apply them in practice. By the end of this tutorial, you should have a good understanding of the SOLID principles and how to apply them to your software development projects.

What is the Single Responsibility Principle?

The Single Responsibility Principle (SRP) states that a class should have only one reason to change, or in other words, it should have only one responsibility. This means that a class should have only one job to do, and it should do it well.

If a class has too many responsibilities, it can become hard to understand, maintain, and modify. Changes to one responsibility can inadvertently affect another responsibility, leading to unintended consequences and bugs. By following SRP, we can create code that is more modular, easier to understand, and less prone to errors.

Let's take an example that violates the SRP:

class Marker {
    String name;
    String color;
    int price;

    public Marker(String name, String color, int price) {
        this.name = name;
        this.color = color;
        this.price = price;
    }
}

The above code defines a simple Marker class having three instance variables – name, color and price.

class Invoice {
    private Marker marker;
    private int quantity;

    public Invoice(Marker marker, int quantity) {
        this.marker = marker;
        this.quantity = quantity;
    }

    public int calculateTotal() {
        return marker.price * this.quantity;
    }

    public void printInvoice() {
        // printing implementation
    }

    public void saveToDb() {
        // save to database implementation
    }
}

The above Invoice class violates the SRP because it has multiple responsibilities – it is responsible for calculating the total amount, printing the invoice, and saving the invoice to the database. As a result, if the calculation logic changes, such as the addition of taxes, the calculateTotal() method would require modification. Similarly, if the printing or database-saving implementation changes at any point, the class would need to be changed.

There are several reasons for the class to be modified, which could lead to increased maintenance costs and complexity.

Here's how you can modify the code to follow the SRP:

class Invoice {
    private Marker marker;
    private int quantity;

    public Invoice(Marker marker, int quantity) {
        this.marker = marker;
        this.quantity = quantity;
    }

    public int calculateTotal() {
        return marker.price * this.quantity;
    }
}

class InvoiceDao {
    private Invoice invoice;

    public InvoiceDao(Invoice invoice) {
        this.invoice = invoice;
    }

    public void saveToDb() {
        // save to database implementation
    }
}

class InvoicePrinter {
    private Invoice invoice;

    public InvoicePrinter(Invoice invoice) {
        this.invoice = invoice;
    }

    public void printInvoice() {
        // printing implementation
    }
}

In this refactored example, we have split the responsibilities of the Invoice class into three separate classes: Invoice, InvoiceDao, and InvoicePrinter.

The Invoice class is responsible only for calculating the total amount, and the printing and saving responsibilities have been delegated to separate classes. This makes the code more modular, easier to understand, and less prone to errors.

What is the Open-Closed Principle?

The Open-Closed Principle (OCP) states that software entities (classes, modules, functions, and so on) should be open for extension but closed for modification. This means that the behavior of a software entity can be extended without modifying its source code.

The OCP is essential because it promotes software extensibility and maintainability. By allowing software entities to be extended without modification, developers can add new functionality without the risk of breaking existing code. This results in code that is easier to maintain, extend, and reuse.

Let's take the previous example again.

class InvoiceDao {
    private Invoice invoice;

    public InvoiceDao(Invoice invoice) {
        this.invoice = invoice;
    }

    public void saveToDb() {
        // save to database implementation
    }
}

The InvoiceDao class has a single responsibility of saving the invoice to the database. But, suppose there's a new requirement to save the invoice to a file as well. One way to implement this requirement would be to modify the existing InvoiceDao class by adding a saveToFile() method. But this violates the Open-Closed Principle because it modifies the existing code that has already been tested and is live in production.

To follow the OCP, a better solution would be to create an InvoiceDao interface and implement it separately for database and file saving as shown below:

interface InvoiceDao {
    public void save(Invoice invoice);
}

class DatabaseInvoiceDao implements InvoiceDao {
    @Override
    public void save(Invoice invoice) {
        // save to database implementation
    }
}

class FileInvoiceDao implements InvoiceDao {
    @Override
    public void save(Invoice invoice) {
        // save to file implementation
    }
}

This way, if there's a new requirement to save the invoice to another data store, you can implement a new InvoiceDao implementation without modifying the existing code. Now the InvoiceDao interface is open for extension and closed for modification, which follows the OCP.

What is the Liskov Substitution Principle?

The Liskov Substitution Principle (LSP) states that any instance of a derived class should be substitutable for an instance of its base class without affecting the correctness of the program.

In other words, a derived class should behave like its base class in all contexts. In more simple terms, if class A is a subtype of class B, you should be able to replace B with A without breaking the behavior of your program.

The importance of the LSP lies in its ability to ensure that the behavior of a program remains consistent and predictable when substituting objects of different classes. Violating the LSP can lead to unexpected behavior, bugs, and maintainability issues.

Let's take an example.

interface Bike {
    void turnOnEngine();

    void accelerate();
}

In the given example, the interface Bike has two methods, turnOnEngine() and accelerate(). Two classes implement this interface, Motorbike and Bicycle.

class Motorbike implements Bike {

    boolean isEngineOn;
    int speed;

    @Override
    public void turnOnEngine() {
        isEngineOn = true;
    }

    @Override
    public void accelerate() {
        speed += 5;
    }
}

Motorbike correctly implements the turnOnEngine() method, as it sets the isEngineOn boolean to true. It also correctly implements the accelerate() method by increasing the speed by 5.

class Bicycle implements Bike {

    boolean isEngineOn;
    int speed;

    @Override
    public void turnOnEngine() {
        throw new AssertionError("There is no engine!");
    }

    @Override
    public void accelerate() {
        speed += 5;
    }
}

However, the Bicycle class throws an AssertionError in the turnOnEngine() method because it has no engine. This means that an instance of Bicycle cannot be substituted for an instance of Bike without breaking the behavior of the program.

In other words, if the Bicycle class is considered a subtype of the Bike interface, then according to the LSP, any instance of Bike should be replaceable with an instance of Bicycle without altering the correctness of the program.

But in this case, it's not true because Bicycle throws an AssertionError while trying to turn on the engine. Therefore, the code violates the LSP.

What is the Interface Segregation Principle?

The Interface Segregation Principle (ISP) focuses on designing interfaces that are specific to their client's needs. It states that no client should be forced to depend on methods it does not use.

The principle suggests that instead of creating a large interface that covers all the possible methods, it's better to create smaller, more focused interfaces for specific use cases. This approach results in interfaces that are more cohesive and less coupled.

Consider a Vehicle interface as below:

interface Vehicle {
    void startEngine();
    void stopEngine();
    void drive();
    void fly();
}

And then you have a class called Car that implements the Vehicle interface:

class Car implements Vehicle {

    @Override
    public void startEngine() {
        // implementation
    }

    @Override
    public void stopEngine() {
        // implementation
    }

    @Override
    public void drive() {
        // implementation
    }

    @Override
    public void fly() {
        throw new UnsupportedOperationException("This vehicle cannot fly.");
    }
}

In this example, the Vehicle interface has too many methods. The Car class is forced to implement all of them, even though they cannot fly. This violates the ISP because the Vehicle interface is not properly segregated into smaller interfaces based on related functionality.

Let's understand how you can follow the ISP here. Suppose you refactor the Vehicle interface into smaller, more focused interfaces:

interface Drivable {
    void startEngine();
    void stopEngine();
    void drive();
}

interface Flyable {
    void fly();
}

Now, you can have a class called Car that only implements the Drivable interface:

class Car implements Drivable {

    @Override
    public void startEngine() {
        // implementation
    }

    @Override
    public void stopEngine() {
        // implementation
    }

    @Override
    public void drive() {
        // implementation
    }
}

And, thanks to interface segregation, you can have another class called Airplane that implements both the Drivable and Flyable interfaces:

class Airplane implements Drivable, Flyable {

    @Override
    public void startEngine() {
        // implementation
    }

    @Override
    public void stopEngine() {
        // implementation
    }

    @Override
    public void drive() {
        // implementation
    }

    @Override
    public void fly() {
        // implementation
    }
}

In this example, you have properly segregated the Vehicle interface into smaller interfaces based on related functionality. This adheres to the ISP and makes your code more flexible and maintainable.

What is the Dependency Inversion Principle?

The Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules, but both should depend on abstractions. Abstractions should not depend on details – details should depend on abstractions.

This principle aims to reduce coupling between modules, increase modularity, and make the code easier to maintain, test, and extend.

For example, consider a scenario where you have a class that needs to use an instance of another class. In the traditional approach, the first class would directly create an instance of the second class, leading to a tight coupling between them. This makes it difficult to change the implementation of the second class or to test the first class independently.

But if you apply the DIP, the first class would depend on an abstraction of the second class instead of the implementation. This would make it possible to easily change the implementation and test the first class independently.

Here is an example that violates the DIP:

class WeatherTracker {
    private String currentConditions;
    private Emailer emailer;

    public WeatherTracker() {
        this.emailer = new Emailer();
    }

    public void setCurrentConditions(String weatherDescription) {
        this.currentConditions = weatherDescription;
        if (weatherDescription == "rainy") {
            emailer.sendEmail("It is rainy");
        }
    }
}

class Emailer {
    public void sendEmail(String message) {
        System.out.println("Email sent: " + message);
    }
}

In this example, the WeatherTracker class directly creates an instance of the Emailer class, making it tightly coupled to the implementation. This makes it difficult to change the implementation of the Emailer class or to test the WeatherTracker class independently.

Here is an example of how to apply the DIP to the above code:

interface Notifier {
    public void alertWeatherConditions(String weatherDescription);
}

class WeatherTracker {
    private String currentConditions;
    private Notifier notifier;

    public WeatherTracker(Notifier notifier) {
        this.notifier = notifier;
    }

    public void setCurrentConditions(String weatherDescription) {
        this.currentConditions = weatherDescription;
        if (weatherDescription == "rainy") {
            notifier.alertWeatherConditions("It is rainy");
        }
    }
}

class Emailer implements Notifier {
    public void alertWeatherConditions(String weatherDescription) {
        System.out.println("Email sent: " + weatherDescription);
    }
}

class SMS implements Notifier {
    public void alertWeatherConditions(String weatherDescription) {
        System.out.println("SMS sent: " + weatherDescription);
    }
}

In this example, we created a Notifier interface that defines the alertWeatherConditions method. The WeatherTracker class now depends on this interface instead of the Emailer class, making it possible to easily change the implementation and test the WeatherTracker class independently.

We also created two implementations of the Notifier interface, Emailer, and SMS, to demonstrate how you can change the implementation of the WeatherTracker class without affecting its behavior.

Conclusion

In this article, you learned about the SOLID principles which are a very important part of general Design Principles.

By applying these principles in your software development projects, you can create code that is easier to maintain, extend, and modify, leading to more robust, flexible, and reusable software. This will also lead to better collaboration among team members, as the code becomes more modular and easier to work with.

For more such tutorials, you can follow my personal blog.

They also make it easy to create readable and testable code that many developers can collaboratively work with anywhere and anytime. And they make you aware of the best way to write code 💪.

SOLID is a mnemonic acronym that stands for the five design principles of Object-Oriented class design. These principles are:

• S - Single-responsibility Principle

• O - Open-closed Principle

• L - Liskov Substitution Principle

• I - Interface Segregation Principle

• D - Dependency Inversion Principle

In this article, you will learn what these principles stand for and how they work using JavaScript examples. The examples should be fine even if you are not fully conversant with JavaScript, because they apply to other programming languages as well.

What is the Single-Responsibility Principle (SRP)?

The Single-responsibility Principle, or SRP, states that a class should only have one reason to change. This means that a class should have only one job and do one thing.

Let’s take a look at a proper example. You’ll always be tempted to put similar classes together – but unfortunately, this goes against the Single-responsibility principle. Why?

The ValidatePerson object below has three methods: two validation methods, (ValidateName() and ValidateAge()), and a Display() method.

class ValidatePerson {
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }

    ValidateName(name) {
        if (name.length > 3) {
            return true;
        } else {
            return false;
        }
    }

    ValidateAge(age) {
        if (age > 18) {
            return true;
        } else {
            return false;
        }
    }

    Display() {
        if (this.ValidateName(this.name) && this.ValidateAge(this.age)) {
            console.log(`Name: ${this.name} and Age: ${this.age}`);
        } else {
            console.log('Invalid');
        }
    }
}

The Display() method goes against the SRP because the goal is that a class should have only one job and do one thing. The ValidatePerson class does two jobs – it validates the person’s name and age and then displays some information.

The way to avoid this problem is to separate code that supports different actions and jobs so that each class only performs one job and has one reason to change.

This means that the ValidatePerson class will only be responsible for validating a user, as seen below:

class ValidatePerson {
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }

    ValidateName(name) {
        if (name.length > 3) {
            return true;
        } else {
            return false;
        }
    }

    ValidateAge(age) {
        if (age > 18) {
            return true;
        } else {
            return false;
        }
    }
}

While the new class DisplayPerson will now be responsible for displaying a person, as you can see in the code block below:

class DisplayPerson {
    constructor(name, age) {
        this.name = name;
        this.age = age;
        this.validate = new ValidatePerson(this.name, this.age);
    }

    Display() {
        if (
            this.validate.ValidateName(this.name) &&
            this.validate.ValidateAge(this.age)
        ) {
            console.log(`Name: ${this.name} and Age: ${this.age}`);
        } else {
            console.log('Invalid');
        }
    }
}

With this, you will have fulfilled the single-responsibility principle, meaning our classes now have just one reason to change. If you want to change the DisplayPerson class, it won’t affect the ValidatePerson class.

What is the Open-Closed Principle?

The open-closed principle can be confusing because it's a two-direction principle. According to Bertrand Meyer's definition on Wikipedia, the open-closed principle (OCP) states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

This definition can be confusing, but an example and further clarification will help you understand.

There are two primary attributes in the OCP:

• It is open for extension — This means you can extend what the module can do.

• It is closed for modification — This means you cannot change the source code, even though you can extend the behavior of a module or entity.

OCP means that a class, module, function, and other entities can extend their behavior without modifying their source code. In other words, an entity should be extendable without modifying the entity itself. How?

For example, suppose you have an array of iceCreamFlavours, which contains a list of possible flavors. In the makeIceCream class, a make() method will check if a particular flavor exists and logs a message.

const iceCreamFlavors = ['chocolate', 'vanilla'];

class makeIceCream {
    constructor(flavor) {
        this.flavor = flavor;
    }

    make() {
        if (iceCreamFlavors.indexOf(this.flavor) > -1) {
            console.log('Great success. You now have ice cream.');
        } else {
            console.log('Epic fail. No ice cream for you.');
        }
    }
}

The code above fails the OCP principle. Why? Well, because the code above is not open to an extension, meaning for you to add new flavors, you would need to directly edit the iceCreamFlavors array. This means that the code is no longer closed to modification. Haha (that's a lot).

To fix this, you would need an extra class or entity to handle addition, so you no longer need to modify the code directly to make any extension.

const iceCreamFlavors = ['chocolate', 'vanilla'];

class makeIceCream {
    constructor(flavor) {
        this.flavor = flavor;
    }
    make() {
        if (iceCreamFlavors.indexOf(this.flavor) > -1) {
            console.log('Great success. You now have ice cream.');
        } else {
            console.log('Epic fail. No ice cream for you.');
        }
    }
}

class addIceCream {
    constructor(flavor) {
        this.flavor = flavor;
    }
    add() {
        iceCreamFlavors.push(this.flavor);
    }
}

Here, we've added a new class — addIceCream – to handle addition to the iceCreamFlavors array using the add() method. This means your code is closed to modification but open to an extension because you can add new flavors without directly affecting the array.

let addStrawberryFlavor = new addIceCream('strawberry');
addStrawberryFlavor.add();
makeStrawberryIceCream.make();

Also, notice that SRP is in place because you created a new class. 😊

What is the Liskov Substitution Principle?

In 1987, the Liskov Substitution Principle (LSP) was introduced by Barbara Liskov in her conference keynote “Data abstraction”. A few years later, she defined the principle like this:

“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”.

To be honest, that definition is not what many software developers want to see 😂 — so let me break it down into an OOP-related definition.

The principle defines that in an inheritance, objects of a superclass (or parent class) should be substitutable with objects of its subclasses (or child class) without breaking the application or causing any error.

In very plain terms, you want the objects of your subclasses to behave the same way as the objects of your superclass.

A very common example is the rectangle, square scenario. It’s clear that all squares are rectangles because they are quadrilaterals with all four angles being right angles. But not every rectangle is a square. To be a square, its sides must have the same length.

Bearing this in mind, suppose you have a rectangle class to calculate the area of a rectangle and perform other operations like set color:

class Rectangle {
    setWidth(width) {
        this.width = width;
    }

    setHeight(height) {
        this.height = height;
    }

    setColor(color) {
        // ...
    }

    getArea() {
        return this.width * this.height;
    }
}

Knowing fully well that all squares are rectangles, you can inherit the properties of the rectangle. Since the width and height has to be the same, then you can adjust it:

class Square extends Rectangle {
    setWidth(width) {
        this.width = width;
        this.height = width;
    }
    setHeight(height) {
        this.width = height;
        this.height = height;
    }
}

Taking a look at the example, it should work properly:

let rectangle = new Rectangle();
rectangle.setWidth(10);
rectangle.setHeight(5);
console.log(rectangle.getArea()); // 50

In the above, you will notice that a rectangle is created, and the width and height are set. Then you can calculate the correct area.

But according to the LSP, you want the objects of your subclasses to behave the same way as the objects of your superclass. Meaning if you replace the Rectangle with Square, everything should still work well:

let square = new Square();
square.setWidth(10);
square.setHeight(5);

You should get 100, because the setWidth(10) is supposed to set both the width and height to 10. But because of the setHeight(5), this will return 25.

let square = new Square();
square.setWidth(10);
square.setHeight(5);
console.log(square.getArea()); // 25

This breaks the LSP. To fix this, there should be a general class for all shapes that will hold all generic methods that you want the objects of your subclasses to have access to. Then for individual methods, you create an individual class for rectangle and square.

class Shape {
    setColor(color) {
        this.color = color;
    }
    getColor() {
        return this.color;
    }
}

class Rectangle extends Shape {
    setWidth(width) {
        this.width = width;
    }
    setHeight(height) {
        this.height = height;
    }
    getArea() {
        return this.width * this.height;
    }
}

class Square extends Shape {
    setSide(side) {
        this.side = side;
    }
    getArea() {
        return this.side * this.side;
    }
}

This way, you can set the color and get the color using either the super or subclasses:

// superclass
let shape = new Shape();
shape.setColor('red');
console.log(shape.getColor()); // red

// subclass
let rectangle = new Rectangle();
rectangle.setColor('red');
console.log(rectangle.getColor()); // red

// subclass
let square = new Square();
square.setColor('red');
console.log(square.getColor()); // red

What is the Interface Segregation Principle?

The Interface Segregation Principle (ISP) states that “a client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use”. What does this mean?

Just as the term segregation means — this is all about keeping things separated, meaning separating the interfaces.

Note: By default, JavaScript does not have interfaces, but this principle still applies. So let’s explore this as if the interface exists, so you will know how it works for other programming languages like Java.

A typical interface will contain methods and properties. When you implement this interface into any class, then the class needs to define all its methods. For example, suppose you have an interface that defines methods to draw specific shapes.

interface ShapeInterface {
    calculateArea();
    calculateVolume();
}

When any class implements this interface, all the methods must be defined even if you won't use them or if they don’t apply to that class.

class Square implements ShapeInterface {
    calculateArea(){
        //...
    }
    calculateVolume(){
        //...
    }  
}

class Cuboid implements ShapeInterface {
    calculateArea(){
        //...
    }
    calculateVolume(){
        //...
    }    
}

class Rectangle implements ShapeInterface {
    calculateArea(){
        //...
    }
    calculateVolume(){
        //...
    }   
}

Looking at the example above, you will notice that you cannot calculate the volume of a square or rectangle. Because the class implements the interface, you need to define all methods, even the ones you won’t use or need.

To fix this, you would need to segregate the interface.

interface ShapeInterface {
    calculateArea();
}

interface ThreeDimensionalShapeInterface {
    calculateArea();
    calculateVolume();
}

You can now implement the specific interface that works with each class.

class Square implements ShapeInterface {
    calculateArea(){
        //...
    } 
}

class Cuboid implements ThreeDimensionalShapeInterface {
    calculateArea(){
        //...
    }
    calculateVolume(){
        //...
    }    
}

class Rectangle implements ShapeInterface {
    calculateArea(){
        //...
    }  
}

What is the Dependency Inversion Principle?

This principle is targeted towards loosely coupling software modules so that high-level modules (which provide complex logic) are easily reusable and unaffected by changes in low-level modules (which provide utility features).

According to Wikipedia, this principle states that:

1. High-level modules should not import anything from low-level modules. Both should depend on abstractions (for example, interfaces).

2. Abstractions should be independent of details. Details (concrete implementations) should depend on abstractions.

In plain terms, this principle states that your classes should depend upon interfaces or abstract classes instead of concrete classes and functions. This makes your classes open to extension, following the open-closed principle.

Let's look at an example. When building a store, you would want your store to make use of a payment gateway like stripe or any other preferred payment method. You might write your code tightly coupled to that API without thinking of the future.

But then what if you discover another payment gateway that offers far better service, let’s say PayPal? Then it becomes a struggle to switch from Stripe to Paypal, which should not be an issue in programming and software design.

class Store {
    constructor(user) {
        this.stripe = new Stripe(user);
    }

    purchaseBook(quantity, price) {
        this.stripe.makePayment(price * quantity);
    }

    purchaseCourse(quantity, price) {
        this.stripe.makePayment(price * quantity);
    }
}

class Stripe {
    constructor(user) {
        this.user = user;
    }

    makePayment(amountInDollars) {
        console.log(`${this.user} made payment of ${amountInDollars}`);
    }
}

Considering the example above, you'll notice that if you change the payment gateway, you won't just need to add the class – you'll also need to make changes to the Store class. This does not just go against the Dependency Inversion Principle but also against the open-closed principle.

To fix this, you must ensure that your classes depend upon interfaces or abstract classes instead of concrete classes and functions. For this example, this interface will contain all the behavior you want your API to have and doesn't depend on anything. It serves as an intermediary between the high-level and low-level modules.

class Store {
    constructor(paymentProcessor) {
        this.paymentProcessor = paymentProcessor;
    }

    purchaseBook(quantity, price) {
        this.paymentProcessor.pay(quantity * price);
    }

    purchaseCourse(quantity, price) {
        this.paymentProcessor.pay(quantity * price);
    }
}

class StripePaymentProcessor {
    constructor(user) {
        this.stripe = new Stripe(user);
    }

    pay(amountInDollars) {
        this.stripe.makePayment(amountInDollars);
    }
}

class Stripe {
    constructor(user) {
        this.user = user;
    }

    makePayment(amountInDollars) {
        console.log(`${this.user} made payment of ${amountInDollars}`);
    }
}

let store = new Store(new StripePaymentProcessor('John Doe'));
store.purchaseBook(2, 10);
store.purchaseCourse(1, 15);

In the code above, you will notice that the StripePaymentProcessor class is an interface between the Store class and the Stripe class. In a situation where you need to make use of PayPal, all you have to do is create a PayPalPaymentProcessor which would work with the PayPal class, and everything will work without affecting the Store class.

class Store {
    constructor(paymentProcessor) {
        this.paymentProcessor = paymentProcessor;
    }

    purchaseBook(quantity, price) {
        this.paymentProcessor.pay(quantity * price);
    }

    purchaseCourse(quantity, price) {
        this.paymentProcessor.pay(quantity * price);
    }
}

class PayPalPaymentProcessor {
    constructor(user) {
        this.user = user;
        this.paypal = new PayPal();
    }

    pay(amountInDollars) {
        this.paypal.makePayment(this.user, amountInDollars);
    }
}

class PayPal {
    makePayment(user, amountInDollars) {
        console.log(`${user} made payment of ${amountInDollars}`);
    }
}

let store = new Store(new PayPalPaymentProcessor('John Doe'));
store.purchaseBook(2, 10);
store.purchaseCourse(1, 15);

You will also notice that this follows the Liskov Substitution Principle because you can replace it with other implementations of the same interface without breaking your application.

Ta-Da 😇

It's been an adventure🙃. I hope you noticed that each of these principles are related to the others in some way.

In an attempt to correct one principle, say the dependency inversion principle, you indirectly ensure that your classes are open to extension but closed to modification, for example.

You should keep these principles in mind when writing code, because they make it easier for many people to collaborate on your project. They simplify the process of extending, modifying, testing, and refactoring your code. So make sure you understand their definitions, what they do, and why you need them beyond OOP.

For more understanding, you can watch this video by Beau Carnes on the freeCodeCamp YouTube channel or read this article by Yiğit Kemal Erinç.

Have fun coding!

You can access over 200 of my articles by visiting my website. You can also use the search field to see if I've written a specific article.

Those rules are known as design principles, and in this article, you will learn the basics of the 13 design principles.

Knowing what design principles are will give you a better understanding of how to go about creating more harmonious designs and better user experiences.

Here is what we will cover in this guide:

1. What are design principles?
2. The 13 principles of design
   1. Balance
   2. Variety
   3. Emphasis
   4. Contrast
   5. Hierarchy
   6. Repetition
   7. Pattern
   8. Movement
   9. Rhythm
   10. Proportion
   11. Alignment
   12. Unity
   13. White space

What Are Design Principles?

Design principles are a strict set of rules.

Designers adhere to those rules to create pleasant user experiences and visually appealing end products.

These rules are tools and guidelines that help the designer create a sense of harmony and balance in their designs.

They guarantee usability and an overall pleasing effect for viewers and users.

The 13 Principles Of Design

Balance

Every design element on a page has a different weight, depending on its size, shape, or color.

That weight is known as visual weight.

Balance in design is how you arrange and position elements in a composition, and it's about distributing the weight of those elements.

A composition lacking in balance means that one element overpowers all the rest.

To create balance, you need to position elements properly.

For example, this could be that an element on one side is much 'heavier' than the rest and is overpowering, thus making the design look unstable.

There are two types of balance:

• Symmetrical balance
• Asymmetrical balance

With Symmetrical balance, think of drawing an invisible, vertical line down the center of the page and splitting the page into two sides.

The items on both sides of the line have evenly distributed visual weight and create a mirrored image.

The order, the position, and the alignment of elements are equal on both sides, creating consistency in the design.

Asymmetrical balance is the opposite of symmetrical balance.

Elements on both sides have different arrangements, as they also have an order and positioning that varies in the composition.

Even though each side has a different visual weight, the overall design maintains an equal visual weight on both sides.

There is no mirrored image, and both sides look different, but the design is still stable.

For example, asymmetrical design can be when three lighter elements stacked on top of one another on one side balance out one single heavier item on the opposite side.

Asymmetrical balance creates visual interest and adds a modern feel to the design.

Variety

Variety creates visual interest and prevents the design from becoming monotonous and predictable.

Variety is created by using elements that are not similar to one another.

With the use of the variety, you have a good chance of maintaining the interest and engagement of viewers.

Variety in design is achieved with the use of many different things, a few of which are:

• Varying sizes,
• Varying shapes,
• Varying colors,
• Varying textures,
• Varying typography.

Emphasis

The purpose of emphasis is to create a focal point.

A focal point is an object that stands out instantly and grabs the viewer's or user's attention at first sight.

When there is an emphasis on a design element, it means that the specific object is highlighted from the rest and is therefore of great significance and importance.

For example, you can think of emphasis as some text with all-caps and a bold type.

Emphasis can be the main heading on a website.

It can also be a message of some kind.

You may want to convey something crucial or cautionary to your viewers and need to make sure that your audience is aware of it and focuses on that first.

Emphasis can also be a large button with a bright color under an item for purchase - this can act as a call to action for visitors.

It's what you want others to notice first - the essential information someone needs to be aware of and pay attention to upon first viewing your work.

It's a specific piece of content that needs to stand out from the rest of the design.

Besides text and color, emphasis is achieved with size, shape, weight, texture, and position, to name a few.

When creating emphasis, make sure that you do it without disturbing the overall balance of the composition and without creating an overpowering and jarring effect.

Contrast

While emphasis is about accentuating one single element, contrast has to do with the apparent, stand-out degree of difference between two or more design elements that are close together.

This difference can be that one element has a dark background color, and the other has a light one.

It can also be that one element has a cooler tone, whereas the other has a warmer tone. Or that one element is larger and the other is smaller in size. Or using a serif font on some text and a sans-serif text on another piece of text.

For example, take this webpage.

When browsing the page from a desktop computer or a laptop, you will see that at the top right corner, there are two buttons you can click on:

• the 'Forum' button has a dark background color that is the same as the rest of the navigation bar,
  • the 'Donate' button has a bright yellow background color that makes it stand out.

That is considered contrast. There are two very different elements next to one another, but one catches the eye the most and demands your attention.

All-in-all, contrast highlights two totally opposing elements with highly different characteristics. The difference has to be a noticeable one.

There are different types of contrast, such as color contrast or size, shape, or texture contrast.

The purpose is to create variation and interest and therefore create focus and emphasis while maintaining balance in the design.

Good contrast goes hand in hand with accessibility best practices and creating usable products and services for everyone. It's necassary to take into consideration people with visual impairments.

Think of another example.

Say there is an element with a light grey background and some dark grey text. Then, there is another element with the same background color, but there is some black text.

Which one is easier to read? The second one with the black text.

There is a higher color contrast between the background color and foreground (text) color.

There is a lack of contrast in the first element - this makes reading the text much harder.

Hierarchy

Hierarchy organizes visual elements in order of importance.

The role of hierarchy in design is to create a visual ranking system according to the logical priority of content. It helps guide viewers from the most important information to the least important by creating a logical flow and arrangement of that content.

Think of the typical order of elements on a webpage.

We read from top to bottom, so the viewer's eye must be first drawn immediately to essential information before they start scrolling down the page.

So this means that the crucial information needs to be at the top of the page - it needs to be the most prominent and rank the highest on the page.

Take the following example.

At the top of a webpage, there is typically the company logo first.

Then, there is a navigation bar or dropdown menu, which helps users decide the area of the site they want to interact with.

There can also be a search bar for users to enter keywords to search for a specific topic and save time.

Then, there can be a call to action or the main heading that reinforces the purpose of the page and its content.

Then, there can be the main area that would contain a subheading with some text, then another subheading with more text, and so on.

This order creates visual organization and helps viewers distinguish what content appears to be the most important and deserves their attention.

It guides viewers from the start of the content to the end - from highest priority to least priority.

The position of elements signifies importance - the most important information is always higher on a page, whereas if something is at the bottom, it is not as important.

Other ways to create hierarchy in design are using colors to create contrast and alternate the sizing of elements in different ways.

Without hierarchy, all content would appear the same, and nothing would stand out and signal importance, which would lead to confusion for viewers.

Repetition

Repetition is when a specific element is repeated multiple times throughout the design.

The role of repetition in design is to create consistency and unity.

Repetition creates relationships and associations between seemingly separate and different elements and creates a bond between them - a common link that ties everything together.

To achieve repetition, you use the same particular color or the same color scheme multiple times throughout the design.

Or stick to a specific font type or use a recurring phrase throughout the page.

A commonly repeated element in designs is a logo, which plays a critical part in creating a brand identity.

A logo will make viewers and users familiar with the brand. They will recognize and distinguish its voice and tone from other brands.

Users will memorize and identify the logo with the company's vision and mission.

They will know what the brand is all about.

Pattern

Pattern at first glance appears to be very similar to repetition since it implies that elements reoccur multiple times throughout the page.

However, they have significant differences.

While repetition deals with the same element repeating throughout the design, a pattern focuses on multiple and different design elements repeating in the same way throughout the composition.

A pattern in design is all about the repetition of more than one element.

An example of a pattern in everyday life is floor tiles and wallpapers.

An example of a pattern on the web is the use of backgrounds in websites and applications to create harmony and a cohesive feel.

Movement

Movement is how the eyes move when viewing and interacting with a composition.

Movement refers to the way the viewer's eye travels and the path it takes throughout a design.

The designer uses movement to guide the viewer around different design elements.

They create different focal areas for each point in time to effectively capture the viewer's attention, moving from one element to another in a well-thought-out directed sequence.

Typically, the viewer's eye first sees the most important element, then the second most important, then the third one, and so on.

An example of movement can be viewing a spiraling staircase when you are standing at the top - your eye will move along the different lines and edges.

Movement on the web can be created by:

• The use of animated effects,
• The use of blurring effects,
• The use of spiraling effects,
• The use of lines and edges,
• The use of different direction signs that provide guidance, indicating to the viewer to move their focus to the left, right, or look downwards or upwards.

Rhythm

Rhythm involves the combination of repetition, variety, and movement.

Rhythm is how multiple design elements that are different from each other repeat in a particular order.

Repeating or alternating a group of different elements in the same order and at specific intervals is a way to create rhythm in design.

There are five different types of rhythm in design, depending on the type of interval:

• Random rhythm,
• Regular rhythm,
• Flowing rhythm,
• Progressing rhythm,
• Alternating rhythm.

The elements follow a tempo and move and flow in an organized way.

It resembles the feeling of following a dance choreography or moving to the beat of some music.

Instead of bringing the attention to only one area of the design or guiding the viewer from one different part to another, rhythm focuses on moving the viewer's eyes across the whole composition.

Proportion

Proportion in design refers to the size and visual weight of two or more visual elements.

Proportion is also the relationship between those visual elements.

The relationship is based on size. It's how the size of one object compares and is correlated to the size of the other object.

Essentially, it is how elements scale in size in relation to each other.

For example, proportion compares and measures the importance of elements to one another.

Say there are two objects - one is bigger and the other is much smaller.

The bigger element will be more noticeable, which indicates that it is more important than the smaller one.

A well-proportioned design means that the size of all the elements preserves balance, unity, and harmony for the whole design.

Good proportion means that all elements relate well to each other.

Alignment

Alignment refers to how visual elements are lined up, ordered, and structured in comparison to one another and in comparison to the whole design.

It is a way to create a connection and visual flow between related objects and create a more unified result in the design.

By aligning the different visual objects, you help guide your viewer throughout the design.

The most common forms of alignment are left-aligned, right-aligned, and center-aligned.

Unity

Unity in design is how different visual elements come together to create cohesion and completeness in the design and a harmonious effect.

With unity, seemingly different items create a sense of 'oneness'. This can be achieved in a few different ways.

For example, elements of different sizes can all have the same color and be near one another.

This makes them appear as if they belong together or as if they are related and are similar in some way.

White Space

White space is also known as negative space.

Essentially, white space refers to areas that lack visual elements, and areas with unused, empty space around already existing elements in a design.

White space doesn't necessarily mean that the empty space is white in color - it can be any color. It more so refers to the emptiness and available room in your design and the fact that some areas don't contain anything.

White space is about not adding any elements to the composition and takes a more minimalistic and simplistic approach to design. Sometimes, less is indeed more.

White space creates breathing room in the design.

When a lot is going on on a page, viewers can easily become overwhelmed with all the information they need to take in. White space helps to prevent that from happening. It makes any available text more readable and creates an all-around better user experience.

White space eliminates any unnecessary clutter and creates a focal point. So, use white space around important elements to make them stand out.

Conclusion

Hopefully, now you have a high-level understanding of design principles and have a better idea of how to implement them in your future designs.

Thanks for reading!

So here, hopefully, is a good one – with a non trivial and real life example, what changes to support, and a description of the trade offs.

The Open-Closed principle states that code should be "Open for extension" and "Closed for modification".

There is quite a lot of confusion about the term, but essentially it means that if you want to implement a supported change, you should be able to do it without changing the code in a large number of places. Ideally, you can implement the new feature just by adding new code, and changing little or no old code, which makes the code easier to develop and maintain.

Open is the 'O' in the SOLID design principles, which are probably the most famous guides for writing high quality code.

No useful code can ever be completely open to all possible changes, so we have to decide which changes we are going to support. When writing our code we can think about what the potential changes might be, decide which ones to support, and then make the code 'open' to these.

We can create a list of these potential changes by:

• Analysing the code
• Looking at previous changes to the code
• Using our experience of commonly requested changes
• Using any knowledge of upcoming feature requests

Take a minute to look at the code below (and on GitHub) and think about what changes we might expect. You don't have access to the commit history, or any knowledge of upcoming feature requests, but you can still probably come up with some likely candidates.

public class GrossToNetCalculator
{
    public GrossToNetCalculator(
        IGrossEnergyYield grossYield,
        double grossEnergy,
        double hysteresisLoss,
        double curtailmentLossGrid,
        double turbineLossTurbulence,
        double electricalLoss,
        double turbineLossShear,
        double turbinePerformanceExperience,
        double operationalExperienceLoss)
    {
        double dependentLoss = 
            CombinePercentages(
                grossYield.TurbineAvailability,
                grossYield.BalanceAvailability,
                grossYield.AccessibilityAvailability,
                hysteresisLoss,
                electricalLoss,
                grossYield.EnvironmentalShutdownWeather,
                grossYield.EnvironmentalSiteAccess,
                grossYield.EnvironmentTreeGrowth);

        double independentLoss = 
            CombinePercentages(
                grossYield.GridAvailability,
                turbinePerformanceExperience,
                turbineLossTurbulence,
                grossYield.EnvironmentalPerformanceDegradationIcing,
                grossYield.CurtailmentPowerPurchase,
                grossYield.SubOptimalPerformance,
                turbineLossShear,
                operationalExperienceLoss);

        GrossToNet = 
            1 - 
            (1 - (dependentLoss + curtailmentLossGrid))
            * (1 - independentLoss);
    }

    double CombinePercentages(params double[] percentages)
    {
        double combination = 1;
        foreach (var percentage in percentages)
            combination *= 1 - percentage;
        return 1 - combination;
    }

    public double GrossToNet { get; private set; }
}

This code is relatively simple, and when I look at it these are the potential changes that I see:

• Items could be added or removed from the dependentLoss and independentLoss calculations. Items could be also be moved between dependentLoss and independentLoss, but this is essentially the same thing
• The calculation of GrossToNet could change
• The CombinePercentages calculation could change

As with most things in computer programming, there is a tension when applying the Open-Closed Principle.

On the one hand, making the code more easily extensible is good. On the other hand, doing this often breaks encapsulation, adds complication, and adds unnecessary levels of abstraction.

So again, we need to make a decision about which of these changes we want to support and make the code 'open to'. We can then avoid adding unnecessary complication to the code for unsuitable changes.

It is worth remembering that the work can always be done later, when it will be easier, as we will know exactly what is required.

To make a decision about what changes we should support and make the code 'open to', we need to estimate how likely the change is to occur, think about design solutions, and then think about the trade offs.

We Could Add or Remove Items from the dependentLoss and independentLoss Calculations

Very likely to change

The calculation of dependentLoss and independentLoss (for example double dependentLoss = CombinePercentages(...)) each use 8 parameters (electricalLoss, TurbineAvailability and so on).

These 16 make up the majority of the 17 total inputs to the entire calculation. So, from a purely statistical point of view, a change to one of these has a 16/17 (94%) chance of affecting these calculations.

It's also easy to imagine that we might want to add another "Loss" or "Availability" or similar in the future, or that a current one is no longer relevant, or that different combinations will be required in different circumstances.

Possible solution

Take a list of dependent and independent losses in the constructor, instead of taking each loss individually. So the existing constructor:

public GrossToNetCalculator(
    ...
    double hysteresisLoss,
    double curtailmentLossGrid,
    ...)

is replaced with this:

public GrossToNetCalculator(
    IReadOnlyList<double> dependentLosses
    IReadOnlyList<double> independentLosses)

This means that if the change is requested, we can implement it without changing the class (and instead just changing the parameters we pass to the constructor).

For example, if another 'dependentLoss' is requested, we can just add this to the dependentLosses list.

(You can see the code on GitHub here)

Trade offs

A small amount of encapsulation is lost, and the calling code would now be in charge of deciding which losses to pass in.

The code adheres much better to the Open-Closed Principle and becomes much more easily extendable and reusable. If you need to make a change, you won't need to modify the tests, which is useful as they are complicated.

Tests for the calling code would have to modified, but only to verify that they pass the correct parameters, which is much simpler.

It is possible that the constructor parameters are passed around in the code base, and now there are only two parameters, as opposed to the previous nine.

Decision

We should implement this solution to support this change and make the code 'open' to it.

The GrossToNet Calculation Could Change

Unlikely to change

The GrossToNet calculation is GrossToNet = 1 - (1 - (dependentLoss + curtailmentLossGrid)) * (1 - independentLoss);

Only the curtailmentLossGrid parameter is used, aside from the dependentLoss and independentLoss which are covered earlier.

This 1 parameter is a small minority of the 17 total inputs to the entire calculation. So, from a purely statistical point of view, a change to one of these has a 1/17 (6%) chance of affecting this calculation.

Possible solutions

1. Take a lambda parameter in the constructor to calculate GrossToNet and pass it dependentLoss and independentLoss, so that the calculation becomes GrossToNet = grossToNetCalculatorLambda(dependentLoss, independentLoss)(code on GitHub)
2. Remove curtailmentLossGrid from the calculation, which then becomes completely generic and can be renamed to PercentageCombiner. Require that the calling code applies this adjustment (this adjustment is too complicated for useful example code)
3. Remove curtailmentLossGrid from the calculation as above, then recreate the original GrossToNetCalculator, using the PercentageCombiner and adding curtailmentLossGrid to the calculation
   (code on GitHub)

Trade Offs

A large amount of encapsulation is lost for options 1 and 2. Option 3 is a reasonable amount of work, and adds a layer of abstraction.

Decision

This change isn't likely to happen, so it probably isn't worth the effort involved to support it and make the code 'open' to it. But if we had another use for the new PercentageCombiner then it would definitely be worthwhile.

The CombinePercentages Calculation Could Change

Very unlikely to change

CombinePercentages(params double[] percentages)
{
    double combination = 1;
    foreach (var percentage in percentages)
    combination *= 1 - percentage;
    return 1 - combination;
}

The CombinePercentages calculation implements some standard laws of math / statistics, which do not change.

Possible solutions

1. Take a lambda parameter in the constructor to combine the percentages, and use this instead of the CombinePercentages function. So instead of having double dependentLoss = CombinePercentages(...), you would have double dependentLoss = combinePercentagesLambda(...).
   (code on GitHub)
2. Create a PercentageCombiner abstraction, take this in the constructor to combine the percentages, and use this instead of the CombinePercentages function. So instead of having double dependentLoss = CombinePercentages(...), you would have double dependentLoss = percentageCombiner.CombinePercentages(...).
   (code on GitHub)

Trade offs

Combining percentages is at the heart of what this code does, so removing this logic makes the code mostly useless.

Option 1 passes all the responsibility for this on to the caller, whereas option 2 at least allows for predefined implementations of the abstraction.

Decision

This change is very unlikely, and the only reasonable solution (option 2) requires a lot of work and adds complexity and abstraction.

This means that it would only make sense to do it when the change is actually required, and even then only if multiple algorithms are required. Note that if a change is required to the algorithm, it will make more sense to simply change the implementation of the CombinePercentages function.

Conclusion

Deciding whether code adheres to the Open-Closed Principle is almost always a judgement call, and there are usually trade offs involved with encapsulation, complexity and abstraction.

It is worth thinking about likely changes and extensions, and using these to guide your decisions.

When I first learned about MVC patterns, I was intimidated by all the jargon. And even more so when I started applying these concepts to an actual application.

By taking a step back to focus on what MVC is and what it can accomplish, it's much easier to understand and apply the pattern to any web application.

What is MVC?

MVC stands for model-view-controller. Here's what each of those components mean:

• Model: The backend that contains all the data logic
• View: The frontend or graphical user interface (GUI)
• Controller: The brains of the application that controls how data is displayed

The concept of MVCs was first introduced by Trygve Reenskaug, who proposed it as a way to develop desktop application GUIs.

Today the MVC pattern is used for modern web applications because it allows the application to be scalable, maintainable, and easy to expand.

Why Should You Use MVC?

Three words: separation of concerns, or SoC for short.

The MVC pattern helps you break up the frontend and backend code into separate components. This way, it's much easier to manage and make changes to either side without them interfering with each other.

But this is easier said than done, especially when several developers need to update, modify, or debug a full-blown application simultaneously.

How to Use MVC

To better illustrate the MVC pattern, I've included a web application that shows how these concepts all work.

My Car Clicker application is a variation of a well-known Cat Clicker app.

Here are some of the major differences in my app:

1. No cats, only muscle cars images (sorry cat lovers!)
2. Multiple car models are listed
3. There are multiple click counters
4. It only displays the selected car

Now let's dive into these three components that make up the MVC architecture pattern.

Model (data)

The model's job is to simply manage the data. Whether the data is from a database, API, or a JSON object, the model is responsible for managing it.

In the Car Clicker application, the model object contains an array of car objects with all the information (data) needed for the app.

It also manages the current car being displayed with a variable that's initially set to null.

const model = {
    currentCar: null,
    cars: [
        {
            clickCount: 0,
            name: 'Coupe Maserati',
            imgSrc: 'img/black-convertible-coupe.jpg',
        },
        {
            clickCount: 0,
            name: 'Camaro SS 1LE',
            imgSrc: 'img/chevrolet-camaro.jpg',
        },
        {
            clickCount: 0,
            name: 'Dodger Charger 1970',
            imgSrc: 'img/dodge-charger.jpg',
        },
        {
            clickCount: 0,
            name: 'Ford Mustang 1966',
            imgSrc: 'img/ford-mustang.jpg',
        },
        {
            clickCount: 0,
            name: '190 SL Roadster 1962',
            imgSrc: 'img/mercedes-benz.jpg',
        },
    ],
};

Views (UI)

The view's job is to decide what the user will see on their screen, and how.

The Car Clicker app has two views: carListView and CarView.

Both views have two critical functions that define what each view wants to initialize and render.

These functions are where the app decides what the user will see and how.

carListView

const carListView = {
    init() {
        // store the DOM element for easy access later
        this.carListElem = document.getElementById('car-list');

        // render this view (update the DOM elements with the right values)
        this.render();
    },

    render() {
        let car;
        let elem;
        let i;
        // get the cars to be render from the controller
        const cars = controller.getCars();

        // to make sure the list is empty before rendering
        this.carListElem.innerHTML = '';

        // loop over the cars array
        for(let i = 0; i < cars.length; i++) {
            // this is the car we've currently looping over
            car = cars[i];

            // make a new car list item and set its text
            elem = document.createElement('li');
            elem.className = 'list-group-item d-flex justify-content-between lh-condensed';
            elem.style.cursor = 'pointer';
            elem.textContent = car.name;
            elem.addEventListener(
                'click',
                (function(carCopy) {
                    return function() {
                        controller.setCurrentCar(carCopy);
                        carView.render();
                    };
                })(car)
            );
            // finally, add the element to the list
            this.carListElem.appendChild(elem);
        }
    },
};

CarView

const carView = {
    init() {
        // store pointers to the DOM elements for easy access later
        this.carElem = document.getElementById('car');
        this.carNameElem = document.getElementById('car-name');
        this.carImageElem = document.getElementById('car-img');
        this.countElem = document.getElementById('car-count');
        this.elCount = document.getElementById('elCount');


        // on click, increment the current car's counter
        this.carImageElem.addEventListener('click', this.handleClick);

        // render this view (update the DOM elements with the right values)
        this.render();
    },

    handleClick() {
        return controller.incrementCounter();
    },

    render() {
        // update the DOM elements with values from the current car
        const currentCar = controller.getCurrentCar();
        this.countElem.textContent = currentCar.clickCount;
        this.carNameElem.textContent = currentCar.name;
        this.carImageElem.src = currentCar.imgSrc;
        this.carImageElem.style.cursor = 'pointer';
    },
};

Controller (Brain)

The controller's responsibility is to pull, modify, and provide data to the user. Essentially, the controller is the link between the view and model.

Through getter and setter functions, the controller pulls data from the model and initializes the views.

If there are any updates from the views, it modifies the data with a setter function.

const controller = {
    init() {
        // set the current car to the first one in the list
        model.currentCar = model.cars[0];

        // tell the views to initialize
        carListView.init();
        carView.init();
    },

    getCurrentCar() {
        return model.currentCar;
    },

    getCars() {
        return model.cars;
    },

    // set the currently selected car to the object that's passed in
    setCurrentCar(car) {
        model.currentCar = car;
    },

    // increment the counter for the currently-selected car
    incrementCounter() {
        model.currentCar.clickCount++;
        carView.render();
    },
};

// Let's goooo!
controller.init();

MVC Frameworks

JavaScript has grown in popularity, and it's taken over the backend in recent years. More and more full-blown JavaScript applications have opted for the MVC architecture pattern in one way or another.

Frameworks come and go, but what has been constant are the concepts borrowed from the MVC architecture pattern.

Some of the early frameworks that applied these concepts were KnockoutJS, Django, and Ruby on Rails.

Conclusion

The most attractive concept of the MVC pattern is separation of concerns.

Modern web applications are very complex, and making a change can sometimes be a big headache.

Managing the frontend and backend in smaller, separate components allows for the application to be scalable, maintainable, and easy to expand.

If you want to take a look at the Car Clicker app, the code is available on GitHub or checkout the live version here.

🌟Thank you for reading this far!🌟

I wanted to test my limits as a young designer by improving the user experience of Clubhouse, the hottest new audio conversation app on the social media scene.

After speaking with both power users and novices on the app, I uncovered some specific pain points with wayfinding and discoverability in the app. These became the primary design challenges that guided my work throughout this project.

Onboarding Mockups

Disclaimer: I do not work for Clubhouse, and the views in this case study are strictly my own.

As a budding designer, I acknowledge that my vision for this project may be overly ambitious and at times reliant on assumptions of business goals and user data.

In a perfect world, I’d be working alongside the Clubhouse team with direct access to these resources to guide my work. Until then, this case study is meant to be an exploratory learning experience on a product I deeply admire.

The Brief

It’s difficult to understate the excitement around Clubhouse, the audio chat app where members can move around virtual rooms discussing topics ranging from culture to politics.

The app raised its first $100 million with only 1,500 users a month after its beta release. And at the time of this writing, Silicon Valley’s buzziest app has just been valued at $1 billion dollars, a mere 9 months after taking off and before even launching to the public.

Beyond its success with investors, Clubhouse has amassed a fiercely loyal user base, whose creativity has spanned from a 24-hour continuous room dedicated to new user onboarding to a live production of The Lion King.

As an early beta user on the invite-only platform, I had the unique perspective of following the product’s updates (and exponential success) in real-time. And I sought to challenge myself with my most ambitious project yet: redesigning Silicon Valley’s most exciting app in recent memory. No pressure.

The high-level goals of this project were:

• Improving discoverability within Clubhouse, allowing users to more easily find new rooms, people, and clubs to engage with
• Creating a more seamless Hallway experience, where users can filter and find the most relevant rooms to them

UX Challenges: Simplifying a complex information hierarchy

One of the main considerations I had to take into account was the hierarchy of the main components users can interact with inside the app:

• People (other users of the app)
• Rooms (a virtual meeting place for audio conversations), and
• Clubs (interest-based groups that rooms can be hosted under).

Beyond this, I had to consider how each of these components were connected, both interpersonally and through time.

Currently, a Clubhouse user’s Hallway (home screen) shows live rooms connected to the people and clubs they follow (which I’ll refer to throughout this case study as “in-network”). This makes it difficult for users to easily keep track of upcoming rooms in their network, as well as join new, out-of-network rooms.

This became a major dichotomy throughout my work: I needed to find a balance between making each of these individual parts of Clubhouse easily discoverable while maintaining – and simplifying – the web that weaves them together.

Discovery task flow

Mind map of the relationship between Clubhouse components

Research + Planning: A UX Researcher’s Dream

Another unique aspect of this project was the direct access beta users have to the Clubhouse founders, Paul Davison and Rohan Seth. Every Sunday, the pair host Clubhouse Townhall, an open forum where they share the week’s latest product updates, their upcoming roadmap, business goals, and top priorities, as well as holding space for user-submitted Q&As.

And thanks to Clubhouse’s enthusiastic user base, the official Townhalls are regularly followed by Townhall recap rooms (shoutout to Community Club), where power users would deep dive into the week’s updates and what features they’re most excited for.

Between Clubhouse Townhalls, recap rooms, and both official and community-run new member onboarding rooms (including FAQs, Q&As, and discussions), I spent on average 5 hours a week for 6 weeks gaining as many business insights and goals as I possibly could from my limited vantage point.

A compilation of some of the rooms that became a regular part of my UX Research

From these discussions, the overarching goals of the Clubhouse team are:

• Making Clubhouse accessible for everyone: Paul always made it clear that the team’s top priority was to scale Clubhouse as quickly as possible while not sacrificing quality
• Putting creators first: another point Paul never understated was the team’s prioritization of the platform’s creators, building tools that would allow for creator monetization
• Improving discoverability and suggested content: at the time of this project, Clubhouse was actively building out their topics directory and algorithms that would make finding relevant rooms progressively easier

Early sketches of how different screens might behave

User Interviews, from power users to newbies

I spoke with Clubhouse users — both power users and more casual community members — to uncover friction points they currently had with the app’s discovery experience. These interviews showed gave me the following insights:

• Keep it lightweight: most users preferred room discovery to be a spontaneous experience, not necessarily wanting to schedule upcoming rooms in their personal calendars
• Cluttered Hallway: most users were confused by how the hallway was currently curated, and who of the people they followed were in any given room present
• Hallway as a source of discovery: despite the cluttered hallway experience, most users still relied on the hallway to find new rooms, despite there being an existing (but not yet robust) “Explore” tab
• Friends first: when deciding which rooms to join in the hallway, users unanimously wanted to see which of their friends were in any given room

Affinity map of my user interviews (made using Evolve)

So how might we make the Hallway a clear and concise place for spontaneous interaction, while facilitating lightweight out-of-network discovery?

UX Solution: Streamlining the Discovery-to-Hallway pipeline

I developed a simple yet powerful UI that makes wayfinding within your hallway and rooms easier. It also makes bringing rooms found through the discover page into your hallway a breeze.

In order for this solution to feel cohesive and not siloed, I needed to implement a near-full redesign of Clubhouse, broken up into 5 main experiences.

Play with the final prototype here.

Early Wireframes

Experience 1: The Hallway

The Clubhouse Hallway currently (left), and reoptimized for more functionalities and access to controls (right)

Users wanted their hallway experience to feel more intentional and within their control. To achieve this, I established a top-level hierarchy of:

• ongoing vs. upcoming, to allow users to not only see active rooms but get a quick overview of scheduled rooms within their network
• filters by topics of interest, selected by the user during onboarding, and
• sort rooms in your hallway by people vs clubs you follow

An additional UI decision was to only present people you follow within the rooms in your hallway. This would alleviate the current issue of ambiguity surrounding the names users currently see in the room cards in their hallways.

Navigating the reimagined Hallway

Experience 2: Room preview

Room preview in action, where users can see a full list of which friends are inside any given room

Currently in Clubhouse, clicking on a room in a hallway immediately drops you into that room’s conversation.

Since identifying friends in any given room was a high decision factor for users joining a room, I wanted to design a way for users to see whom they know inside before committing to join.

Experience 3: Discovery

Clubhouse’s Explore tab currently (left), and redesigned as an immersive discovery experience (right)

Currently, discovery in Clubhouse is siphoned: users go to the Explore tab to discover people and clubs by categories and keywords, and they go to the calendar tab to discover both active and upcoming rooms across all of Clubhouse.

Bringing a room to your hallway via Clubhouse’s Calendar tab currently (left), and reimagined as a simple bottom sheet function (right)

Most participants actually didn’t use these tabs to achieve their primary goal of discovery. Instead, they adopted workarounds such as discovering clubs through user profiles, discovering people through rooms, and discovering rooms primarily through their hallway, limiting the scope of content they were being exposed to.

An immersive discovery experience with rich filter and sort options

While I designed UI solutions to make these workarounds more seamless, I wanted the discover page to be the go-to destination to accommodate for all these use cases, allowing users to search for people, clubs, and rooms by Clubhouse’s growing topics directory, in addition to keywords.

I also integrated an additional sort functionality to further facilitate discovery.

Sending an out-of-network room to your Hallway

Users also wanted an easy, lightweight solution to discover and access out-of-network rooms.

The ability to send a room from the discover feed to your hallway without committing to following that room’s moderators, corresponding club, or scheduling in your personal calendar was the biggest challenge of this project, involving many iterations in order to feel intuitive.

Experience 4: Active Users

Clubhouse “Available to Chat” flyout currently (left), and reimagined as an “Online Now” tab (right)

A close cousin to the hallway, your active users screen is where all your Clubhouse people and clubs that are currently online live. 83% of users interviewed mentioned scanning this screen to quickly identify what rooms their friends were in.

I added a much-requested search bar to further facilitate friend-finding, as well as a sort drop-down menu to reach an even more important distinction: who’s actively participating in a room vs. just listening in.

Discovering active users by different sort options

Experience 5: User and Club Profiles

Clubhouse User Profiles currently (left), and after consolidating clubs as one metric (right)

87% of users discover suitable clubs to follow via user profiles directly. There exists a further hierarchy within clubs: followers (who receive notifications and see club-branded rooms in their hallway), and members (who, in addition to the above, can also start club-branded rooms themselves).

In Clubhouse’s current design, the clubs a user follows vs. clubs a user is a member of are in disparate locations: in the user’s following list and at the bottom of their user profile, respectively. This was confusing to users wanting scan all the clubs associated with a particular person.

Navigating both User and Club Profiles

By making clubs associated with a user a consolidated metric, users visiting that profile can more easily see what clubs that person belongs to, and immediately follow without visiting a new screen.

On the club level, being able to access metadata such as previously held rooms, upcoming rooms, and club admins can help a user get a more effective overview of the club.

UI & Branding: A Case for Dark UI

In bringing all the pieces of this experience together, it became clear that adding too many visual elements would disrupt the visual hierarchy needed to move through the app with ease.

Additionally, the typical user experience on Clubhouse is already so immersive and emotive, often spanning all hours of the night — I wanted to take advantage of this use case and implement an elegant UI that emphasized Clubhouse’s few content types harmoniously.

A snippet of the Style Guide that guided my work

Usability Testing: How effectively is findability and discoverability throughout the app?

After conducting my usability tests, I created an affinity map with insights, behaviors, and findings during the tests.

Most users moved through the app with little to no missteps, but for many participants, there was one main point of friction that disrupted a key pillar of this redesign:

It was still unclear how to access a room you saved from the Discovery page to your Hallway.

Usability Testing Insights & Priority Changes

Initially, I designed for upcoming out-of-network rooms found in the discover tab to appear in the hallway by the user starring the room. These would then appear in your hallway algorithmically, further discoverable via the “sort by” drop-down menu. There were a few problems with this:

• The original design essentially treated these rooms as saved items, which inadvertently (and incorrectly) prioritized these rooms over other rooms found in your hallway
• This treatment could have greater implications of disincentivizing spontaneous room creation, or unfairly prioritizing out-of-network rooms in general
• Beyond this, embedding a saved item in a sort drop-down wasn’t intuitive or an expected place to find this type of content

Setting notifications on the room, club, and user level

Conclusion: Lessons learned & where we go from here

Going into this project, I knew this would be an ambitious challenge for a young designer. What I didn’t know was just how intricate and all-encompassing that challenge would be.

I learned that working on a highly publicized and highly beloved product comes with a lot of external pressure and internal emotions to do right by (seemingly) everyone.

There are the power users with fierce attachment to existing structures, and new users who can’t fully experience the nuance of an audio app as a static prototype.

Then there's the small but mighty Clubhouse team, who are actively iterating their product on a weekly basis, potentially launching imaginative solutions themselves for the same challenges I’m working on. And even others I haven’t imagined yet.

Against a constant stream of public conversation over an exciting product that felt almost ethereal, I’ll humbly admit that there were times where this pressure got the best of me and I felt like a total imposter who bit off way more than she could ever chew.

The biggest lessons this project taught me were the delicate balance between perseverance when faced with complex challenges, grace in the wake of perceived failure, and when to be okay with “good enough” (for this iteration, of course).

In the end, I’m extremely proud of what I was able to accomplish with this project at this stage in my design journey. And I often reminded myself of my favorite mantra that led me to product design in the first place:

“All I wanted was a job like a book so good I’d be finishing it for the rest of my life.”

Product design is that job for me, and I’m proud to say that while this project (and all my others) will never be fully finished, I breathed as much life into it as I could — I hope you enjoyed it!

Sketch has long been the application of choice for UX and UI designers. But in the last four years, we have seen many new contenders for Sketch’s crown. Three of them that have made the biggest strides are Figma, Adobe XD, and InVision Studio.

These four tools have many pros in common but there are some differences too. For example, the first comparison, Adobe XD vs Sketch, makes sense especially since both have a similar interface which is user-friendly and has a minimalistic style.

In this article, I analyze how the most used design apps compete and what their unique features are using my experience acquired while working at Creative Tim.

Adobe XD

Adobe XD was developed and published by Adobe Inc. XD, released on 18 October 2017. It is a vector-based user experience design tool for web apps, mobile apps, and voice apps available for macOS and Windows. There are versions for iOS and Android as well that help you preview the result of your work directly on mobile devices.

XD also support website wireframing and creating simple interactive click-through prototypes. With the character and layout tools of Adobe XD, Elements can be easily created and individual objects can be exported.

The interface is kept relatively simple, with a toolbar that is aligned at the side, as well as the large artboard area.

Comparing Adobe XD vs Sketch makes sense especially because of this similar interface which is user-friendly and has a minimalistic style.

Sketch

Sketch is a vector graphics editor, developed by the Dutch company Bohemian Coding. Sketch was first released on 7 September 2010 for macOS. It won an Apple Design Award in 2012.

A key difference between Sketch and other vector graphics editors is that Sketch does not include print design features. Sketch is only available on macOS. This problem is partially solved by third party and handoff tools.

When Sketch first came out it completely disrupted the interface design space, but Adobe XD and Figma have recently come forward as new challengers. They offer unique functionality like prototyping and live collaboration.

I’ve recently been researching these tools for my side project, uxtools.co, and wanted to share what I believe the be the most noteworthy decision points. Also, from my point of view, learning to sketch is very useful and it does not take to much to become a Pro.

Figma

Figma came to the stage in 2016 with initial funding of $14M.

With its seamless user interface and sleek feature palette, the tool quickly became a notorious competitor to similar solutions in the field.

Designers from brands like Twitter, Microsoft, GitHub, and Dropbox swear by Figma as the ultimate UI design tool.

InVision Studio

InVision Studio is a new piece of software, released in 2019, that allows designers to build more advanced animation and micro-interactions. Studio also integrated with InVision’s link to Sketch via its Craft plugin.

InVision Studio has got a nice dark UI by default, that helps developers focus on the work to be done in the evening. However, with macOS Mojave, every app can look like this quite easily. When they created it, they were inspired by another design tool - I am thinking about the Sketch app.

Apps Comparison

1. Pricing

Budget can be a big deal when you’re working with your own resources. Some of these licenses have educational and promotional pricing (often 50% off), so don’t miss that part. For example, Figma will get you there for free as long as you're not working on a team.

• Figma: Free for individuals! You can have 3 projects for free, or you can upgrade to unlimited projects and team functionality for $12/month (billed annually).

• Sketch: $99 per license that gets you the Mac App for life and access to the next production versions of the app.

• Adobe XD: It offers free and paid plans, depending on an individual's or team's needs. Paid plans start at $9.99/month.

• InVision Studio: Free right now.

2. Platform

Though Sketch has been immensely popular, it forces designers to only use Mac, which alienates developers from accessing design files.

• Figma: Browser! Figma recently released a Mac app and Windows app (not offline-capable, though).

• Sketch: Mac only.

• Adobe XD: Mac and Windows. Subject to the same limitations as the CC suite.

• InVision Studio: Mac and Windows.

3. Live Collaboration

Nobody likes to send at the end of the day “version 3.0”, “version3.0.final”, “version3.0.final.final”. Live Collaboration can help us, especially live comments.

I imagine these were the same concerns that surrounded the release of the highly innovative Google Docs suite. Google Docs, however, turned the Microsoft Suite on its head with live collaboration, and now Figma is seeking to do the same thing with UI design.

• Figma: Yes! Not to mention being browser-based, it allows Windows and even Linux users to have a very polished design tool.

• Sketch: Not natively, but a plugin, Picnic, is looking to change that. Also, they have Sketch for Teams.

• Adobe XD: It offers real-time Coediting, launched at Adobe MAX 2019.

• InVision Studio: Not currently possible, but can generate share links.

Image: Figma - Argon Design System Pro

4. Handoff

Recently a few apps have been developed specifically to deliver specs (sizing, spacing, color) to developers, but design tools are starting to integrate this functionality natively.

• Figma: Because of live collaboration, developers can easily jump in (regardless of OS) and access the designs. Figma now neatly prints the handoff code for CSS, iOS, or Android in the right panel.

• Sketch: They've recently launched their own native developer handoff feature — Cloud Inspector. There’s even an entirely free alternative called Sketch measure that works just as well.

• Adobe XD: It offers design specs that allow a designer to create a shared link that contains measurements, assets, and automatically-generated CSS code snippets.

• InVision Studio: They have “Inspect Now”.

Image: Figma - Argon Design System Pro

5. Offline

This is so important. Some online apps can protect your information when Wifi goes down, but you need full access to open, use, and save from the app offline.

• Figma: No, in an AMA they stated they don't have any current plans to add it.

• Sketch: Sure.

• Adobe XD: Yep.

• InVision Studio: Yes.

Image: AdobeXD - Argon Dashboard Free

6. Prototyping

There are literally dozens of these apps nowadays, but they might become extinct as Adobe XD brings prototyping directly to the design tool. Keep your eye on these.

• Figma: Yes! It's very basic but feels like Adobe XD without the transitions. Also, there's a nice Framer integration.

• Sketch: Yes!

• Adobe XD: Yes, native prototyping within the app. Adobe XD also supports voice prototyping and keyboard/gamepad support.

• InVision Studio: Yes, you can create prototypes and animations.

Image: InVision Studio - Argon React Native

7. Symbols

Symbols can make your work easier. These have completely changed the design process. Forget building and duplicating list items over and over, let symbols do the work for you.

• Figma: Good to go. Symbols now have states, constraints, and overrides.

• Sketch: The symbol functionality in Sketch is very impressive, and continues to improve. Symbols can be updated across entire documents and can resize responsively (that means less work for you when changing screen sizes).

• Adobe XD: It offers components that can be used throughout a document as well as linked across documents. It also allows designers to create variations of a component for different interactions, known as component states.

• InVision Studio: they have components that are a close approximation to the symbol conventions found in other applications. Components in their final form will honor a broad, scalable hierarchy that allows designers to quickly build-up, mix, and match components intelligently across their designs.

Image: Sketch - Material Kit Pro

Conclusion

Sketch has a big disadvantage here because it is only available for Mac users. And as such, it lets tools like Figma and Adobe XD innovate beyond the basic necessities.

Also, in terms of design tools, Adobe XD provides a robust set of responsive while the Sketch doesn’t have this feature built-in (but it has many plugins). If your tool does something better than the other, it is often enough of a reason to switch over. The browser-based approach that Figma has taken is also something to behold.

When talking about Adobe XD vs Sketch, the first one’s future is looking very bright and will win over many Sketch users. InVision’s change of focus may ensure its survival but one thing is for certain - Adobe XD is here to stay. The Adobe powerhouse is strong, and smaller companies like InVision and Sketch will have to work hard to stay relevant in the future.

People usually prefer to design and work in just one place. If you’re a part of a team, then Figma is undoubtedly for you.

After all of that: first is Figma, second is Sketch, third is Adobe XD and fourth is InVision Studio.

Overall, when talking about the best design software, these four tools are extremely well-suited for modern designer needs.

Try all four out to see which one is better for your use cases. I hope this comparison - Adobe XD vs Sketch vs Figma vs InVision - helped you decide which design tool is better for you.

Resources:

https://www.figma.com/figma-vs-sketch/

https://uxtools.co/blog/sketch-vs-adobe-xd-vs-figma/

https://www.codeinwp.com/blog/figma-vs-sketch-vs-adobe-xd/

https://support.invisionapp.com/hc/en-us/sections/360004450191-Studio

https://helpx.adobe.com/ro/xd/help/components.html

https://www.sketch.com/docs/

I was at a software craftsmanship meetup recently, where we formed pairs to solve a simplified Berlin Clock Kata. A Berlin Clock displays the time using rows of flashing lights, which you can see below (although in the kata we just output a text representation, and the lights in a row are all the same colour).

Initial Test Driven solution

Most pairs used inside out TDD, and there were a lot of solutions that looked something like this (complete code available on GitHub).

def berlin_clock_time(julian_time):
    hours, minutes, seconds = list(map(int, julian_time.split(":")))

    return [
        seconds_row_lights(seconds % 2)
        , five_hours_row_lights(hours)
        , single_hours_row_lights(hours % 5)
        , five_minutes_row_lights(minutes)
        , single_minutes_row_lights(minutes % 5)
    ]

def five_hours_row_lights(hours):
    lights_on = hours // 5
    lights_in_row = 4
    return lights_for_row("R", lights_on, lights_in_row)

# ...

This type of solution drops out naturally from applying inside out TDD to the problem. You write some tests for the seconds row, then some tests for the five hours row, and so on, and then you put it all together and do some refactoring. This solution does expose some of the domain concepts at a glance:

• There are 5 rows
• There is one second row, 2 hour rows and 2 minute rows

Some more concepts are available after a bit of digging, but aren't immediately obvious. The rows are made up of lights that can be on (or presumably off), and that the number of lights on is an indication of the time.

However there are some big parts of the problem that are not exposed. And since I haven't yet explained it, you probably don't know exactly how the Berlin Clock works yet.

Elevate the concepts

To improve this we can bring some of the details that are buried in the helper functions (such as get_five_hours) closer to the top of the file. This brings you to something like the following (complete code available on GitHub), although the downside is that it breaks nearly all of the tests. Solutions like this are rarer on GitHub, but do exist.

def berlin_clock_time(julian_time):
    hours, minutes, seconds = list(map(int, julian_time.split(":")))

    single_seconds = seconds_row_lights(seconds % 2)
    five_hours = row_lights(
        light_colour="R",
        lights_on=hours // 5,
        lights_in_row=4)
    single_hours = row_lights(
        light_colour="R",
        lights_on=hours % 5,
        lights_in_row=4)
    five_minutes = row_lights(
        light_colour="Y",
        lights_on=minutes // 5,
        lights_in_row=11)
    single_minutes = row_lights(
        light_colour="Y",
        lights_on=minutes % 5,
        lights_in_row=4)

    return [
        single_seconds,
        five_hours,
        single_hours,
        five_minutes,
        single_minutes
    ]

# ...

This improves the concepts that are now exposed at a glance:

• There are 5 rows
• The seconds row is a special case
• There are 2 hour rows and 2 minute rows
• The rows use different colour lights
• The rows have a different number of lights

This is pretty good, and is already better that most of the solutions out there. However, it's still a bit mysterious how the rows are related to each other (there are 2 rows to display the hours and the minutes, so presumably these are linked). It's also not obvious what amount of time each light represents.

Name implicit concepts

At the moment some of the concepts (such as the amount of time each light represents) are implicit in the code. Making these explicit, and naming them, forces us to understand them and to embed that understanding in the code.

In order to make the amount of time each light represents explicit, it seems like it would be sensible to pass a time_per_light value to row_lights. This means we have to push the calculation of lights_on down into row_lights.

This in turn makes it obvious that there are two kinds of rows: one related to the quotient (\\) of the time value, and one related to the remainder / modulus (%). If we look at the quotient case, we see that the 2nd parameter to the operation is the time_per_light, which is 5 in both cases (5 hours in one case and 5 minutes in the other).

This allows us to write these rows like this:

five_hour_row = row_lights(
    time_per_light=5,
    value=hours, 
    light_colour="R",
    lights_in_row=4)

If we now turn our attention to the remainder case, we realise that time_per_light is always singular (one hour or one minute), as it is filling in the gaps in the quotient case.

For example, the five hours row can represent 0, 5, 10, 15, or 20 hours, but nothing in between. In order to represent any hour, there must be another row to represent +1, +2, +3 and +4. This means that this row must have exactly 4 lights, and that each light must represent 1 hour.

This implies that the remainder case is dependent on the quotient one, which most people would describe as a parent / child relationship.

With this knowledge in hand, we can now create a function for the child remainder rows, and the solution now looks like this (complete code on GitHub):

def berlin_clock_time(julian_time):
    hours, minutes, seconds = list(map(int, julian_time.split(":")))

    return [
        seconds_row_lights(
            seconds % 2),
        parent_row_lights(
            time_per_light=5,
            value=hours, 
            light_colour="R",
            lights_in_row=4),
        child_remainder_row_lights(
            parent_time_per_light=5,
            value=hours,
            light_colour="R"),
        parent_row_lights(
            time_per_light=5,
            value=minutes, 
            light_colour="Y",
            lights_in_row=11),
        child_remainder_row_lights(
            parent_time_per_light=5,
            light_colour="Y",
            value=minutes)
    ]

# ...

A quick glance at this code now reveals nearly all the domain concepts

• The first row represents the seconds and is a special case
• On the second row each "R" light represents 5 hours
• The third row shows the remainder from the second
• On the fourth row each "Y" light represents 5 hours
• The fifth row shows the remainder from the fourth

This took something thinking about, which will have cost us some time / money. But we increased our understanding of the problem while we did it, and most importantly we embedded that knowledge in to the code. This means that the next person to read the code will not have to do this, which will save some time / money. Since we spend about 10 times longer reading code than we do writing it, this is probably a worthwhile endeavour.

Embedding this understanding has also made it harder for future programmers to make mistakes. For example, the concept of parent / child rows didn't exist in earlier examples, and it would be easy to mismatch them. Now the concept is plain to see, and the values are mostly worked out for you. It is also easier to refactor to support new clock variants, for example where lights in the first hours row represent 6 hours.

How far should you take it?

There are things we can do to take this further. For example the parent_time_per_light of a child row must match the time_per_light of its parent, and there is nothing enforcing this. There is also a relationship between time_per_light and lights_in_row for the parent rows, and again it is not enforced.

However, at the moment we are only required to support one clock variant, so these probably aren't worth doing. When a change is required for the code, we should refactor so that the change is easy (which might be hard) and then make the easy change.

Conclusions

Embedding domain concepts in code requires thought and skill, and TDD won't necessarily do it for you. It takes longer than a naive solution, but makes the code easier to understand, and will very likely save time in the medium term. Time is money, and finding the right balance of spending time now versus saving time later is also an important skill for a professional programmer to have.

This is usually a fertile breeding ground for bugs born out of miscommunication / misunderstanding, and fixing these bugs often introduces new ones, for the same reasons. In the end it becomes code that no one really understands or wants to touch.

Example of undescribable code

It is easy to think that code is already a written language. If it looks simple, it should be easy to read, speak and listen to. However, this is not always the case.

Below is a common solution to deciding whether a year is a leap year.

(divisibleBy(4) and not divisibleBy(100)) or divisibleBy(400)

This is not overly complicated code. It calls a functions 3 times, has 3 operators (and, or, not), and has two levels of nesting.

However, if you take a second to try and describe the algorithm in words I think you will find it to be a struggle.

Maybe “A year is leap year if it is divisible by 4 and not divisible by 100, or divisible by 400”?

The trouble with this is that the code has brackets, but the words do not. So they cannot adequately describe the condition, and whether “or divisible by 400” applies to “divisible by 4” or “not divisible by 400”. You could try some hand waving and gesturing to get around this, or vary the length of pause between the statements, but hopefully it’s obvious that there is a lot of potential for error.

Refactoring to describable code

Instead we can start by describing the condition with words, and then make the words as clear and concise as possible. We might start with this:

“400 years is a special case. If a year is divisible by 400, then it is a leap year. 100 years is also a special case. If a year is divisible by 100 then it isn’t a leap year, unless it is also divisble by 400, the 400 year special case takes priority. If there are no special cases, then the year is a leap year if it is divisible by 4.”

This is clear, but isn’t concise, so we would probably want to shrink it a bit:

“If a year is divisible by 400, then it is a leap year. Otherwise if it is divisible by 100 then it is a normal year, otherwise it is a leap year if it is divisible by 4.”

If we turn these words in to code, we probably get something like the following:

    if divisbleBy(400):
        return LeapYear
    elif divisbleBy(100)
        return NormalYear
    elif divisbleBy(4):
        return LeapYear
    else:
        return NormalYear

Conclusions

Hard to understand code is a daily occurrence for virtually all programmers. We can help ourselves and our co-workers by writing code that is easy to describe in words.

And the great thing is that doing so is actually easier than writing code any other way, as there is no mental mapping / wasted mental effort. The only “trick” is to describe the algorithm in words, and then write code to match the words.

In many organisations, the algorithm will already be described in words, as part of acceptance tests or user stories, which will improve productivity even further.

This article is a summary of what I'm writing about in my newest project, solidbook.io - The Handbook to Software Design and Architecture with TypeScript. Check it out it you like this post.

It's crazy to me to consider the fact that Facebook was once an empty text file on someone's computer.

Lol.

This past year, I've been going hard in software design and architecture, Domain-Driven Design, and writing a book on it, and I wanted to take a moment to try to piece it together into something useful I could share with the community.

Here's my roadmap for how to learn software design and architecture.

I've broken it down into two artifacts: the stack and the map.

The Stack

Similar to the OSI Model in networking, each layer builds on top of the foundation of the previous one.

The Map

While I think the stack is good to see the bigger picture of how everything works together, the map is a little bit more detailed (and inspired by the web developer roadmap) and as a result, I think it's more useful.

Here it is below! To fork the repo, read my detailed write-up and download it in high-res, click here.

Stage 1: Clean code

The very first step towards creating long-lasting software is figuring out how to write clean code.

Clean code is code that is easy to understand and change. At the low-level, this manifests in a few design choices like:

• being consistent
• preferring meaningful variable, method and class names over writing comments
• ensuring code is indented and spaced properly
• ensuring all of the tests can run
• writing pure functions with no side effects
• not passing null

Writing clean code is incredibly important.

Think of it like a game of jenga.

In order to keep the structure of our project stable over time, things like indentation, small classes and methods, and meaningful names, pay off a lot in the long run.

The best resource to learn how to write clean code is Uncle Bob's book, "Clean Code".

Stage 2: Programming Paradigms

Now that we're writing readable code that's easy to maintain, it would be a good idea to really understand the 3 major programming paradigms and the way they influence how we write code.

In Uncle Bob's book, "Clean Architecture", he brings attention to the fact that:

• Object-Oriented Programming is the tool best suited for defining how we cross architectural boundaries with polymorhpism and plugins
• Functional programming is the tool we use to push data to the boundaries of our applications
• and Structured programming is the tool we use to write algorithms

This implies that effective software uses a hybrid all 3 programming paradigms styles at different times.

While you could take a strictly functional or strictly object-oriented approach to writing code, understanding where each excels will improve the quality of your designs.

If all you have is a hammer, everything seems like a nail.

Resources

For functional programming, check out:

• Professor Frisby's Mostly Adequate Guide to Functional Programming
• Domain Modeling Made Functional

Stage 3: Object-Oriented Programming

It's important to know how each of the paradigms work and how they urge you to structure the code within them, but with respect to architecture, Object-Oriented Programming is the clear tool for the job.

Not only does Object-Oriented programming enable us to create a plugin architecture and build flexibility into our projects; OOP comes with the 4 principles of OOP (encapsulation, inheritance, polymorhism, and abstraction) that help us create rich domain models.

Most developers learning Object-Oriented Programming never get to this part: learning how to create a software implementation of the problem domain, and locating it in the center of a layered web app.

Functional programming can seem like the means to all ends in this scenario, but I'd recommend getting acquainted with model-driven design and Domain-Driven Design to understand the bigger picture on how object-modelers are able to encapsulate an entire business in a zero-dependency domain model.

Why is that a huge deal?

It's huge because if you can create a mental-model of a business, you can create a software implementation of that business.

Stage 4: Design Principles

At this point, you're understanding that Object-Oriented Programming is very useful for encapsulating rich domain models and solving the 3rd type of "Hard Software Problems"- Complex Domains.

But OOP can introduce some design challenges.

When should I use composition?

When should I use inheritance?

When should I use an abstract class?

Design principles are really well-established and battle-tested object-oriented best practices that you use as railguards.

Some examples of common design principles you should familiarize yourself with are:

• Composition over inheritance
• Encapsulate what varies
• Program against abstractions, not concretions
• The hollywood principle: "Don't call us, we'll call you"
• The SOLID principles, especially the Single responsibility principle
• DRY (Do Not Repeat Yourself)
• YAGNI (You Aren't Gonna Need It)

Make sure to come to your own conclusions, though. Don't just follow what someone else says you should do. Make sure that it makes sense to you.

Stage 5: Design Patterns

Just about every problem in software has been categorized and solved already. We call these patterns: design patterns, actually.

There are 3 categories of design patterns: creational, structural, and behaviour.

Creational

Creational patterns are patterns that control how objects are created.

Examples of creational patterns include:

• The Singleton pattern, for ensuring only a single instance of a class can exist
• The Abstract Factory pattern, for creating an instance of several families of classes
• The Prototype pattern, for starting out with an instance that is cloned from an existing one

Structural

Structural patterns are patterns that simplify how we define relationships between components.

Examples of structural design patterns include:

• The Adapter pattern, for creating an interface to enable classes that normally can't work together, to work together.
• The Bridge pattern, for splitting a class that should actually be one or more, into a set of classes that belong to a hierarchy, enabling the implementations to be developed independently of each other.
• The Decorator pattern, for adding responsibilities to objects dynamically.

Behavioural

Behavioural patterns are common patterns for facilitating elegant communication between objects.

Examples of behavioural patterns are:

• The Template pattern, for deferring the exact steps of an algorithm to a subclass.
• The Mediator pattern, for defining the exact communication channels allowed between classes.
• The Observer pattern, for enabling classes to subscribe to something of interest, and to be notified when a change occurred.

Design pattern criticisms

Design patterns are great and all, but sometimes they can an additional complexity to our designs. It's important to remember YAGNI and attempt to keep our designs as simple as possible. Only use design patterns when you're really sure you need them. You'll know when you will.

If we know what each of these patterns are, when to use them, and when to not even bother using them, we're in good shape to begin to understand how to architect larger systems.

The reason behind that is because architectural patterns are just design patterns blown-up in scale to the high-level, where design patterns are low-level implementations (closer to classes and functions).

Resources

Refactoring Guru - Design Patterns

Stage 6: Architectural Principles

Now we're at a higher level of thinking beyond the class level.

We now understand that the decisions we make towards organzing and building relationships between components at the high-level and the low-level, will have a significant impact on the maintainability, flexibility, and testability of our project.

Learn the guiding principles that helps you build in the flexibility that your codebase needs in order to be able to react to new features and requirements, with as little effort as possible.

Here's what I'd recommend learning right off the bat:

• Component design principles: The Stable Abstraction Principle, The Stable Dependency Principle, and The Acyclic Dependency Principle, for how to organize components, their dependencies, when to couple them, and the implications of accidentally creating dependency cycles and relying on unstable components.
• Policy vs. Detail, for understanding how to separate the rules of your application from the implementation details.
• Boundaries, and how to identify the subdomains that the features of your application belongs within.

Uncle Bob discovered and originally documented many of these principles, so the best resource to learn about this is again, "Clean Architecture".

Stage 7: Architectural Styles

Architecture is about the stuff that matters.

It's about identifying what a system needs in order for it to be successful, and then stacking the odds of success by choosing the architecture that best fits the requirements.

For example, a system that has a lot of business logic complexity would benefit from using a layered architecture to encapsulate that complexity.

A system like Uber needs to be able to handle a lot of real time-events at once and update drivers' locations, so publish-subscribe style architecture might be most effective.

I'll repeat myself here because it's important to note that the 3 categories of architectural styles are similar to the 3 categories of design patterns, because architectural styles are design patterns at the high-level.

Structrual

Projects with varying levels of components and wide-ranging functionality will either benefit or suffer from adopting a structural architecture.

Here are a few examples:

• Component-based architectures emphasize separation of concerns between the individual components within a system. Think Google for a sec. Consider how many applications they have within their enterprise (Google Docs, Google Drive, Google Maps, etc). For platforms with lots of functionality, component-based architectures divide the concerns into loosely coupled independent components. This is a horizontal separation.
• Monolithic means that the application is combined into a single platform or program, deployed altogether. Note: You can have a component-based AND monolithic architecture if you separate your applications properly, yet deploy it all as one piece.
• Layered architectures separate the concerns vertically by cutting software into infrastructure, application, and domain layers.

An example of cutting the concerns of an application vertically by using a layered architecture. Read here for more information on how to do this.

Messaging

Depending on your project, messaging might be a really important component to the success of the system. For projects like this, message-based architectures build on top of functional programming principles and behavioural design patterns like the observer pattern.

Here are a few examples of message-based architectural styles:

• Event-Driven architectures view all signficant changes to state as events. For example, within a vinyl-trading app, a offer's state might change from "pending" to "accepted" when both parties agreee on the trade.
• Publish-subscribe architectures build on top of the Observer design pattern by making it the primary communication method between the system itself, end-users / clients, and others systems and components.

Distributed

A distributed architecture simply means that the components of the system are deployed separately and operate by communicating over a network protocol. Distributed systems can be very effective for scaling throughput, scaling teams, and delegating (potentially expensive tasks or) responsibility to other components.

A few examples of distributed architectural styles are:

• Client-server architecture. One of the most common architectures, where we divide the work to be done between the client (presentation) and the server (business logic).
• Peer-to-peer architectures distribute application-layer tasks between equally-privileged participants, forming a peer-to-peer network.

Stage 8: Architectural Patterns

Architectural patterns explain in greater tactical detail how to actually implement one of those architectural styles.

Here are a couple of examples of architectural patterns and the styles that they inherit from:

• Domain-Driven Design is an approach to software development against really complex problem domains. For DDD to be most successful, we need to implement a layered architecture in order to separate the concerns of a domain model from the infrastrural details that makes the application actually run, like databases, webservers, caches, etc.
• Model-View Controller is probably the most well-known architectural pattern for developing user interface-based applications. It works by dividing the app into 3 components: model, view, and controller. MVC is incredibly useful when you're first starting out, and it helps you piggyback towards other architectures, but there hit's a point when we realize MVC isn't enough for problems with lots of business logic.
• Event sourcing is a functional approach where we store only the transactions, and never the state. If we ever need the state, we can apply all the transactions from the beginning of time.

Stage 9: Enterprise patterns

Any architectural pattern you choose will introduce a number of constructs and technical jargon to familiarize yourself with and decide on whether it's worth the effort to use or not.

Taking an example that many of us know, in MVC, the view holds all the presentation layer code, the controller is translates commands and queries from the view into requests that are handled by the model and returned by the controller.

Where in the Model (M) do we handle these things?:

• validation logic
• invariant rules
• domain events
• use cases
• complex queries
• and business logic

If we simply use an ORM (object-relational mapper) like Sequelize or TypeORM as the model, all that important stuff to gets left to interpretation on where it should go, and it finds itself in some unspecified layer between (what should be a rich) model and the controller.

Taken from "3.1 - Slim (Logic-less) models" in solidbook.io.

If there's something I've learned so far in my journey going beyond MVC, it's that there is a construct for everything.

For each of those things that MVC fails to address, there exist other enterprise patterns to solve them. For example:

• Entities describe models that have an identity.
• Value Objects are models that have no identity, and can be used in order to encapsulate validation logic.
• Domain Events are events that signify some relevant business event occurring, and can be subscribed to from other components.

Depending on the architectural style you've chosen, there are going to be a ton of other enterprise patterns for you to learn in order to implement that pattern to it's fullest potential.

Integration patterns

Once your application is up and running, as you get more and more users, you might run into performance issues. API calls might take a long time, servers might crash from being overloaded with requests, etc. In order to solve these problems, you might read about integrating things like message queues or caches in order to improve performance.

This is probably the most challenging stuff: scaling, audits, and performance.

Designing a system for scale can be incredibly challenging. It requires a deep understanding of the limitations of each component within the architecture, and a plan of action for how to mitigate stress on your architecture and continue to serve requests in high-traffic situations.

The need also the need to audit what's going on in your application. Large enterprise companies need to be able to perform audits in order to identify potential security issues, understand how users are using their applications, and have a log of everything that's ever happened.

This can be challenging to implement, but common architectures end up looking event-based and build upon a wide range of software and system design concepts, principles, and practices like Event Storming, DDD, CQRS (command query response segregation), and Event Sourcing.

I hope that was useful to you!

Let me know if you have any suggestions or questions.

Cheers!

Fork it on GitHub

Read the book on software design & architecture

Read the write-up

khalilstemmler.com - I teach Advanced TypeScript & Node.js best practices for large-scale applications and how to write flexible, maintainable software.

Strap yourself in. In this guide, we compare when it’s absolutely vital to be using TypeScript, the strictly-typed programming language, and when it makes sense to stick to vanilla JavaScript

Have you heard of that little programming language called TypeScript? You know, the one that Microsoft made? The one that’s kinda blowing up?

Maybe you were like me, a true JavaScript purist. I was doing just fine building things with React and Node without types. Prop types and Joi validation have been treating me just nicely, thank you.

Maybe you caved at some point and gave it a shot. Started playing with it. Maybe you hated it because it reminded you of Java. Maybe you got annoyed with how you couldn’t be super productive right away.

These were some of my own initial sentiments when I first started with TypeScript.

I certainly didn’t see the benefit… up until I started experiencing some really annoying stuff. Things like builds not failing when they should, buggy code and typos finding their way into production code somehow in addition to finding it increasingly challenging to express my designs in a really clean object-oriented way.

9 months later into using TypeScript, I’ve built new features in Angular apps for clients, I began compiling Univjobs's React / Redux front-end with TypeScript and ported all of our backend services to TypeScript from vanilla Node.js, refactoring mass amounts of code along the way.

In this article, we’ll take a look at some of the most common scenarios and identify when it might be vital to use TypeScript, and when we could probably just do without it and stick to vanilla JS.

Why this discussion matters today more than ever

I’ve come to the very important conclusion that depending on your situation, context, project, skill level, and other factors, that it’s actually dangerous for your project to NOT be using TypeScript today.

The front-end space, for one, is getting more and more complex. Certain features that were once considered bleeding-edge, are now very much standard user experience assumptions.

For example, it’s almost always expected that your app is still going to work offline in some capacity. And when users ARE online, it’s also usually expected that they’re going to get real-time notifications without having to refresh the page.

These are some pretty steep (but definitely not unrealistic in 2019) demands.

Before we dive into different scenarios, we should actually talk about the three categories of really hard software problems to be solved.

3 Categories of Hard Software Problems

Generally speaking, there are three of these. The Performant System Problem, the Embedded System Problem, and the Complex Domain Problem.

1. The Performant System Problem

Let’s talk about Twitter for a sec.

Twitter is actually a really simple concept.

You sign up, you make tweets, you like other people’s tweets and that’s pretty much it.

If Twitter is that simple, why couldn’t someone else do it?

It’s apparent that the real challenge for Twitter is not actually so much as what it does, but it’s how it’s able to do what it does.

Twitter has the unique challenge of serving requests from approximately 500 million users every single day.

The hard problem that Twitter solves is actually a performance problem.

When the challenge is performance, whether or not we use a strictly typed language is much less important.

2. The Embedded System Problem

An embedded system is a combination of computer hardware and software, with the purpose of enabling control over the mechanical or electrical aspects of a system.

Most systems we use today are built on a very complex layer of code that, if not initially written in, compiles down to C or C++ usually.

Coding in these languages is not for the faint of heart.

In C, there is no such thing as objects; and we as humans like objects because we can easily understand them. C is procedural and this makes the code that we have to write in this language more challenging to keep clean. These problems also require knowledge of the lower-level details.

C++ does make life a whole lot better because it has object orientation, but the challenge is still fundamentally interacting with lower-level hardware details.

Because we don’t really have that much of a choice on the languages we use for these problems, so it’s irrelevant to consider TypeScript here.

3. The Complex Domain Problem

For some problems, that challenge is less about scaling in terms of handling more requests, but scaling in terms of the codebase’s size.

Enterprise companies have complex real-life problems to be solved. In these companies, the biggest engineering challenges are usually:

• Being able to logically (domains) separate parts of that monolith into smaller apps. And then, physically (microservices for bounded contexts) splitting them up so that teams can be assigned to maintain them
• Handling integration and synchronization between these apps
• Modeling the domain concepts and actually solving the problems of the domain
• Creating a ubiquitous (all-encompassing) language to be shared by developers and domain experts
• Not getting lost in the mass amounts of code written and slowing down to the point where it becomes impossible to add new features without breaking existing ones

I’ve essentially described the types of problems that Domain-Driven Design solves. For these types of projects, you wouldn’t even think about not using a strictly-typed language like TypeScript.

Object-oriented JavaScript

For Complex Domain problems, if you don’t choose TypeScript and instead, choose JavaScript, it will require some extra effort to be successful. Not only will you have to be extra comfortable with your object modeling abilities in vanilla JavaScript, but you’ll also have to know how to utilize the 4 principles of object-oriented programming (encapsulation, abstraction, inheritance, and polymorphism).

This can be hard to do. JavaScript doesn’t naturally come with concepts of interfaces and abstract classes.

“Interface Segregation” from the SOLID design principles isn’t easily achievable with vanilla JavaScript.

Using JavaScript alone would also require a certain level of discipline as a developer in order to keep the code clean, and this is vital once the codebase is sufficiently large. You’re also left to ensure that your team shares the same discipline, experience and knowledge level on how to implement common design patterns in JavaScript. If not, you’ll need to guide them.

In Domain-Driven projects like this, the strong benefit from using a strictly typed language is less about expressing what can be done, but more about using encapsulation and information hiding to reduce the surface area of bugs by limiting what domain objects are actually allowed to do.

We can live without this on the front-end, but it’s a hard language requirement for the backend in my books. It’s also the reason why I moved my Node.js backend services to TypeScript.

There’s a reason why TypeScript is called “JavaScript that scales”.

Out of all three categories of hard software problems, only the Complex Domain Problem is the one where TypeScript is an absolute necessity.

Besides this, there are other factors that might determine when it’s best to use TypeScript for your JavaScript project.

Code size

Code size usually ties back to the Complex Domain Problem, where a large codebase means a complex domain, but that’s not always the case.

When the amount of code a project has gets to a certain size, it becomes harder to keep track of everything that exists and becomes easier to end up re-implementing something already coded.

Duplication is the enemy to well-designed and stable software.

This is especially heightened when new developers start coding on an already large codebase.

Visual Studio Code’s autocompletion and Intellisense helps to navigate through huge projects. It works really well with TypeScript, but it’s somewhat limited with JavaScript.

For projects that I know will stay simple and small, or if I know that it will be thrown away eventually, I would be less pressed to recommend TypeScript as a necessity.

Production software vs. pet projects

Production software is code that you care about or code that you’ll get in trouble for if it doesn’t work. This is also code that you’ve written tests for. The general rule of thumb is that “if you care about the code, you need to have unit tests for it”.

If you don’t care, don’t have tests.

Pet projects are self-explanatory. Do whatever you like. You have no professional commitment to uphold any standards of craftsmanship whatsoever.

Go on and make things! Make small things, make big things.

Maybe someday you’ll experience the pain when your pet project turns into your main project which turns into production software, which is buggy because it didn’t have tests or types ? not like I’ve been there or anything…

Lack of Unit Tests

It’s not always possible to have tests for everything, because, well — life.

In that case, I’d say that if you don’t have Unit Tests, the next best thing you could have is compile-time checking with TypeScript. After that, if you’re using React, the next best is thing is to use runtime checking with Prop types.

However, compile-time checking is not a substitute for having unit tests. The good thing is that unit tests can be written in any language — so the argument for TypeScript here is irrelevant. What’s important is that tests are written and we are confident about our code.

Startups

Definitely use whatever helps you be most productive.

At this time, the language you choose matters a lot less.

The most important thing for you to do is to validate your product.

Choosing a language (Java, for example) or a tool (like Kubernetes) that you heard would help you scale in the future (while being totally unfamiliar with it) may or may not be the best option in the case of a startup.

Depending on how early you are, the most important thing for you to do is to be productive.

In Paul Graham’s famous article, The Python Paradox, his main point is that startup engineers should just use the technology that maximizes their productivity.

Overall, in this case, use whatever you’re most comfortable with: types or no types. You can always refactor towards a better design once you know you’ve built something people actually want.

Working on Teams

Depending on the size of your team and the frameworks you’re using, using TypeScript might be a make or break kind-of-thing.

Large teams

When teams are sufficiently large (because the problems are sufficiently large), it’s a good reason to use an opinionated framework, like Angular for the front-end, and TypeScript for the backend.

The reason why using an opinionated framework is beneficial is because you limit the number of possible ways for people to accomplish something. In Angular, there’s pretty much one main way to add a Route Guard, use Dependency Injection, hook up Routing, Lazy-Loading, and Reactive Forms.

The huge benefit here is that the API is well specified.

With TypeScript, we also save massive amounts of time and make communication efficient.

The ability to quickly determine the required arguments and its return type for any method, or the ability to explicitly describe program intent through public, private, and protected variables alone is incredibly useful.

Yes, some of this is possible with JavaScript, but it’s hacky.

Communicating patterns & implementing design principles

Not only that, but design patterns, the solutions to commonly occurring problems in software, are more easily communicated through explicit strictly-typed languages.

Here’s a JavaScript example of a common pattern. See if you can identify what it is.

class AudioDevice {
  constructor () {
    this.isPlaying = false;
    this.currentTrack = null;
  }

  play (track) {
    this.currentTrack = track;
    this.isPlaying = true;
    this.handlePlayCurrentAudioTrack();
  }

  handlePlayCurrentAudioTrack () {
    throw new Error(`Subclasss responsibility error`)
  }
}

class Boombox extends AudioDevice {
  constructor () {
    super()
  }

  handlePlayCurrentAudioTrack () {
    // Play through the boombox speakers
  }
}

class IPod extends AudioDevice {
  constructor () {
    super()
  }

  handlePlayCurrentAudioTrack () {
    // Ensure headphones are plugged in
    // Play through the ipod
  }
}

const AudioDeviceType = {
  Boombox: 'Boombox',
  IPod: 'Ipod'
}

const AudioDeviceFactory = {
  create: (deviceType) => {
    switch (deviceType) {
      case AudioDeviceType.Boombox:
        return new Boombox();
      case AudioDeviceType.IPod:
        return new IPod();
      default:
        return null;
    }
  } 
}

const boombox = AudioDeviceFactory
  .create(AudioDeviceType.Boombox);

const ipod = AudioDeviceFactory
  .create(AudioDeviceType.IPod);

If you guessed Factory Pattern, you’re right. Depending on your familiarity with the pattern, it might not have been that obvious to you.

Let’s look at it in TypeScript now. Look at how much more intent we can signify about AudioDevice in TypeScript.

abstract class AudioDevice {
  protected isPlaying: boolean = false;
  protected currentTrack: ITrack = null;

  constructor () {
  }

  play (track: ITrack) : void {
    this.currentTrack = track;
    this.isPlaying = true;
    this.handlePlayCurrentAudioTrack();
  }

  abstract handlePlayCurrentAudioTrack () : void;
}

Immediate improvements

• We know the class is abstract right away. We needed to sniff around in the JavaScript example.
• AudioDevice can be instantiated in the JavaScript example. This is bad, we intended AudioDevice to be an abstract class. And abstract classes shouldn’t be able to be instantiated, they’re only meant to be subclassed and implemented by concrete classes. This limitation is set in place correctly in the TypeScript example.
• We’ve signaled the scope of the variables.
• In this example, currentTrack refers to an interface. As per the Dependency Inversion design principle, we should always depend on abstractions, not concretions. This isn’t possible in the JavaScript implementation.
• We’ve also signaled that any subclasses of AudioDevice will need to implement the handlePlayCurrentAudioTrack themselves. In the JavaScript example, we exposed the possibility for someone to introduce runtime errors trying to execute the method from either the illegal abstract class or the non-complete concrete class implementation.

Takeaway: If you work on a large team and you need to minimize the potential ways someone could misuse your code, TypeScript is a good way to help fix that.

Smaller teams & coding styles

Smaller teams are a lot easier to manage coding styles and communication. Paired with linting tools, frequent discussions about how things will get done and pre-commit hooks, I think small teams can be really successful without TypeScript.

I think that success is an equation involving the size of the codebase and the size of the team.

As the codebase grows, the team might find that they need to rely on some help from the language itself to remember where things are and how they should be.

As the team grows, they might find they need more rules and restrictions to keep the style consistent and prevent duplicate code.

Frameworks

React & Angular

Much of what draws me and other developers to React is the ability to write code however you want and in an elegant/clever way.

It’s true that React makes you a better JavaScript developer because it forces you to approach problems differently, it forces you to be aware of how this binding in JavaScript works and enables you to compose large components out of small ones.

React also allows you to have a bit of your own style. And because of the number of ways I can implement any given task, I will most often write vanilla React.js apps when:

• the codebase is small
• it’s just me coding it

And I will compile it with TypeScript when:

• more than 3 people are coding it, or
• the codebase is expected to be very large

I will also optionally use Angular for the same reason I will compile React with TypeScript.

Conclusion

In conclusion, these are my personal opinions on when TypeScript is absolutely necessary and I welcome you to disagree with any of it.

This is what has worked for me in the past when deciding whether or not to use TypeScript. However, today, since I’ve seen the light, it’s not much more effort for me to use TypeScript over vanilla JavaScript as I’m equally comfortable with both and would prefer the type safety.

My final points here are:

You can always gradually start using TypeScript

Start gradually by adding TypeScript and ts-node to your package.json and utilizing the allowjs: true, option in your tsconfig file.

This is how I migrated all of my Node.js apps over time to TypeScript.

Compile time errors are better than runtime ones

You can’t argue with that. If catching bugs in production code is especially important to you, TypeScript will help you minimize a lot of these.

If you are in a position to learn it, learn it. It does wonders for your software design skills

Depending on where you are in your life and your career, you might not have the time to learn it. If you do have the time, I’d recommend you start learning it and start learning about SOLID design principles and software design patterns. This is the fastest way to level up as a Junior Developer in my honest opinion.

I hope this article was useful to you! Are you considering using TypeScript on your next project? Let me know if you agree/disagree in the comments.

Learn Enterprise TypeScript & JavaScript

Essential software development patterns, principles, and tutorials with modern JavaScript and TypeScript.

Originally published April 6th @ khalilstemmler.com.

Architecture may sound like a “scary ” or overwhelming subject, but actually, applying logic and approaching the problem methodologically simplifies the process drastically.

When you architect a system, service, or feature, you actually design a solution to a problem in a specific context. The solution should answer a real need and solve the problem at hand.

Throughout the text, I’ll be using solution in order to emphasize that the systems, services, and features we build are part of a bigger flow.

When designing a solution think about the entire environment flow you affect.

• Think about what happens before the data reaches your code
• What triggers your feature or service
• Who sends it?
• Is it something automatic?
• Is it a user?

This will also help you think about tests and edge cases you want to address, what happens after, who would use it and how.

1.Understand the problem

Start from understating the problem at hand and understand your boundaries. Don’t optimize for an unknown future, focus on the current situation and most importantly, don’t make assumptions. Don’t limit yourself by requirements that are not there.

Make sure you have all the information you need to understand the problem, don’t be afraid to do research, Google is your friend ;)

_Photo by [Unsplash](https://unsplash.com/@rawpixel?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">rawpixel on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

2. Understand your boundaries and set priorities

Solution architecture is always a trade-off between concerns, such as resilience, security, data integrity, throughput, scalability, performance and of course cost.

Think about value vs friction

Understand your constraints. What are your must-haves. If you have a product team, work with them in order to understand the business need, impact and SLA’s. This will help you understand your considerations and limitations better.

Use data to make priorities, avoid assumptions when possible and be data-driven.

• How many users?
• Number of requests?
• Size of requests?

Test your service in order to estimate the resources that are needed.

Make sure you address the maximum rate you want to support and not only the average (look at percentage vs average).

Think about solving the problem and not just how to solve it. First think about the solution and only after that think about the implementation. When you free yourself from the expectation of how the solution should look like, you understand that a solution can be provided in many forms. It can be a system, service, feature, process or even documentation.

3. Ask WHY?

Challenging people and even yourself can be frustrating sometimes. But asking why can help you solve the real problem, understand the mandatory requirements and your boundaries, and can help you avoid mistakes and understand the motivation from the business side.

• Why is it a real pain?
• Why should it be done like this?
• Why it works like this today?

Challenge yourself and ask questions. It will help make better decisions and better solutions.

_Photo by [Unsplash](https://unsplash.com/@emilymorter?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Emily Morter on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

4. Your solution is not in a vacuum

Context is important. A startup of 4 people that needs to provide MVP and is limited by funds will and should solve a problem differently than a team in a big organization that needs to create a sustainable product that will need to be maintained by several teams.

Going back to my first statement, after you understand the problem think about the context.

• What are the tools you have at your disposal?
• Are you part of a big organization?
• Are there any limitations such as time or money?
• Who will maintain the solution?

Think about what is right for your situation, define what production ready means to you, and whether it should be highly available (HA). Think about the ROI. Should you address Edge cases?

• How would you design a solution that will return values from a database?
• And what if I told you that it would be used only once a week until the end of the year. Would it change your answer? Would it affect the design?
• If you have 1 day to build a solution would it be the same as if you had a month?

Think about growth. For different solutions and different companies, growth means different things. It can be from a scale perspective, such as supporting the growth of additional users. It can also be from a functionality perspective, where your solution should be flexible to enable other developers to add /modify functionality with ease.

5. Cost

As engineers and developers, we sometimes do not stop to think about the cost of our solutions and services. From my experience it is mostly due to lack of awareness and not willingness.

When we are at university, we are “pumped” with performance and complexity concerns, and taught to think about the efficiency of the solution. But when designing a product that will be used, we need to also think about efficiency with regards to cost. You can build an amazing stable and reliable service that provides value, but if its ROI is not high or if your company won’t be able to afford the cost, it will be axed in favor of other alternatives.

Remember, performance and infrastructure are not free.

6. Production deployment is only the beginning

An important concept that sometimes is neglected is maintenance. Is our system or service stable and easy to maintain, debug, troubleshoot and fix?

Production deployment is only the beginning of our solution. Make sure it can be easily maintained, make sure it is production ready and can serve real traffic and users. When developing your solution, think about end to end monitoring, focusing on application monitoring vs. utilization, and make sure to add logging and documentation.

When designing your solution, think about a simple and easy to maintain design, as much as the requirements allow for it of course.

As developers, we are sometimes drawn to new “flashy” and trendy technologies. Stop to think whether this technology is mature enough. Could it be maintained in production? Could a different stack be more efficient or offer fewer risks?

Wrapping up

To recap, if you want to architect the best solution EVER, start from understanding the problem and your limitations, and know the context of the solution you are trying to design for.

Then think about what happens with your solution after it’s up.

Unless you have unlimited funds (which is never the case), think about your solution’s cost and make sure that it maintainable.

If you liked what you read, be sure to ? it below!

Let me know in the comments ❤ if you like more architecture posts and/or would like me to deep dive about each of the points above.

Unlike many other object-oriented programming languages, C++ allows multiple inheritance.

Multiple inheritance allows a child class to inherit from more than one parent class.

At the outset, it seems like a very useful feature. But a user needs to be mindful of a few gotchas while implementing this feature.

In the examples below, we will cover a few scenarios that one needs to be mindful about.

We’ll start with a simple example to explain this concept in C++.

The output of this code is as follows:

I'm breathing as a snake.I’m crawling as a snake.

In the example above, we have a base class named as LivingThing. The Animal and Reptile classes inherit from it. Only the Animal class overrides the method breathe(). The Snake class inherits from the Animal and Reptile classes. It overrides their methods. In the example above, there is no problem. Our code works well.

Now, we’ll add a bit of complexity.

What if Reptile class overrides the breathe() method?

The Snake class would not know which breathe() method to call. This is the “Diamond Problem”.

Diamond Problem

Look at the code below. It is like the code in the example above, except that we have overridden the breathe() method in the Reptile class.

If you try compiling the program, it won’t. You’ll be staring at an error message like the one below.

member ‘breathe’ found in multiple base classes of different types

The error is due to the “Diamond Problem” of multiple inheritance. The Snake class does not know which breathe() method to call.

In the first example, only the Animal class had overridden the breathe() method. The Reptile class had not. Hence, it wasn’t very difficult for the Snake class to figure out which breathe() method to call. And the Snake class ended up calling the breathe() method of the Animal class.

In the second example, the Snake class inherits two breathe() methods. The breathe() method of the Animal and Reptile class. Since we haven’t overridden the breathe() method in the Snake class, there is ambiguity.

C++ has many powerful features such as multiple inheritance. But, it is not necessary that we use all the features it provides.

I don’t prefer using multiple inheritance and use virtual inheritance instead.

Virtual inheritance solves the classic “Diamond Problem”. It ensures that the child class gets only a single instance of the common base class.

In other words, the Snake class will have only one instance of the LivingThing class. The Animal and Reptile classes share this instance.

This solves the compile time error we receive earlier. Classes derived from abstract classes must override the pure virtual functions defined in the base class.

I hope you enjoyed this overview of multiple inheritance and the “Diamond Problem”.