In the vast landscape of software development, writing code is not just about instructing a computer to perform a task; it's about crafting a language that communicates with fellow developers, both present and future. Clean code is the art of writing code that is not only functional but also elegant, efficient, and understandable to others.

Imagine a coach flipping through a playbook where each play is neatly arranged, labeled, and easily accessible. This organized playbook is not just a collection of random strategies but a carefully curated guide to success on the field. With every play clearly defined and structured, the team can execute with precision, knowing exactly what to do in any situation.

In the realm of software development, clean code serves as the playbook for developers. Each line of code is akin to a play in the playbook—purposeful, structured, and easily understandable. When the code base is clean and well-organized, developers can navigate through it seamlessly, making changes and enhancements with confidence.

In this blog, we embark on a journey into the realm of clean code, exploring its principles, practices, and significance in modern software development. Whether you're a seasoned developer looking to refine your craft or a newcomer eager to learn the ropes, join us as we delve into the art of writing code that not only works but also stands the test of time. Let's elevate our programming practices and strive for cleaner, more elegant solutions that not only solve problems but also inspire and empower others.

What is clean code?

Clean code refers to source code that is well-organized, easy to read, and easy to understand. It emphasizes clarity and simplicity, making it easier for developers to maintain, modify, and debug. Clean code is not just about functionality; it's about writing code in a way that minimizes complexity and maximizes readability.

Clean code is not just about whether code works; it's primarily about whether it's easy to read and understand. As developers, we spend a significant amount of time reading and understanding code, whether it's our own past code or code written by colleagues. Clean code prioritizes readability and comprehension to enhance productivity and prevent loss of time. It's crucial for maintaining code bases over time and ensuring their longevity. There's no one-size-fits-all solution for writing clean code, but it's essential for effective software development.

Why is clean code important?

• Readability and Maintainability:-

  Clean code is easier to read and understand, reducing the time and effort required to maintain and modify it. This leads to faster bug fixes, easier feature additions, and smoother code reviews.

• Reduced Technical Debt:-

  Technical debt accumulates when shortcuts are taken or code quality is compromised in favor of quick fixes or tight deadlines. Clean code reduces technical debt by prioritizing long-term maintainability and reducing the cost of future changes.

• Enhanced Collaboration:-

  Clean code improves collaboration among developers by providing a common understanding of how the code works and where to find specific functionality. It also reduces the risk of miscommunication and misunderstandings between team members.

• Improved Productivity:-

  Developers spend a significant portion of their time reading and understanding code. Clean code reduces cognitive overhead and makes developers more productive by allowing them to focus on solving problems rather than deciphering complex code.

• Better Quality Software:-

  Clean code results in better quality software that is more reliable, easier to test, and less prone to bugs and errors. This leads to higher customer satisfaction and a better overall user experience.

In summary, clean code is essential for building maintainable, scalable, and high-quality software applications. It improves readability, reduces technical debt, enhances collaboration, boosts productivity, and ultimately leads to better software outcomes for both developers and end-users.

Properties of clean code

• Readable and Meaningful:-

  Clean code should be easy to understand for other developers who might work on it in the future. This means using descriptive names for variables, functions, and classes, as well as writing clear and concise comments where necessary.

• Reduces Cognitive Load:-

  Clean code minimizes the mental effort required to understand it. This involves breaking down complex tasks into smaller, more manageable components and organizing the code in a logical manner.

• Concise and "To the Point":-

  Clean code gets straight to the point without unnecessary complexity or verbosity. It eliminates redundant or superfluous code, keeping only what is essential for the functionality.

• Avoids Unintuitive Names, Complex Nesting, and Big Code Blocks:-

  Clean code uses meaningful and intuitive names for variables, functions, and classes, making it easier to understand their purpose and usage. It also avoids deep nesting of control structures and large code blocks, which can make code harder to follow and maintain.

• Follows Common Best Practices and Patterns:-

  Clean code adheres to established best practices and design patterns in software development. This includes principles like DRY (Don't Repeat Yourself), SOLID, and others that promote modular, reusable, and maintainable code.

• Well-Tested:-

  Clean code is thoroughly tested to ensure its correctness and robustness. This involves writing unit tests, integration tests, and other forms of automated testing to validate the code's behavior under various conditions.

• Documented When Necessary:-

  Clean code includes appropriate documentation to explain its purpose, usage, and any important considerations for developers working with it. This documentation should be clear, concise, and kept up-to-date as the code evolves.

• Consistent Formatting and Style:-

  Clean code follows a consistent formatting and coding style throughout the code-base. This includes aspects such as indentation, spacing, naming conventions, and so on, which help improve readability and maintainability.

• Performance Considerations:-

  While clean code prioritizes readability and maintainability, it also takes performance into account where necessary. This involves optimizing critical sections of code, avoiding unnecessary overhead, and considering factors like memory usage and algorithmic efficiency.

• Fun to Write and Maintain:-

  Clean code is enjoyable to work with for developers. It's satisfying to write code that is elegant, efficient, and easy to understand, and it's less stressful to maintain code that is well-organized and documented.

By adhering to these principles, developers can produce code that is not only functional but also easy to understand, modify, and extend over time.

Things to be considered

Rules and concepts

• DRY (Don't Repeat Yourself):-

  This principle emphasizes the avoidance of duplicating code. Duplicated code increases the risk of inconsistencies and makes maintenance more difficult. Instead, reusable code should be encapsulated into functions, classes, or modules.

• KISS (Keep It Simple, Stupid):-

  This principle advocates for simplicity in design and implementation. Complex solutions can lead to confusion and bugs, while simpler solutions are easier to understand, debug, and maintain.

• YAGNI (You Ain't Gonna Need It):-

  This principle discourages adding functionality that is not currently needed. Speculative features can bloat the codebase, increase complexity, and introduce unnecessary dependencies. Only implement features that are required by the current requirements.

Patterns & Principles

• Design Patterns:-

  Design patterns are reusable solutions to common problems in software design. Examples include the Singleton pattern, Factory pattern, Observer pattern, etc. These patterns provide proven solutions to recurring design challenges and promote clean, maintainable code.

• SOLID Principles:-

  • S - Single Responsibility Principle

  • O - Open/Closed Principle

  • L - Liskov Substitution Principle

  • I - Interface Segregation Principle

  • D - Dependency Inversion Principle

These principles form the foundation of object-oriented design and promote modular, flexible, and maintainable code.

Test-Driven Development (TDD)

Test-Driven Development is a development approach where tests are written before the code implementation. This follows a cycle of:

1. Write a Test: First, write a test that specifies a desired behavior or feature.

2. Write the Code: Implement the code necessary to make the test pass.

3. Run the Tests: Execute all tests to ensure the new code did not break existing functionality.

4. Refactor: Once the tests pass, refactor the code to improve its structure, readability, and performance while keeping the tests passing.

TDD promotes clean code by ensuring that code is thoroughly tested and that new features are added incrementally while maintaining existing functionality.

Paradigm-specific Considerations

• Functional Programming:-

  Emphasizes immutability, pure functions, and higher-order functions. This paradigm encourages a declarative style of programming, which can lead to cleaner, more concise code with fewer side effects.

• Object-Oriented Programming:-

  Focuses on encapsulating behavior and state within objects. Principles like encapsulation, inheritance, and polymorphism help promote modular design and code reuse.

• Procedural Programming:-

  Prioritizes procedures or functions that perform operations on data. While not as modular as OOP or as declarative as FP, procedural code can still be kept clean by adhering to principles like DRY and KISS, and by organizing code into cohesive functions or modules.

Continuous improvement and refactoring are indispensable practices in our journey towards maintaining a robust and sustainable codebase. While we strive to craft exemplary code from the outset, the iterative nature of software development means that opportunities for enhancement will inevitably arise as our projects evolve. By embracing the ethos that "Refactoring today is the work we save tomorrow," we acknowledge the value of investing time and effort into improving code quality upfront, leading to long-term benefits such as reduced technical debt, increased agility, and enhanced developer productivity.

As a team, we recognize that integrating refactoring into our development workflow is essential for addressing shortcomings and inefficiencies as they emerge, rather than allowing them to accumulate and impede progress. This proactive approach fosters a culture of craftsmanship and quality within our team, promoting collaboration, innovation, and a shared commitment to excellence in software engineering practices.

By continuously refining and optimizing our code, we can mitigate the accumulation of complexity, eliminate redundancy, and adapt more effectively to changing requirements and technological advancements. Through this iterative process of improvement, we not only ensure the resilience and longevity of our software projects but also position ourselves for sustained innovation, competitive advantage, and customer satisfaction in an ever-evolving technological landscape.

Naming

Click here

Comments

Click here

Code Formatting

Click here

Functions/Methods

Click here

Control Structure & Errors

Click here

Classes, Objects and Data Containers

Click here

Key Takeaways

1. Naming:

• Descriptive names: Use nouns for variables and properties, and verbs for methods.

• Specificity: Be as specific as possible without being redundant.

• Consistency: Avoid slang, unknown abbreviations, and maintain consistency in naming conventions.

• Clarity: Make names easy to read and understand by humans.

2. Comments and Formatting:

• Minimal comments: Most comments are discouraged; only include necessary comments like legal information, warnings, or explanations.

• Vertical formatting: Keep related concepts together and separate unrelated ones using blank lines and line breaks.

• Horizontal formatting: Keep lines short, use indentation, and split code across multiple lines for readability.

• IDE assistance: Utilize auto-formatting tools and IDE features to aid in writing clean code.

3. Functions:

• Parameters: Limit the number of parameters and consider grouping them into dictionaries or objects for clarity.

• Function body: Keep functions small and focused on a single task to maintain clarity and avoid repetition.

• Abstraction levels: Ensure consistency between the level of abstraction implied by the function name and its implementation.

• DRY principle: Avoid repeating code and strive for reusability.

• Side effects: Minimize unexpected side effects to enhance code readability.

4. Control Structures:

• Positive wording: Use positive language in control structures for clarity.

• Avoid deep nesting: Utilize guard clauses and extract logic into separate functions to prevent deep nesting.

• Polymorphism and factory functions: Reduce code duplication by employing polymorphism and factory functions.

• Error handling: Use real errors instead of synthetic errors to improve code clarity.

5. Objects and Classes:

• Differentiation: Distinguish between real objects with methods and data structures that only hold data.

• Class size: Keep classes small by focusing on a single responsibility.

• Law of Demeter: Avoid diving too deeply into object hierarchies to maintain code clarity.

• SOLID principles: Follow principles like SRP and OCP to enhance maintainability and improve code readability.

Clean code prioritizes human readability and understanding over mere functionality. By following guidelines for naming, comments, formatting, functions, control structures, and objects/classes, developers can ensure their code is clear, concise, and maintainable. Consistency, clarity, and simplicity are key principles that should guide the writing and organization of code, ultimately leading to better collaboration, easier debugging, and enhanced software quality.

Conclusion

In conclusion, the pursuit of clean code transcends the mere execution of programming tasks; it is an art form, a philosophy, and a commitment to excellence in software development. Throughout this discussion, we have delved into the intricacies of various aspects that constitute clean code, ranging from naming conventions to the principles of object-oriented programming. At its core, clean code is about prioritizing the human experience of reading and understanding code over mere functionality.

Through meticulous naming, minimal yet purposeful comments, and thoughtful formatting, developers create code that is not only functional but also comprehensible to others. By adhering to principles such as modular function design, clear control structures, and object-oriented best practices, clean code fosters readability, simplicity, and maintainability.

In essence, clean code is not merely a set of rules or guidelines; it is a mindset—a commitment to craftsmanship and excellence in software development. As we continue to evolve in our understanding and practice of clean code, let us remain steadfast in our dedication to writing code that not only speaks to machines but also resonates with our fellow humans. For in the end, clean code is not just about computers; it's about people.

Similarly, think of data containers as organized compartments to store your tools. Whether it's a simple list or a custom class, choose the appropriate container based on the complexity and structure of your data. This helps in maintaining data integrity and improves code readability.

Tell, Don't Ask Principle: This principle suggests that instead of asking an object for its state and then making decisions based on that state, we should tell the object to do something. For example, instead of asking a Car object for its speed and then deciding whether to accelerate, we should simply tell the Car to accelerate.

Example:

# Example of a class adhering to SRP
class UserManager:
    def authenticate(self, username, password):
        # Authentication logic
        pass

    def updateUserProfile(self, user_id, new_data):
        # Profile update logic
        pass

# Example of a data container
class Customer:
    def __init__(self, name, email):
        self.name = name
        self.email = email

# Usage
user_manager = UserManager()
customer = Customer("John Doe", "john@example.com")

Cohesion

Maximum Cohesion:

High cohesion means that all methods within a class are closely related and work together to achieve a common goal. This leads to more readable and maintainable code.

Example: In a BankAccount class, methods like deposit, withdraw, and getBalance all directly relate to managing the bank account's balance and transactions.

No Cohesion:

Low or no cohesion occurs when methods in a class are unrelated or don't work together towards a common purpose. This often indicates poor design and can make the code harder to understand and maintain.

Example: A Utilities class with methods like sortArray and calculateAverage, which don't relate to each other or any specific entity.

Strive for high cohesion in your classes, where every method collaborates harmoniously towards a common goal. This is like having a well-orchestrated team, where each member knows their role and works seamlessly with others. By maximizing cohesion, you create classes that are focused, understandable, and easy to maintain.

Conversely, avoid creating classes with low or no cohesion, resembling a group of individuals with no shared purpose. This leads to confusion and complexity in your codebase. Instead, aim for classes where every method contributes meaningfully to the overall functionality, promoting clarity and cleanliness.

Example:

# High cohesion example
class Calculator:
    def add(self, x, y):
        return x + y

    def subtract(self, x, y):
        return x - y

# Low cohesion example
class Utilities:
    def sortArray(self, arr):
        # Sorting logic
        pass

    def calculateAverage(self, arr):
        # Average calculation logic
        pass

# Usage
calculator = Calculator()
result = calculator.add(5, 3)

Law of Demeter

The Law of Demeter, also known as the principle of least knowledge, states that a module should not know about the internal workings of the objects it manipulates. Instead, it should only interact with its immediate friends (its own attributes, parameters passed to the method, objects it creates, or global variables).

Embrace the Law of Demeter as your guiding principle when interacting with objects. Just like maintaining professional boundaries, ensure that your modules only communicate with their immediate 'friends' and avoid delving into unnecessary details. By following this principle, you foster modularity and encapsulation, resulting in code that is less prone to unexpected changes and easier to maintain.

Remember, clean code is not just about achieving functionality; it's about creating code that is intuitive, organized, and easy to modify. By incorporating these principles into your coding practices, you not only write cleaner code but also empower yourself and your team to build robust and scalable software solutions.

Example:

# Without adhering to the Law of Demeter
class Customer:
    def __init__(self, name, address):
        self.name = name
        self.address = address

    def getAddress(self):
        return self.address

# Usage
customer = Customer("John Doe", "123 Main St")
street = customer.getAddress().split(',')[0]  # Directly accessing internal state

# Adhering to the Law of Demeter
class Customer:
    def __init__(self, name, address):
        self.name = name
        self.address = address

    def getStreet(self):
        return self.address.split(',')[0]

# Usage
customer = Customer("John Doe", "123 Main St")
street = customer.getStreet()  # Indirectly accessing internal state

In conclusion, writing clean code is not just a matter of syntax and formatting; it's a mindset that values simplicity, clarity, and maintainability. By embracing principles such as Single Responsibility, Polymorphism, Maximum Cohesion, and the Law of Demeter, developers can elevate their code to a higher standard.

Encouraging users to adopt these principles fosters a culture of clean coding practices within their projects. It empowers developers to create classes that are focused, data containers that are well-organized, and interactions between modules that are cohesive and respectful of boundaries.

SOLID Principles

The SOLID principles are a set of five design principles that help developers create more maintainable, flexible, and scalable software systems. Each principle focuses on a different aspect of object-oriented design:

1. Single Responsibility Principle (SRP): This principle states that a class should have only one reason to change, meaning it should have only one responsibility or job. By adhering to SRP, classes become more focused, easier to understand, and less prone to unexpected changes.

2. Open/Closed Principle (OCP): The Open/Closed Principle suggests that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This means that the behavior of a module can be extended without modifying its source code, promoting code reuse and minimizing the risk of introducing bugs in existing code.

3. Liskov Substitution Principle (LSP): LSP states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. In other words, derived classes should be substitutable for their base classes without altering the desired properties of the program.

4. Interface Segregation Principle (ISP): ISP suggests that clients should not be forced to depend on interfaces they do not use. Instead of implementing large, monolithic interfaces, it's better to break them into smaller, more specific interfaces. This promotes loose coupling and allows clients to depend only on the functionality they need.

5. Dependency Inversion Principle (DIP): DIP advocates for high-level modules to not depend on low-level modules, but rather both should depend on abstractions. Furthermore, it suggests that abstractions should not depend on details; instead, details should depend on abstractions. By decoupling high-level and low-level modules, DIP increases flexibility, maintainability, and testability of the codebase.

Find more details here

Avoid Deep Nesting

Deeply nested code can be challenging to read, understand, and maintain. To mitigate this issue, it's advisable to use guards and fail-fast mechanisms. Guards are conditions placed at the beginning of a function or block of code to check for invalid inputs or conditions. If these conditions are met, the function exits early or raises an error. This approach helps reduce the level of nesting and improves code readability.

Example with Guards:

def calculate_total_price(items):
    if not items:
        return 0  # Guard clause to handle empty list

    total_price = 0
    for item in items:
        if item['price'] <= 0:
            continue  # Guard clause to skip items with non-positive price
        total_price += item['price']
    return total_price

In this example, the guard clause if not items checks if the list of items is empty, exiting the function early if it is. Inside the loop, another guard clause if item['price'] <= 0 skips items with non-positive prices, reducing the nesting level.

Prefer Positive Checks

Positive checks are generally easier to understand than negative ones because they express what is expected rather than what is not. It's recommended to extract control structures into functions with positive phrasing to improve code readability. Additionally, using clean function rules and inverting conditional logic can further enhance code clarity.

Example with Positive Check:

def is_valid_age(age):
    return age >= 18  # Positive check for age validity

if is_valid_age(user['age']):
    print("User is an adult.")

In this example, the function is_valid_age performs a positive check to determine if the given age is valid (>= 18), making the code more straightforward and self-explanatory.

Utilize Errors

Throwing and handling errors can be an effective alternative to complex if statements, leading to more focused and readable functions. Utilizing try-catch blocks to handle errors gracefully and creating error guards to catch potential issues early in the code can greatly improve code robustness and maintainability.

Example with Error Handling:

def divide(x, y):
    if y == 0:
        raise ValueError("Cannot divide by zero")
    return x / y

try:
    result = divide(10, 0)
except ValueError as e:
    print("Error:", e)

Here, the divide function throws a ValueError if the divisor is zero, and this error is caught and handled using a try-except block, providing a clear indication of what went wrong.

Use Factory Functions & Polymorphism

Factory functions can dynamically create objects or functions based on input parameters, contributing to cleaner control structures. By embracing polymorphism, methods with the same name can exhibit different behaviors based on input parameters, promoting modularity and extensibility.

Example with Factory Function:

def create_operation(type):
    if type == 'add':
        return lambda x, y: x + y
    elif type == 'subtract':
        return lambda x, y: x - y

add_operation = create_operation('add')
subtract_operation = create_operation('subtract')

result1 = add_operation(5, 3)
result2 = subtract_operation(5, 3)

In this example, the create_operation factory function dynamically creates different operations (addition or subtraction) based on the input type, enhancing code modularity and readability.

Modularize Code

Modularizing code involves organizing related functions into separate files or modules, promoting better code organization and maintainability. By grouping functions logically and importing them as needed, you can create a cleaner and more manageable codebase.

Example of Modularization:

# File: math_operations.py
def add(x, y):
    return x + y

def subtract(x, y):
    return x - y

# File: main.py
import math_operations

result1 = math_operations.add(5, 3)
result2 = math_operations.subtract(5, 3)

Here, the math operations are modularized into a separate module (math_operations.py), which is then imported into the main file (main.py), enhancing code organization and readability.

Summary

In conclusion, mastering control structures and error handling techniques is essential for writing clean, maintainable, and scalable code. By applying the principles outlined in this guide—avoiding deep nesting, preferring positive checks, utilizing errors, leveraging factory functions and polymorphism, and modularizing code—developers can enhance code readability, reduce complexity, and future-proof their applications. With a commitment to smart coding practices and continuous improvement, developers can unlock the full potential of their software projects and deliver exceptional value to their users and stakeholders.

Calling a function

Let's delve into a more comprehensive explanation of the principles and practices surrounding function parameters in the context of writing clean and maintainable code.

Consideration of parameters

Parameters are the inputs that functions accept to perform their tasks. When designing functions, the number and order of parameters play a pivotal role in their usability and readability.

Minimizing the number of parameters is a cardinal rule in clean code practices. Reducing parameter count simplifies the function interface, making it easier to understand and use. Developers are less likely to make mistakes when calling functions with fewer parameters, as there's less cognitive overhead in remembering their order and purpose.

Refactoring with objects

One effective technique for reducing parameter count is to bundle related parameters into an object. By encapsulating parameters within an object, you create a cohesive data structure that represents the inputs to the function. This approach improves readability by providing a clear and self-descriptive interface for invoking the function.

Let's consider a practical example to illustrate this concept. Suppose you have a logging function that logs messages, along with an optional flag indicating whether the message is an error. Initially, you might define the function with separate parameters for the message and error flag:

def log(message, is_error=False):
    if is_error:
        print(f"Error: {message}")
    else:
        print(message)

However, as the function evolves and additional parameters are introduced, the function call becomes less intuitive and more error-prone.

To address this, you can refactor the function to accept a single parameter—an object representing the logging options:

class LogOptions:
    def __init__(self, message, is_error=False):
        self.message = message
        self.is_error = is_error

def log(options):
    if options.is_error:
        print(f"Error: {options.message}")
    else:
        print(options.message)

With this refactoring, calling the log function becomes more expressive and readable:

log(LogOptions("hi", is_error=False))

While this technique aligns particularly well with functional programming principles, where functions often operate on single data structures, it's also applicable in object-oriented programming. By adopting this approach, you create cleaner and more maintainable code that adheres to the principles of encapsulation and separation of concerns.

Exceptions

It's important to note that there are exceptions to the guideline of minimizing parameter count. Functions that accept a dynamic number of arguments, such as Python's *args and **kwargs, may have a larger parameter count by necessity.

Naming

Lastly, when naming functions and their parameters, prioritize clarity and descriptiveness. Meaningful names enhance the readability of the codebase, making it easier for developers to understand and maintain.

In conclusion, by carefully considering the number and order of function parameters and leveraging techniques such as parameter bundling with objects, developers can write cleaner, more readable, and maintainable code. These practices ultimately contribute to the long-term sustainability and scalability of software projects.

Writing a function body

In software development, the length of a function's body has a profound effect on code quality and maintainability. Long, complex functions tend to obscure the logic, making it difficult for developers to grasp the overall flow and purpose. On the other hand, breaking down functions into smaller, focused units of work enhances readability, promotes code reuse, and facilitates easier debugging and testing.

Single Long Body vs. Distributed Responsibilities

Bad Example: A single long body function encapsulates multiple tasks within its structure, leading to a tangled web of logic that's challenging to comprehend at a glance. This monolithic structure intertwines various tasks, making it challenging to understand and modify.

Good Example: Distributing responsibilities across multiple smaller functions results in a more modular and readable codebase. Each function focuses on a single task, making it easier to understand and modify.

Pros of Distributing Responsibilities

1. Modularity: Breaking down functions into smaller units promotes modularity, allowing developers to understand and modify individual components without impacting the entire codebase.

2. Readability: Smaller functions are easier to read and comprehend, as they focus on specific tasks and maintain a clear, linear flow of execution.

3. Reusability: Modular functions can be reused across different parts of the codebase, reducing duplication and promoting a more efficient development process.

Guide for how to distribute responsibilities

Deciding when & how to split a function effectively is a critical aspect of writing clean and maintainable code. When breaking down functions, it's essential to adhere to the principle of "each function should only do one thing." Here's a detailed guide on how to decide when and how to split functions, while also considering levels of abstraction:

1. Single Responsibility Principle (SRP):

   Each function should have a single responsibility or perform a single task. When assessing whether to split a function, consider whether it's responsible for more than one distinct operation or task. If so, it's a clear indication that the function should be broken down into smaller, more focused units.

2. Levels of Abstraction:

   Functions should operate at a consistent level of abstraction, meaning that the operations they perform should be at a similar conceptual level. For example, a function named saveUser(user) should handle operations related to saving a user, such as validating input data or persisting user information to a database.

    def saveUser(user):
        if isEmailValid(user.email):  # Level of abstraction: Validation
            # Save user to database       # Level of abstraction: Persistence
            pass
        else:
            # Handle invalid email       # Level of abstraction: Error handling
            pass
   
    def isEmailValid(email):
        # Validate email address
        pass
   

   In this example, saveUser(user) delegates the task of email validation to isEmailValid(email), ensuring that each function operates at a consistent level of abstraction.

3. Functions Should Do Work One Level Below Their Name:

   A function's name should provide a clear indication of the task it performs, and the function itself should handle operations one level below that abstraction. For instance, a function named saveUser(user) should encapsulate operations related to saving a user, such as validating user input data, checking email validity, and persisting user information to a database.

4. Avoid mixing levels of abstraction:

   Avoid mixing operations with different levels of abstraction within the same function. For example, a function responsible for user authentication should not handle low-level tasks such as database access or input validation. By keeping functions focused on a single level of abstraction, code becomes more modular, readable, and maintainable.

5. Write pure functions:

   A pure function is one that has no side effects and always produces the same output for a given input. This property makes pure functions predictable, testable, and easier to reason about. By isolating their behavior from the rest of the system, pure functions promote code reliability and maintainability.

6. Avoid side effects:

   Side effects occur when a function modifies state outside of its scope, such as changing global variables, modifying external resources, or printing to the console. While some side effects are necessary, such as updating a database or interacting with external services, excessive side effects can make code difficult to understand and maintain.

   When a function has side effects, it's crucial to reflect this in its name. Descriptive function names can provide clarity about the potential side effects, helping developers understand the function's behavior and usage. For example, a function named updateDatabase implies that it may modify the database state.

   Alternatively, if a function performs side effects, consider encapsulating the side effect in a separate function or module. This approach isolates side effects, making them easier to manage and reason about. The pure function can then call the side effect function without directly modifying state.

Guide for when to distribute responsibilities

Deciding when to split functions depends on several factors:

1. Complexity:

   If a function becomes too complex or lengthy, it's often an indication that it should be split into smaller, more manageable units.

2. Single Responsibility:

   If a function performs multiple tasks or operations, it's a clear sign that it should be broken down into smaller functions, each with a single responsibility.

3. Reusability:

   Identify portions of code that could be reused in other parts of the codebase. Extracting reusable logic into separate functions promotes code reuse and maintains a DRY (Don't Repeat Yourself) codebase.

Guide for when not to distribute responsibilities

Avoiding the unnecessary splitting up of functions is crucial to maintaining a balance between granularity and readability. While breaking down functions can enhance code organization and clarity, excessive fragmentation can lead to code that is difficult to navigate and understand. Here's a more detailed explanation of when to avoid uselessly splitting up functions:

1. Granularity vs Readability:

   While granularity can improve code organization and reusability, it won't automatically enhance readability in all cases. Breaking down functions into excessively small units can result in code that is difficult to follow, especially if the functions are named poorly or if the split does not correspond to logical divisions in the code.

2. Renaming the Operation:

   If splitting a function results in merely renaming the operation without providing additional clarity or modularity, it may not be necessary. For example, if a function named calculateTotalPrice is split into calculateSubtotal and calculateTax, but the original function's purpose remains unchanged, the split may not add value.

3. Finding the New Function Takes Longer:

   If locating the newly extracted function takes longer than reading the extracted code inline, it defeats the purpose of splitting the function. The goal of function extraction is to enhance readability and maintainability, so if the extracted function introduces unnecessary complexity or confusion, it should be avoided.

4. Can't Produce Reasonable Name:

   If you struggle to produce a reasonable, descriptive name for the extracted function, it may indicate that the operation being extracted does not have sufficient coherence or significance to warrant its own function. Functions should encapsulate meaningful units of work, so if the extracted function lacks clear purpose or relevance, it may be better to keep the operation within the original function.

In conclusion, clean code is not just about writing code that works; it's about writing code that is easy to understand, maintain, and extend. When it comes to functions and methods, readability is paramount. Calling a function should be intuitive, with clear argument orders and concise naming conventions. Moreover, the length of a function's body plays a significant role in readability. By distributing responsibilities effectively and adhering to the single responsibility principle, functions become easier to comprehend and manage.

Vertical Formatting

Vertical formatting concerns how code is organized from top to bottom, focusing on readability and logical grouping.

1. Readability like an essay:-

   Code should be structured in a way that allows for smooth reading from top to bottom, without unnecessary jumps or disruptions. This ensures that the code flows logically and is easy to follow.

    # Bad vertical formatting
    def main():
        print("Hello,")
    print("world!")
   
    # Good vertical formatting
    def main():
        print("Hello,")
        print("world!")
   

2. Separating Different Concepts:-

   Different concepts or sections of code should be separated by spacing to visually distinguish them. This improves readability by clearly indicating transitions between different parts of the code.

    # Bad: No spacing between different concepts
    def process_data():
        # code for processing data
   
    def display_results():
        # code for displaying results
   
    # Good: Separating different concepts with spacing
    def process_data():
        # code for processing data
   
    # Spacer
    def display_results():
        # code for displaying results
   

3. Related Concepts Close Together:-

   Code that is related or serves a similar purpose should be kept close together. This makes it easier for developers to understand the context and relationship between different parts of the code.

    # Bad: Related concepts separated by unrelated code
    def calculate_area():
        # code for calculating area
   
    print("Results:")
   
    def display_results():
        # code for displaying results
   
    # Good: Related concepts grouped together
    def calculate_area():
        # code for calculating area
   
    def display_results():
        # code for displaying results
   
    print("Results:")
   

Horizontal Formatting

Horizontal formatting refers to how code is structured within a line, focusing on indentation, line breaks, and spacing.

1. Indentation:-

   Indentation is crucial for readability and code organization. Even if not strictly required by the language syntax, consistent indentation enhances readability by visually representing the structure of the code.

    # Bad: Inconsistent indentation
    def main():
    print("Hello, world!")
   
    # Good: Consistent indentation
    def main():
        print("Hello, world!")
   

2. Breaking Long Statements:-

   Long statements should be broken into multiple shorter ones to improve readability and prevent excessively long lines of code. This enhances clarity and makes it easier for developers to understand each part of the statement.

    # Bad: Long statement without line breaks
    result = calculate_some_long_expression() + another_long_expression() - \
             some_other_long_expression()
   
    # Good: Breaking long statement into multiple lines
    result = (calculate_some_long_expression() +
              another_long_expression() -
              some_other_long_expression())
   

3. Clear but Not Unreadable Long Names:-

   Variable and function names should be clear and descriptive, but not excessively long. This balance ensures that code remains readable while conveying the intent of each identifier.

    # Bad: Unreadably long name
    def calculate_area_of_rectangle_given_length_and_width(length, width):
        pass
   
    # Good: Clear and concise name
    def calculate_rectangle_area(length, width):
        pass
   

4. Spacing Between Code:-

   Proper spacing between elements of code improves readability and helps distinguish different parts of the code. Consistent use of spacing enhances clarity and makes the code easier to follow.

    # Bad: Lack of spacing between code elements
    def main():
    result=calculate_area_of_rectangle_given_length_and_width(5,10)
   
    # Good: Consistent spacing between code elements
    def main():
        result = calculate_rectangle_area(5, 10)
   

5. Line Width:-

   Lines of code should ideally be kept within a reasonable width to prevent horizontal scrolling and maintain readability. While there's no strict rule, a common guideline is to limit lines to around 80 characters.

    # Bad: Exceeding recommended line width
    result = calculate_some_long_expression() + another_long_expression() - some_other_long_expression()
   
    # Good: Keeping line width within recommended limit
    result = (calculate_some_long_expression() +
              another_long_expression() -
              some_other_long_expression())
   

Different programming languages may have their own conventions and guidelines for code formatting. It's essential to follow these conventions to ensure consistency and readability within the specific language ecosystem.

In summary, code formatting plays a crucial role in improving readability and conveying meaning within the code base. By adhering to principles of vertical and horizontal formatting, and following language-specific conventions, developers can create code that is easier to understand, maintain, and collaborate on.

Implementing the principles of good and bad comments in code requires careful consideration of clarity, necessity, and maintainability.

When writing code, it's best to make it easy to understand without needing lots of comments. This means using clear names for things and organizing the code in a logical way. Comments should only be used when necessary, like when something isn't obvious from the code alone.

Poor Comments

1. Redundant Comments:-

    # Increment x by 1
    x += 1
   

   Comments like this are redundant because the code itself is self-explanatory and adding a comment doesn't provide any additional value.

2. Misleading Comments:-

    # Calculate average of numbers
    total = sum(numbers)
   

   Misleading comments can confuse other developers and lead to misunderstandings about the code's functionality. Like the above example has a comment that says 'Calculate average of numbers'. But actually, it's summing the numbers, not calculating the average.

3. Commented-out Code:-

    # x = 10
    # This line is commented out because we're not sure if we still need it.
   

   Leaving commented-out code in the source can clutter the codebase and make it difficult to understand the active code.

Good Comments

1. Legal Information:-

    # Copyright (C) 2024 CompanyXYZ. All rights reserved.
   

   This type of comment provides important legal information about the code's ownership and usage rights.

2. Explanations which can't be replaced by naming convention:-

    # Explanation: Using a custom sorting algorithm due to specific requirements.
    def custom_sort(items):
        # Custom sorting algorithm implementation
        pass
   

   In this case, the comment explains why a custom sorting algorithm is being used instead of a built-in sorting function. This explanation provides valuable context that cannot be conveyed solely through the function name or code itself.

3. Warnings:-

    # WARNING: This function modifies the global variable 'counter'.
    def increment_counter():
        global counter
        counter += 1
        return counter
   

   In this example, the comment warns other developers that the function increment_counter() modifies a global variable named counter. This information is crucial for understanding the potential side effects of using this function.

4. Todo:-

    # TODO: Implement error handling for invalid input.
    def parse_input(input_str):
        # Code for parsing input goes here
        pass
   

   Here, the comment indicates that the function parse_input() lacks error handling for invalid input. This serves as a reminder to implement this functionality in the future.

5. Documentation Comments:-

    """
    This function calculates the area of a rectangle.
   
    :param length: The length of the rectangle.
    :param width: The width of the rectangle.
    :return: The area of the rectangle.
    """
    def calculate_rectangle_area(length, width):
        return length * width
   

   Documentation comments provide comprehensive documentation for functions, classes, or modules, enhancing code readability and maintainability.

In short, good code speaks for itself. By keeping things clear and organized, we can avoid the need for too many comments. While comments have their place, we should aim for code that's easy to understand without them. If used, comments should add value by providing necessary context, warnings, or documentation, rather than stating the obvious or cluttering the code base with redundant or misleading information.

Names should be meaningful

const us = new MainEntity();
us.process();
if (login) {
    // Some code related to login
}

Consider the above example:-

• Lack of clarity on the overall purpose or functionality of the code snippet.

• The purpose and role of MainEntity are undefined, making it unclear what it represents.

• The process method lacks description, leaving ambiguity about its functionality.

• The condition check for login is unclear, with no indication of its type or purpose.

• Ambiguity persists regarding whether login is a boolean flag, variable, or function.

• The absence of context, descriptive naming, and documentation makes the code difficult to understand and maintain.

class UserSession {
    constructor() {
        // Initialize user session
    }

    authenticate(credentials) {
        // Authenticate user with provided credentials
        // Return true if authentication successful, false otherwise
    }

    isLoggedIn() {
        // Check if user is currently logged in
        // Return true if logged in, false otherwise
    }
}

class UserManager {
    constructor() {
        this.userSession = new UserSession();
    }

    authenticateUser(credentials) {
        const isAuthenticated = this.userSession.authenticate(credentials);
        if (isAuthenticated) {
            // Proceed with authenticated user logic
        } else {
            // Handle authentication failure
        }
    }

    isLoggedIn() {
        return this.userSession.isLoggedIn();
    }
}

• The UserManager class effectively manages user-related functionality, including authentication and login status checks.

• Descriptive naming of classes and methods, such as authenticateUser and isLoggedIn, enhances readability and understanding of their purpose.

• Each method within the UserManager class has a clearly defined role, reducing ambiguity and improving maintainability.

• The isLoggedIn method returns a boolean value, providing clarity on the user's login status.

• Well-structured code and meaningful names offer context and understanding of the implemented functionality.

• While not explicitly shown, adding comments or documentation would further enhance comprehension and maintainability.

Meaningful names in code are paramount as they significantly enhance the readability, maintainability, and scalability of software projects. Clear and descriptive names for variables, functions, and classes facilitate easier comprehension for developers, reducing the cognitive load and enabling efficient collaboration. Additionally, meaningful names serve as a form of self-documentation, conveying the purpose and functionality of code elements without the need for extensive comments or documentation. This aids in debugging and troubleshooting processes, as well as in the ongoing maintenance and evolution of the codebase. Ultimately, investing time and effort into choosing meaningful names pays dividends in terms of code quality, developer productivity, and the long-term sustainability of software projects.

Name Casing

Name casing is paramount in clean code as it enhances readability, maintainability, and collaboration among developers. By adhering to consistent naming conventions throughout the code base, developers can quickly understand the purpose and type of each identifier, facilitating easier navigation and modification of code. Clear and intuitive naming conventions also promote effective collaboration, as standardized naming styles reduce misunderstandings and promote cohesive coding standards. Additionally, name casing contributes to code consistency, ensuring that all elements of the code base follow the same conventions, thus enhancing overall code quality.

There are 4 major types of name casing used:-

1. Snake Case:-

   Usages - Typically used in Python for variables, functions, and methods.

   Examples -

    user_name = "John Doe"
    calculate_discount = lambda price, percentage: price * percentage / 100
   

2. Camel Case:-

   Usages - Commonly used in Java and JavaScript for variables, functions, and methods.

   Examples -

    let userName = "John Doe";
    function calculateDiscount(price, percentage) {
        // Function implementation
    }
   

3. Pascal Case:-

   Usages - Used in Python, Java, and JavaScript for naming classes.

   Examples -

    public class UserProfile {
        private String name;
        private int age;
   
        // Constructor, getters, setters, etc.
    }
   

4. Kebab Case:-

   Usages - Often used in HTML for attributes like IDs and classes.

   Examples -

    <div id="user-profile" class="user-info"></div>
   

These naming conventions help maintain consistency and readability within code bases, aiding developers in understanding and navigating the code more efficiently.

How to name variables & constants?

The standard rules when we should follow naming variables and constants is - describe the value and provide more details about the value's context without introducing redundancy (if applicable).

1. Object

   Representing a user

   Variable: user

   More details: loggedInUser, updatedUser, customer

2. Number

   Representing age

   Variable: age

   More details: userAge, customerAge, employeeAge

3. String

   Representing a name

   Variable: name

   More details: userName, productName, customerName

4. Boolean

   Representing whether a user is active

   Variable: isActive

   More details: isLoggedInUserActive, isCustomerActive

5. Context oriented

   User to Customer

   Poor examples: u, c, lIU, uR

   Improved examples: customer, client, loggedInCustomer, registeredCustomer

6. Constants

   Representing the value of PI

   Variable: PI

These examples demonstrate the importance of using descriptive and contextually appropriate names for variables and constants, enhancing readability, clarity, and maintainability of code.

How to name Functions/Methods?

The standard rule we should follow when naming functions/methods is - use verbs or short phrases with descriptive adjectives.

We can categorize the naming for functions/methods in 3 types:-

1. Performs an operation:

   • Performs an operation:

     • calculateArea()

       This method calculates the area of a shape, specifying clearly what it does without introducing redundancy. It follows the convention of using a verb (calculate) followed by a noun (Area) to describe the action performed.

   • Computes a boolean:

     • isValidEmail()

       This function computes a boolean value indicating whether an email address is valid or not. It follows the convention of using a verb (isValid) followed by a noun (Email) to describe the action and the context of the computation.

2. Context-oriented names:

   • addEmployeeToDepartment()

     This method adds an employee to a specific department, clearly indicating the context and action being performed. It follows the convention of prioritizing clarity and specificity in naming methods related to specific contexts.

   • employee.addToDepartment()

     This syntax suggests that an action (addToDepartment) is performed by an instance of the employee object within its own context. It adheres to object-oriented principles by indicating the subject of the action directly.

   • department.addEmployee()

     This syntax suggests that an action (addEmployee) is performed on the department object. It follows a logical structure of subject-verb, making it clear what is being acted upon within the context of the department.

3. Custom examples:

   • Performs an operation:

     • generateReportSummary()

       This method generates a summary report based on certain data or criteria. It follows the convention by using a verb (generate) followed by a noun (ReportSummary) to describe the action.

   • Computes a boolean:

     • isUserLoggedIn()

       This function computes a boolean value indicating whether a user is currently logged in or not. It follows the convention by using a verb (is) followed by a descriptive adjective and noun (UserLoggedIn) to describe the context and the result of the computation.

   • Context-oriented names:

     • checkoutCart()

       This method performs the action of checking out items in a shopping cart. It follows the convention by clearly indicating the context (cart) and the action (checkout) being performed.

These examples demonstrate how naming conventions can greatly enhance code readability and maintainability by providing clear indications of what each function/method does and within what context it operates.

How to name classes?

The standard rule we should follow when naming classes is - use nouns or short phrases with nouns

Sure, here are detailed examples of naming classes using the provided guidelines along with custom examples:

1. Describe the object:

   • Product

     This class represents a product in a system. It follows the convention of using a noun (Product) to clearly describe the object it represents.

2. Provide more details without introducing redundancy:

   • Course

     This class represents a course, providing additional details without redundancy. It's concise and descriptive, making it clear what kind of object it represents without unnecessary repetition.

3. Avoid redundant suffixes:

   • DatabaseManager

     This class manages interactions with a database. It avoids redundant suffixes like "Obj" or "Entity" and instead focuses on describing the primary responsibility of the class.

4. Custom examples:

   • Describe the object:

     • Customer

       This class represents a customer entity within a system. It follows the convention by using a noun (Customer) to clearly describe the object it represents.

   • Provide more details without introducing redundancy:

     • StudentProfile

       This class represents the profile of a student. It provides additional details (Profile) without introducing redundancy, making it clear what kind of object it represents.

   • Avoid redundant suffixes:

     • FileHandler

       This class handles file-related operations. It avoids redundant suffixes and focuses on describing its primary responsibility, which is handling files.

   • Bad names (to contrast):

     • UserObj

       This name is considered bad because it lacks specificity and does not provide clear information about the purpose or nature of the object it represents.

     • ObjectA

       This name is vague and does not convey any meaningful information about the object it represents, making it difficult to understand its purpose or use in the codebase.

     • Data

       This name is too generic and lacks specificity. It does not explain what kind of data the class represents or what its purpose is within the system, making it ambiguous and potentially confusing to other developers.

Common pitfalls when naming

In the context of writing clean code, naming conventions and consistency are crucial aspects that can greatly affect the readability, maintainability, and overall quality of your code base. Let's break down the common pitfalls that can occur when naming variables, functions, classes & more:

1. Avoid unnecessary details in variable names:-

   When naming variables, it's essential to strike a balance between being descriptive and concise. Variables should convey their purpose without including redundant information. For instance, instead of naming a variable customerWithNameAndAge, which explicitly states both the customer's name and age, you could simply name it customer. The context or usage of the variable should provide clarity on what data it holds.

2. Avoid slang or unclear abbreviations:-

   Using clear and understandable names helps other developers (including your future self) comprehend the code more easily. Avoid using obscure abbreviations or slang that might not be immediately apparent to others. For example, using userWithEscalatedPrivileges instead of an unclear abbreviation like uwep ensures that the purpose of the variable is clear at a glance.

3. Avoid disinformation:-

   Naming variables or functions in a way that misleads or provides incorrect information can lead to confusion and errors in the code. For instance, naming a variable allCustomers when it actually contains filtered customers can mislead other developers. Choosing names like filteredCustomers would accurately convey the contents of the variable, promoting clarity and reducing the chances of misunderstanding.

4. Choose distinctive and explanatory names:-

   Functions and methods should have names that clearly describe their purpose and functionality. Ambiguous names like doSomething or processStuff can be vague and unhelpful. Instead, opt for names that succinctly describe the action performed, such as resizeImage, applyFilter, or convertFormat. These names provide clear indications of what the function does, making the code easier to understand and maintain.

5. Be consistent:-

   Consistency in naming conventions across your codebase is essential for readability and maintainability. Choose a naming style for functions, variables, and classes and stick to it throughout your application. Whether you prefer getCustomers(), fetchCustomers(), or retrieveCustomers(), ensure that the chosen style is consistently applied. Inconsistent naming conventions can confuse developers and make it harder to understand the codebase as a whole.

In summary, adhering to these principles of clean code—using descriptive yet concise names, avoiding ambiguous or misleading terminology, and maintaining consistency—can significantly improve the quality and readability of your code, making it easier to understand, debug, and maintain over time.

In this blog, we'll delve into the essence of each SOLID principle, understanding what they entail and why they matter. Whether you're a seasoned developer looking to refine your skills or a newcomer eager to grasp fundamental principles, this journey through SOLID principles promises to provide valuable insights and actionable knowledge. Let's embark on this exploration together and unlock the power of SOLID principles to elevate your software craftsmanship.

Introduction

SOLID principles are a set of design principles that aim to make software designs more understandable, flexible, and maintainable.

The SOLID acronym stands for:

1. S - Single Responsibility Principle (SRP)

2. O - Open/Closed Principle (OCP)

3. L - Liskov Substitution Principle (LSP)

4. I - Interface Segregation Principle (ISP)

5. D - Dependency Inversion Principle (DIP)

These principles provide guidelines for writing clean, maintainable, and scalable code. By adhering to them, developers can create software systems that are easier to understand, extend, and modify.

History

SOLID principles were introduced by Robert C. Martin (also known as Uncle Bob) in the early 2000s and have since become a cornerstone of object-oriented design and programming. Robert C. Martin introduced these principles in his paper "Design Principles and Design Patterns," presented at the OOPSLA conference in 1995. They were further popularized in his book "Agile Software Development, Principles, Patterns, and Practices," published in 2002. Since then, they have become foundational concepts in software engineering and are often taught in computer science courses and used in software development practices worldwide.

S - Single Responsibility Principle (SRP)

Definition

A class should have only one reason to change.

Explanation

This principle suggests that a class should have only one responsibility or job. It should encapsulate one and only one aspect of functionality within the software. This principle promotes a modular approach to software development by encouraging developers to break down complex systems into smaller, more manageable components.

To understand SRP more thoroughly, let's delve into its key aspects:

1. Responsibility: A responsibility in the context of SRP refers to a reason for a class to change. It can be defined as a cohesive set of tasks or functionalities that the class is responsible for.

2. Reason to Change: A reason to change is any requirement or feature that might necessitate modifications to the code. By adhering to SRP, we aim to minimize the number of reasons for a class to change, thus reducing the likelihood of unintended side effects when modifications are made.

3. Encapsulation: SRP is closely related to the concept of encapsulation, which is one of the core principles of object-oriented programming. Encapsulation involves bundling data and the methods that operate on that data into a single unit (i.e., a class). SRP suggests that this unit should have a single, well-defined responsibility.

4. Cohesion: SRP encourages high cohesion within classes. Cohesion refers to the degree to which the elements of a module (e.g., a class) belong together. A class with high cohesion focuses on a single task or responsibility, making it easier to understand, maintain, and test.

5. Separation of Concerns: SRP promotes the separation of concerns, which is a design principle aimed at separating a computer program into distinct sections, each addressing a separate concern. By separating concerns, we can manage complexity more effectively and improve maintainability.

6. Benefits:

   • Improved Readability: Classes with a single responsibility tend to be more concise and easier to understand.

   • Ease of Maintenance: When a class has only one reason to change, modifications are less likely to have unintended consequences elsewhere in the codebase.

   • Testability: Smaller, more focused classes are typically easier to test because they have fewer dependencies and behaviors to consider.

   • Reusability: Well-designed classes with a clear responsibility can often be reused in different contexts without modification.

Example - Violation

Let's consider an example where the Single Responsibility Principle is violated in an Account controller that handles deposit, withdrawal, and money transfer operations. We'll combine authorization logic, validation logic, and database transaction logic within the controller.

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;

@Controller
public class AccountController {

    private AccountService accountService;

    // Authorization and validation logic combined with business logic
    @PostMapping("/deposit")
    @ResponseBody
    public String deposit(@RequestParam("accountId") String accountId, @RequestParam("amount") double amount) {
        // Authorization logic
        if (!authorizeUser()) {
            return "Unauthorized";
        }

        // Validation logic
        if (amount <= 0) {
            return "Invalid amount";
        }

        // Database transaction logic
        if (accountService.deposit(accountId, amount)) {
            return "Deposit successful";
        } else {
            return "Deposit failed";
        }
    }

    // Similar methods for withdrawal and transfer

    private boolean authorizeUser() {
        // Authorization logic implementation
        return true; // Placeholder implementation
    }
}

In this example, the AccountController class is responsible for handling HTTP requests related to account operations. However, it is violating the Single Responsibility Principle by combining authorization logic, validation logic, and database transaction logic within the controller.

To correct this violation and adhere to the Single Responsibility Principle, we can separate these concerns into distinct classes:

1. AuthorizationService: Responsible for handling authorization logic.

2. ValidationService: Responsible for handling validation logic.

3. AccountService: Responsible for handling database transactions related to account operations.

Example - Fix

Here's how we can refactor the code:

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class AuthorizationService {

    public boolean authorizeUser() {
        // Authorization logic implementation
        return true; // Placeholder implementation
    }
}

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class ValidationService {

    public boolean validateAmount(double amount) {
        return amount > 0;
    }
}

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class AccountService {

    @Autowired
    private AccountRepository accountRepository;

    public boolean deposit(String accountId, double amount) {
        // Database transaction logic
        // Call methods from AccountRepository
        return true; // Placeholder implementation
    }

    // Similar methods for withdrawal and transfer
}

import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

@Repository
public interface AccountRepository extends JpaRepository<Account, Long> {
    // Define methods for interacting with the account database
}

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;

@Controller
public class AccountController {

    @Autowired
    private AuthorizationService authorizationService;

    @Autowired
    private ValidationService validationService;

    @Autowired
    private AccountService accountService;

    @PostMapping("/deposit")
    @ResponseBody
    public String deposit(@RequestParam("accountId") String accountId, @RequestParam("amount") double amount) {
        if (!authorizationService.authorizeUser()) {
            return "Unauthorized";
        }

        if (!validationService.validateAmount(amount)) {
            return "Invalid amount";
        }

        if (accountService.deposit(accountId, amount)) {
            return "Deposit successful";
        } else {
            return "Deposit failed";
        }
    }

    // Similar methods for withdrawal and transfer
}

In this refactored version, we've separated the concerns into distinct classes: AuthorizationService, ValidationService, and AccountService. The AccountController now only orchestrates the flow of control by delegating the authorization and validation tasks to their respective services, and the database transaction logic is handled by the AccountService. This separation of concerns adheres to the Single Responsibility Principle, making the codebase more modular, maintainable, and testable.

O - Open/Closed Principle (OCP)

Definition

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

Explanation

OCP emphasizes that software entities should allow for extension without requiring changes to their source code. This is achieved through abstraction and polymorphism.

In simpler terms, this principle suggests that once a class (or module or function) is written and tested, it should not be modified to add new behavior or to alter existing behavior. Instead, it should be designed in a way that allows new functionalities to be added without changing its source code.

Here's a detailed explanation of the Open-Closed Principle:

1. Open for Extension: This aspect implies that the behavior of a software entity can be extended without modifying its source code. In practical terms, this means that you should be able to add new functionality to a class or module by creating new code (such as subclasses, new modules, or new functions) rather than changing the existing code.

2. Closed for Modification: This aspect implies that the existing source code of a software entity should not be changed. Once a class or module is developed, tested, and considered stable, it should remain untouched. Modifying existing code can introduce bugs and unintended consequences, especially in large systems.

To achieve the Open-Closed Principle, several design patterns and techniques can be applied:

• Abstraction: The base class provides a common interface, while subclasses can override or extend specific behaviors.

• Interfaces: Define interfaces or abstract classes that specify the behavior expected from different implementations. This allows new implementations to be added without modifying existing code.

• Composition over Inheritance: Instead of using inheritance, use composition to build flexible and extensible systems. This involves creating classes that contain instances of other classes, allowing behavior to be composed dynamically.

• Strategy Pattern: Define a family of algorithms, encapsulate each one as an object, and make them interchangeable. This allows the behavior of a class to vary independently from the class itself, promoting the open-closed principle.

• Decorator Pattern: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

• Dependency Injection: Instead of directly creating dependencies within a class, inject them from the outside. This allows different implementations to be provided at runtime, promoting flexibility and extensibility.

By following the Open-Closed Principle, you can create software that is easier to maintain, extend, and test. It encourages modular, reusable, and loosely coupled designs, which are essential for building scalable and adaptable systems.

Example - Violation

Suppose we have a AccessControl interface and two concrete implementations: BasicAccessControl and AdminAccessControl. They both provide methods to check access and perform some security-related operations.

interface AccessControl {
    boolean hasAccess(String userId);
}

class BasicAccessControl implements AccessControl {
    @Override
    public boolean hasAccess(String userId) {
        // Basic access control logic
        return true;
    }
}

class AdminAccessControl implements AccessControl {
    @Override
    public boolean hasAccess(String userId) {
        // Admin access control logic
        return true;
    }

    // New method added violating OCP
    public void logAccess(String userId) {
        // Log access details
        System.out.println("Access logged for user: " + userId);
    }
}

In this example, AdminAccessControl violates the Open-Closed Principle by adding a new method logAccess() to the class. If we continue adding new methods for different purposes, it would lead to modifying existing classes whenever new functionalities are introduced, which is against the principle.

Example - Fix

To adhere to the Open-Closed Principle, we can introduce a new class hierarchy for handling additional functionalities. We'll introduce an AccessControlLogger interface and concrete implementations for logging access details. This way, we can extend the behavior of AccessControl without modifying existing classes.

interface AccessControl {
    boolean hasAccess(String userId);
}

class BasicAccessControl implements AccessControl {
    @Override
    public boolean hasAccess(String userId) {
        // Basic access control logic
        return true;
    }
}

interface AccessControlLogger {
    void logAccess(String userId);
}

class BasicAccessControlLogger implements AccessControlLogger {
    @Override
    public void logAccess(String userId) {
        // Log basic access details
        System.out.println("Basic access logged for user: " + userId);
    }
}

class AdminAccessControl implements AccessControl, AccessControlLogger {
    @Override
    public boolean hasAccess(String userId) {
        // Admin access control logic
        return true;
    }

    @Override
    public void logAccess(String userId) {
        // Log admin access details
        System.out.println("Admin access logged for user: " + userId);
    }
}

Now, AdminAccessControl implements both AccessControl and AccessControlLogger, allowing it to provide access control and logging functionalities separately. This approach follows the Open-Closed Principle because we can add new functionalities (like logging) without modifying existing classes.

L - Liskov Substitution Principle (LSP)

Definition

A subclass should be substitutable for its superclass without causing errors or unexpected behavior.

Explanation

Key Points:

1. Inheritance Hierarchy: The principle primarily deals with inheritance relationships, where a subclass inherits from a superclass. The subclass should extend or specialize the behavior of the superclass but not alter its fundamental contract or assumptions.

2. Behavior Preservation: When substituting a subclass instance for a superclass instance, the client code should continue to function correctly. This means that the subclass must honor the same contracts, adhere to the same preconditions and postconditions, and respect the same invariants as the superclass.

3. Type Contracts: The LSP emphasizes the importance of adhering to the contracts defined by the superclass. This includes method signatures, behavior expectations, and any constraints specified by the superclass. Subclasses can strengthen (but not weaken) these contracts.

4. Design by Contract: The principle aligns with the broader concept of "design by contract," where classes explicitly state their preconditions, postconditions, and invariants. Subclasses are expected to adhere to and possibly extend these contracts, ensuring that they maintain the same level of reliability and predictability.

5. Robustness and Extensibility: Adhering to the LSP enhances the robustness and extensibility of object-oriented systems. It allows for easy substitution of components, facilitates code reuse, and simplifies maintenance, as changes to subclasses don't break client code relying on superclass behavior.

Benefits:

• Maintainability: Eases maintenance by allowing for easy substitution of objects.

• Robustness: Ensures that changes to subclasses don't inadvertently break client code.

• Code Reusability: Encourages code reuse through inheritance.

• Design Clarity: Promotes clear interfaces and contracts between classes.

By adhering to the Liskov Substitution Principle, developers can create more flexible, robust, and maintainable object-oriented systems.

Example - Violation

Let's consider a scenario where we have a caching system with two implementations: a LocalCache and a NetworkCache. We'll demonstrate a violation of the Liskov Substitution Principle and then correct it.

class Cache {
    // Common cache methods
    public void put(String key, Object value) {
        // implementation
    }

    public Object get(String key) {
        // implementation
        return null;
    }
}

class LocalCache extends Cache {
    // Local cache specific methods and implementations
}

class NetworkCache extends Cache {
    // Network cache specific methods and implementations
}

Now, let's say the NetworkCache has to make a network call to fetch the data, but the get method in the Cache class is synchronous. To handle the network call, NetworkCache might need an asynchronous get method. In this case, NetworkCache cannot be substituted for Cache without affecting the behavior, violating LSP.

Example - Fix

interface Cache {
    void put(String key, Object value);
    Object get(String key);
}

class LocalCache implements Cache {
    @Override
    public void put(String key, Object value) {
        // Local cache specific implementation
    }

    @Override
    public Object get(String key) {
        // Local cache specific implementation
        return null;
    }
}

class NetworkCache implements Cache {
    @Override
    public void put(String key, Object value) {
        // Network cache specific implementation
    }

    @Override
    public Object get(String key) {
        // Asynchronous network call implementation
        // This might involve using callbacks, CompletableFuture, or similar mechanisms
        // This method might not return the actual value immediately but instead returns a Future or uses a callback
        return fetchDataAsynchronously(key);
    }

    private CompletableFuture<Object> fetchDataAsynchronously(String key) {
        // Simulated asynchronous network call
        return CompletableFuture.supplyAsync(() -> {
            // Actual network call to fetch data
            return fetchDataFromNetwork(key);
        });
    }

    private Object fetchDataFromNetwork(String key) {
        // Simulated network data fetch
        return null;
    }
}

In this corrected version, both LocalCache and NetworkCache implement the Cache interface. The get method in NetworkCache returns a CompletableFuture representing the asynchronous result of the network call. This allows NetworkCache to be substituted for Cache without altering the behavior expected by client code, thus satisfying the Liskov Substitution Principle.

I - Interface Segregation Principle (ISP)

Definition

Clients should not be forced to depend on interfaces they do not use.

Explanation

The principle emphasizes the importance of designing software interfaces in a way that clients should not be forced to depend on methods they do not use. In simpler terms, ISP advocates for smaller, cohesive interfaces tailored to specific client requirements rather than large, monolithic ones.

At its core, ISP encourages developers to create specialized interfaces that contain only the necessary methods relevant to a specific client or group of clients. This prevents clients from being burdened with methods they don't need, which in turn promotes cleaner, more maintainable code.

Example:

Consider a scenario where you have an interface called Worker which has methods such as work(), eat(), and sleep(). Now, let's say you have two types of clients: Robot and Human. Robots don't eat or sleep, they only work. Humans, on the other hand, do all three tasks.

With a single Worker interface, both Robot and Human classes would have to implement all three methods. This violates the Interface Segregation Principle because the Robot class would be forced to implement methods it doesn't need.

By segregating the interfaces, you could have an Workable interface containing only the work() method, and a Eatable interface containing only the eat() method. Both Robot and Human classes would then implement only the interfaces relevant to them.

Benefits:

1. Reduced Dependency: Clients are not forced to depend on methods they don't use, reducing unnecessary dependencies.

2. Improved Cohesion: Interfaces become more focused and cohesive, leading to clearer and more maintainable code.

3. Easier Testing: Smaller interfaces are easier to test because there are fewer methods to consider in each test case.

4. Flexibility and Scalability: It facilitates easier modifications and extensions as new clients can be accommodated without affecting existing ones.

Implementation Guidelines:

1. Identify Clients: Understand the different types of clients that will interact with your system.

2. Group Methods: Group methods based on client requirements and create smaller, focused interfaces.

3. Prefer Composition over Inheritance: Sometimes, ISP can be achieved more effectively through composition rather than inheritance.

4. Refactor Existing Code: If necessary, refactor existing interfaces to adhere to the ISP.

The Interface Segregation Principle is a fundamental concept in OOP design that promotes flexibility, maintainability, and scalability in software systems. By focusing on the specific needs of clients and avoiding unnecessary dependencies, developers can create more robust and adaptable codebases. Following ISP, along with other SOLID principles, can lead to better-designed, more maintainable, and easier-to-understand software architectures.

Example - Violation

// MediaPlayer.java
public interface MediaPlayer {
    String fetchAudioUrl();
    String fetchVideoUrl();
}

// WindowsMediaPlayer.java
public class WindowsMediaPlayer implements MediaPlayer {
    @Override
    public String fetchAudioUrl() {
        return "Fetch audio URL for Windows Media Player";
    }

    @Override
    public String fetchVideoUrl() {
        return "Fetch video URL for Windows Media Player";
    }
}

// VlcMediaPlayer.java
public class VlcMediaPlayer implements MediaPlayer {
    @Override
    public String fetchAudioUrl() {
        return "Fetch audio URL for VLC Media Player";
    }

    @Override
    public String fetchVideoUrl() {
        return "Fetch video URL for VLC Media Player";
    }
}

// SpotifyMediaPlayer.java
public class SpotifyMediaPlayer implements MediaPlayer {
    @Override
    public String fetchAudioUrl() {
        return "Fetch audio URL for Spotify Media Player";
    }

    @Override
    public String fetchVideoUrl() {
        // Spotify doesn't support direct fetching of video URLs
        throw new UnsupportedOperationException("Spotify does not support fetching video URLs");
    }
}

The issue here is that all implementations of the MediaPlayer interface are forced to implement both fetchAudioUrl() and fetchVideoUrl() methods, even if some players like SpotifyMediaPlayer don't support fetching audio URLs.

Example - Fix

To adhere to the Interface Segregation Principle, we should split the MediaPlayer interface into two separate interfaces, one for audio-related functionalities and another for video-related functionalities.

// AudioPlayer.java
public interface AudioPlayer {
    String fetchAudioUrl();
}

// VideoPlayer.java
public interface VideoPlayer {
    String fetchVideoUrl();
}

// WindowsMediaPlayer.java
public class WindowsMediaPlayer implements AudioPlayer, VideoPlayer {
    @Override
    public String fetchAudioUrl() {
        return "Fetch audio URL for Windows Media Player";
    }

    @Override
    public String fetchVideoUrl() {
        return "Fetch video URL for Windows Media Player";
    }
}

// VlcMediaPlayer.java
public class VlcMediaPlayer implements AudioPlayer, VideoPlayer {
    @Override
    public String fetchAudioUrl() {
        return "Fetch audio URL for VLC Media Player";
    }

    @Override
    public String fetchVideoUrl() {
        return "Fetch video URL for VLC Media Player";
    }
}

// SpotifyMediaPlayer.java
public class SpotifyMediaPlayer implements AudioPlayer {
    @Override
    public String fetchAudioUrl() {
        return "Fetch audio URL for Spotify Media Player";
    }
}

By splitting the MediaPlayer interface into AudioPlayer and VideoPlayer, each class is now only forced to implement the methods that are relevant to it. This adheres to the Interface Segregation Principle, as clients are not forced to depend on interfaces they do not use. Now, SpotifyMediaPlayer doesn't need to implement the fetchAudioUrl() method, thus preventing it from having to throw an UnsupportedOperationException.

D - Dependency Inversion Principle (DIP)

Definition

High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions.

Explanation

The principle suggests that high-level modules (which contain the more abstract and policy-related aspects of the application) should not depend on low-level modules (which contain the more detailed implementation details). Instead, both should depend on abstractions, which can be interfaces or abstract classes. This decouples modules and makes the code more flexible and easier to maintain.

At its core, the Dependency Inversion Principle suggests two main things:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.

2. Abstractions should not depend on details. Details should depend on abstractions.

Let's break down these concepts:

1. High-level modules should not depend on low-level modules: This means that classes or modules that implement high-level policy or logic should not depend on the details of low-level components, such as specific implementations or concrete classes. Instead, both high-level and low-level modules should depend on abstractions. For example, rather than a high-level module directly instantiating or depending on a specific database class, it should depend on an interface or an abstract class that defines the behavior expected from the database component. This promotes decoupling and allows for easier substitution of components.

2. Abstractions should not depend on details: This suggests that interfaces or abstract classes (abstractions) should define the behavior or contract that components adhere to, without depending on the specific implementation details of those components. In other words, the high-level policy or logic should not be affected by changes to the low-level details. This allows for greater flexibility and extensibility in the system. For example, if you have an interface for a logging service, it should define methods like logInfo, logError, etc., without specifying how those methods are implemented. Concrete logging implementations can then adhere to this interface, allowing for easy swapping between different logging mechanisms without affecting the rest of the codebase.

By adhering to the Dependency Inversion Principle, you create a more modular and flexible design where components can be easily replaced or extended without impacting other parts of the system. It also facilitates easier testing since components can be easily mocked or replaced with stubs or fakes. Overall, DIP promotes a design that is easier to maintain, extend, and understand.

Example - Violation

Initially, the NotificationService directly depends on the concrete implementation of the EmailService.

// High-level module
class NotificationService {
    private EmailService emailService;

    public NotificationService() {
        this.emailService = new EmailService();
    }

    public void sendNotification(String message) {
        emailService.sendEmail("user@example.com", message);
    }
}

// Low-level module
class EmailService {
    public void sendEmail(String recipient, String message) {
        // Logic to send email
        System.out.println("Email sent to " + recipient + ": " + message);
    }
}

public class Main {
    public static void main(String[] args) {
        NotificationService notificationService = new NotificationService();
        notificationService.sendNotification("Hello, this is a notification!");
    }
}

Example - Fix

To adhere to the Dependency Inversion Principle, we'll introduce an abstraction (interface) NotificationProvider that both NotificationService, EmailService, and SMSService will depend on. This way, NotificationService won't depend directly on the concrete implementations of these services.

// Abstraction
interface NotificationProvider {
    void sendNotification(String recipient, String message);
}

// Low-level module
class EmailService implements NotificationProvider {
    public void sendNotification(String recipient, String message) {
        // Logic to send email
        System.out.println("Email sent to " + recipient + ": " + message);
    }
}

// Low-level module
class SMSService implements NotificationProvider {
    public void sendNotification(String recipient, String message) {
        // Logic to send SMS
        System.out.println("SMS sent to " + recipient + ": " + message);
    }
}

// High-level module
class NotificationService {
    private NotificationProvider notificationProvider;

    public NotificationService(NotificationProvider notificationProvider) {
        this.notificationProvider = notificationProvider;
    }

    public void sendNotification(String recipient, String message) {
        notificationProvider.sendNotification(recipient, message);
    }
}

public class Main {
    public static void main(String[] args) {
        NotificationProvider emailService = new EmailService(); // Dependency injection
        NotificationProvider smsService = new SMSService(); // Dependency injection

        NotificationService emailNotificationService = new NotificationService(emailService);
        emailNotificationService.sendNotification("user@example.com", "Hello, this is an email notification!");

        NotificationService smsNotificationService = new NotificationService(smsService);
        smsNotificationService.sendNotification("1234567890", "Hello, this is an SMS notification!");
    }
}

In this refactored version, both EmailService and SMSService implement the NotificationProvider interface. This allows the NotificationService to be decoupled from specific implementations of notification providers and to depend on abstractions. This design adheres to the Dependency Inversion Principle, promoting flexibility and easier maintenance of the codebase.

Conclusion

In conclusion, SOLID principles serve as guiding beacons in the vast sea of software development, illuminating the path to creating robust, maintainable, and adaptable codebases. By adhering to these principles—Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion—developers can foster codebases that are easier to understand, extend, and modify.

As we wrap up our exploration of SOLID principles, it's essential to recognize their significance in shaping not only individual code modules but entire software ecosystems. By embracing SOLID principles, developers empower themselves to write code that not only solves immediate problems but also stands the test of time, evolving gracefully as requirements change and technologies advance.

So, whether you're embarking on a new project or refactoring existing code, remember the SOLID principles as your guiding compass. Let them steer you towards software designs that are not only elegant but also resilient in the face of change. Together, let's build a future where SOLID principles are more than just principles—they're the foundation upon which exceptional software is built.

The beauty of OOP lies in its ability to create modular, reusable, and extensible code. By organizing software into objects, programmers can break down complex problems into smaller, more manageable components, each with its own well-defined responsibilities and behaviors.

OOP concepts have been instrumental in the development of robust, scalable, and maintainable software systems across various domains, from web applications and mobile apps to games and scientific simulations. By embracing OOP principles, programmers can create code that is not only functional but also easier to understand, modify, and extend over time.

In this blog, we'll explore the intricacies of OOP concepts, providing examples and real-world use cases to help you grasp their significance and practical applications. Whether you're a beginner or an experienced programmer, mastering OOP will undoubtedly enhance your ability to write clean, efficient, and future-proof code.

Why is OOPs required?

1. Modularity: OOPs promotes modular design, where the program is divided into smaller, reusable components (objects), making it easier to develop, maintain, and modify the code.

2. Code Reusability: Through inheritance, objects can reuse code from existing classes, reducing redundancy and promoting code reuse.

3. Data Abstraction: OOPs allows for data abstraction, which means that the implementation details of an object are hidden from the outside world, providing better security and flexibility.

4. Encapsulation: By encapsulating data and methods within objects, OOPs provides better control over data access and modification, improving code organization and security.

5. Polymorphism: Polymorphism allows objects of different classes to be treated as objects of a common superclass, enabling more flexible and extensible code.

6. Maintainability: OOPs promotes modularity, which makes it easier to identify and fix errors, as well as add new features or modify existing ones, improving code maintainability.

7. Real-world Modeling: OOPs provides a way to model real-world objects and their interactions, making it easier to understand and design complex systems.

Class

A class is a blueprint or template for creating objects. It defines a set of properties (attributes) and behaviors (methods) that objects of that class will have. Classes are the fundamental building blocks of Object-Oriented Programming (OOP).

A class is a user-defined data type that encapsulates data (attributes) and code (methods) that operate on that data.

Example:-

public class BankAccount {
    // Attributes (Properties)
    private String accountNumber;
    private String accountHolderName;
    private double balance;

    // Constructor
    public BankAccount(String accountNumber, String accountHolderName, 
                           double initialBalance) {
        this.accountNumber = accountNumber;
        this.accountHolderName = accountHolderName;
        this.balance = initialBalance;
    }

    // Methods (Behaviors)
    public void deposit(double amount) {
        balance += amount;
        System.out.println(
            "Deposited $" + amount + ". New balance: $" + balance);
    }

    public void withdraw(double amount) {
        if (balance >= amount) {
            balance -= amount;
            System.out.println(
                "Withdrew $" + amount + ". New balance: $" + balance);
        } else {
            System.out.println("Insufficient funds.");
        }
    }

    // Getter and Setter methods for attributes
    // ...
}

In this example, the BankAccount class has three attributes (accountNumber, accountHolderName, and balance) that define the state of a bank account object. It also has a constructor that initializes these attributes when creating a new BankAccount object. Additionally, the class has two methods (deposit() and withdraw()) that define the behavior of a bank account object.

Components of a Class:

1. Modifiers: These specify the access level of the class, such as public, private, protected, or default (no modifier).

2. Class Name: The name of the class, following the naming conventions (e.g., BankAccount).

3. Superclass (if any): If the class inherits from another class, the name of the superclass is specified using the extends keyword.

4. Interfaces (if any): If the class implements one or more interfaces, they are specified using the implements keyword.

5. Body: The class body is enclosed within curly braces { }, containing the class members (attributes and methods).

Object

An object is an instance of a class. It is a real-world entity that has its own state (attributes) and behavior (methods) defined by the class it belongs to.

An object is a single instance of a class that encapsulates data and the code that operates on that data.

Example:-

BankAccount account1 = new BankAccount("123456789", "John Doe", 1000.0);
BankAccount account2 = new BankAccount("987654321", "Jane Smith", 5000.0);

account1.deposit(500.0); // Output: Deposited $500.0. New balance: $1500.0
account2.withdraw(1000.0); // Output: Withdrew $1000.0. New balance: $4000.0

In this example, account1 and account2 are two separate objects of the BankAccount class, each with its own set of attribute values (accountNumber, accountHolderName, and balance). We can invoke the deposit() and withdraw() methods on these objects, and they will behave according to their respective states.

Components of an Object:

1. State: The state of an object is defined by its attributes or properties (e.g., accountNumber, accountHolderName, and balance in the BankAccount class).

2. Behavior: The behavior of an object is defined by its methods (e.g., deposit() and withdraw() in the BankAccount class).

3. Identity: Each object has a unique identity, which is typically represented by its memory address or reference.

Major Pillars of OOPs

Abstraction

Abstraction is the process of hiding unnecessary details and exposing only the essential features of an object. It allows you to define the interface (how an object should behave) without revealing the implementation details (how the object works internally).

Abstraction is a way of representing complex real-world entities in a simplified manner by focusing on their essential features and ignoring unnecessary details.

Example:-

public class Main {
    public static void main(String[] args) {
        Animal dog = new Dog("Buddy");
        System.out.println("Name: " + dog.getName()); // Output: Name: Buddy
        dog.makeSound(); // Output: Woof!
    }
}

abstract class Animal {
    private String name;

    public Animal(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public abstract void makeSound();
}

class Dog extends Animal {
    public Dog(String name) {
        super(name);
    }

    @Override
    public void makeSound() {
        System.out.println("Woof!");
    }
}

In this example, the Animal class is an abstract class that defines the common behavior of animals (e.g., having a name) but leaves the implementation of makeSound() to its concrete subclasses (e.g., Dog). The Dog class provides the implementation for the makeSound() method.

Encapsulation

Encapsulation is the bundling of data (properties) and methods (behaviors) together within a single unit, known as a class. It helps in achieving data abstraction and controlling the access to the object's internal state.

Encapsulation is the mechanism of binding data and the code that operates on that data into a single unit, known as a class. It restricts direct access to the object's internal state and provides controlled access through public methods.

Example:-

public class Main {
    public static void main(String[] args) {
        BankAccount account = new BankAccount();
        System.out.println("Initial balance: " + account.getBalance()); // Output: Initial balance: 0.0

        account.deposit(1000.0);
        System.out.println("Balance after deposit: " + account.getBalance()); // Output: Balance after deposit: 1000.0

        account.withdraw(500.0);
        System.out.println("Balance after withdrawal: " + account.getBalance()); // Output: Balance after withdrawal: 500.0

        account.withdraw(600.0); // Output: Insufficient funds.
    }
}

class BankAccount {
    private double balance;

    public double getBalance() {
        return balance;
    }

    public void deposit(double amount) {
        balance += amount;
    }

    public void withdraw(double amount) {
        if (balance >= amount)
            balance -= amount;
        else
            System.out.println("Insufficient funds.");
    }
}

In this example, the BankAccount class encapsulates the balance field by making it private and providing public methods (getBalance, deposit, and withdraw) to access and modify the balance in a controlled manner.

Inheritance

Inheritance is a mechanism that allows a new class (child or derived class) to be based on an existing class (parent or base class). The child class inherits properties and methods from the parent class, promoting code reuse and enabling the creation of hierarchical relationships.

Inheritance is a concept in OOP that allows a new class (derived class) to inherit properties and behaviors from an existing class (base class), forming an "is-a" relationship between the classes.

Example:-

public class Main {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle("Toyota", "Corolla");
        vehicle.start(); // Output: Vehicle started.

        Car car = new Car("Honda", "Civic", 4);
        car.start(); // Output: Vehicle started.
        car.openTrunk(); // Output: Trunk opened.
    }
}

class Vehicle {
    protected String make;
    protected String model;

    public Vehicle(String make, String model) {
        this.make = make;
        this.model = model;
    }

    public void start() {
        System.out.println("Vehicle started.");
    }
}

class Car extends Vehicle {
    private int numDoors;

    public Car(String make, String model, int numDoors) {
        super(make, model);
        this.numDoors = numDoors;
    }

    public void openTrunk() {
        System.out.println("Trunk opened.");
    }
}

In this example, the Car class inherits from the Vehicle class. It inherits the make, model, and start() method from the Vehicle class and adds its own numDoors attribute and openTrunk() method.

Polymorphism

Polymorphism is a concept in OOP that allows objects of different classes to be treated as objects of a common superclass, enabling code reusability and flexibility. It can be achieved through method overriding (runtime polymorphism) or method overloading (compile-time polymorphism).

Runtime Polymorphism (Method Overriding)

Runtime polymorphism, also known as method overriding, occurs when a subclass provides its own implementation of a method that is already defined in its superclass.

Example:-

class Animal {
    public void makeSound() {
        System.out.println("Animal sound");
    }
}

class Dog extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Woof!");
    }
}

class Cat extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Meow!");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal animal1 = new Animal();
        Animal animal2 = new Dog();
        Animal animal3 = new Cat();

        animal1.makeSound(); // Output: Animal sound
        animal2.makeSound(); // Output: Woof!
        animal3.makeSound(); // Output: Meow!
    }
}

In this example, the Dog and Cat classes override the makeSound() method of the Animal class, exhibiting runtime polymorphism. The makeSound() method behaves differently based on the actual object type (Animal, Dog, or Cat) at runtime.

Rules:-

• Methods of child and parent class must have the same name.

• Methods of child and parent class must have the same parameters.

• IS-A relationship is mandatory (inheritance).

• One cannot override the private methods of a parent class.

• One cannot override Final methods.

• One cannot override static methods.

Compile-time Polymorphism (Method Overloading)

Compile-time polymorphism, also known as method overloading, occurs when a class has multiple methods with the same name but different parameter lists (different number of parameters, different types of parameters, or both).

Example:-

public class Main {
    public static void main(String[] args) {
        Calculator calculator = new Calculator();

        int sum1 = calculator.add(2, 3); // Output: 5
        double sum2 = calculator.add(2.5, 3.7); // Output: 6.2
        int sum3 = calculator.add(1, 2, 3); // Output: 6
    }
}

class Calculator {
    public int add(int a, int b) {
        return a + b;
    }

    public double add(double a, double b) {
        return a + b;
    }

    public int add(int a, int b, int c) {
        return a + b + c;
    }
}

In this example, we create an instance of the Calculator class and call different overloaded versions of the add() method. The compiler determines the correct method to call based on the number and types of arguments provided, demonstrating compile-time polymorphism.

Types:-

• By changing number of parameters

• By changing data type of any parameter

• By changing sequence of parameters

Minor Pillars of OOPs

Typing

In a strongly typed language like Java, every variable and expression must have a well-defined data type. The compiler enforces type safety by ensuring that operations are performed only on compatible data types. This helps catch type-related errors at compile-time, making the code more robust and reliable.

Example:-

int age = 25; // Valid
age = "thirty"; // Compiler error: Incompatible types

String name = "John";
int length = name.length(); // Valid

In the above example, the variable age is declared as an int, so you cannot assign a string value like "thirty" to it. The compiler will raise an error. However, you can call the length() method on the String object name and assign the result (an int value) to the length variable.

Persistance

Persistence refers to the ability of an object to survive beyond the lifetime of the program or process that created it. In other words, persistent objects can be stored and retrieved from non-volatile storage, such as a file system or a database, without losing their state.

Example:-

Consider a Student class that represents a student's information:

public class Student {
    private String name;
    private int age;
    private double gpa;

    // Constructors, getters, and setters
}

To make Student objects persistent, you can use serialization, which is the process of converting an object's state to a byte stream that can be saved to a file or sent over a network. Java provides built-in support for serialization through the Serializable interface.

import java.io.*;

public class PersistenceExample {
    public static void main(String[] args) {
        Student student = new Student("John", 20, 3.8);

        // Serialize the object to a file
        try (ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("student.dat"))) {
            oos.writeObject(student);
        } catch (IOException e) {
            e.printStackTrace();
        }

        // Later, deserialize the object from the file
        Student deserializedStudent = null;
        try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream("student.dat"))) {
            deserializedStudent = (Student) ois.readObject();
        } catch (IOException | ClassNotFoundException e) {
            e.printStackTrace();
        }

        // The deserializedStudent object has the same state as the original student object
        System.out.println(deserializedStudent.getName()); // Output: John
        System.out.println(deserializedStudent.getAge()); // Output: 20
        System.out.println(deserializedStudent.getGpa()); // Output: 3.8
    }
}

In this example, a Student object is serialized to a file named student.dat. Later, the object is deserialized from the same file, and its state is preserved, allowing you to work with the same object even after the program has terminated and restarted.

Concurrency

Concurrency refers to the ability of multiple computations or threads to execute simultaneously and potentially interact with each other.

In Java, you can create and manage threads to achieve concurrency. However, concurrent access to shared resources (e.g., objects or data structures) can lead to race conditions and other synchronization issues.

Example:-

Consider a BankAccount class that represents a bank account with a balance:

public class BankAccount {
    private double balance;

    public BankAccount(double initialBalance) {
        this.balance = initialBalance;
    }

    public synchronized void deposit(double amount) {
        double newBalance = balance + amount;
        // Simulate a delay to illustrate the potential for race conditions
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        balance = newBalance;
    }

    public synchronized void withdraw(double amount) {
        double newBalance = balance - amount;
        // Simulate a delay to illustrate the potential for race conditions
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        balance = newBalance;
    }

    public double getBalance() {
        return balance;
    }
}

Now, let's create two threads that both try to deposit and withdraw money from the same BankAccount object:

public class ConcurrencyExample {
    public static void main(String[] args) {
        BankAccount account = new BankAccount(1000.0);

        Runnable depositTask = () -> {
            for (int i = 0; i < 1000; i++) {
                account.deposit(10.0);
            }
        };

        Runnable withdrawTask = () -> {
            for (int i = 0; i < 1000; i++) {
                account.withdraw(10.0);
            }
        };

        Thread depositThread = new Thread(depositTask);
        Thread withdrawThread = new Thread(withdrawTask);

        depositThread.start();
        withdrawThread.start();

        try {
            depositThread.join();
            withdrawThread.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println("Final balance: " + account.getBalance());
    }
}

In this example, two threads (depositThread and withdrawThread) are created to perform 1000 deposit and withdrawal operations, respectively, on the same BankAccount object. Without proper synchronization, the balance may not be accurately updated due to race conditions.

To prevent race conditions, the deposit() and withdraw() methods in the BankAccount class are marked as synchronized. This ensures that only one thread can execute these methods at a time, preventing concurrent access to the balance field and ensuring data consistency.

When you run this program, the final balance printed should be 1000.0 (the initial balance), since the number of deposits and withdrawals is equal.

These examples illustrate how Java's strong typing, persistence capabilities, and concurrency support help in building robust and reliable applications. Strong typing enforces type safety, persistence allows objects to survive beyond program execution, and concurrency enables parallel execution while providing mechanisms to handle shared resources safely.

Conclusion

Throughout this blog, we've explored the fundamental concepts that underpin Object-Oriented Programming (OOP). We've delved into the building blocks of OOP, such as classes and objects, and how they enable the creation of modular, reusable, and extensible code.

We've examined the principles of abstraction and encapsulation, which provide a structured approach to managing complexity and ensuring data integrity. Abstraction allows us to focus on the essential features of an object, while encapsulation protects an object's internal state from unintended modifications.

Inheritance, a powerful mechanism in OOP, enables code reuse and the creation of hierarchical class relationships. By inheriting properties and methods from existing classes, we can create more specialized classes that extend and enhance the functionality of their parent classes.

Polymorphism, both compile-time and runtime, adds flexibility to our code by allowing objects of different classes to be treated as objects of a common superclass. This versatility enables methods to work with a wide range of object types without needing to know their specific implementations.

We've also explored the concept of strong typing, which enforces type safety and helps catch errors during compilation, leading to more robust and reliable code.

Additionally, we've discussed persistence, which allows objects to persist beyond the lifetime of the program, enabling data storage and retrieval across multiple sessions.

Finally, we've touched upon concurrency, a crucial aspect of modern software development, where multiple threads or processes can execute simultaneously, facilitating efficient utilization of system resources and improving application responsiveness.

By mastering these OOP concepts and applying them effectively, developers can create software that is not only functional but also maintainable, scalable, and adaptable to changing requirements. OOP provides a solid foundation for building complex systems, fostering collaboration, and promoting code reuse across projects.

As we continue our journey in OOP, remember to embrace best practices, such as writing clean and self-documenting code, adhering to design patterns, and leveraging the power of object-oriented principles to create efficient and elegant solutions.

Introduction

Embarking on the AWS Free Tier journey, I set out to weave a tapestry of technology by deploying a full-stack application, combining the power of MySQL, Spring, and React. This blog serves as a chronicle of my exploration into the world of cloud computing, where budget constraints met the ambition to create a robust and dynamic web application.

In the realm of databases, I opted for Amazon RDS to host my MySQL database, leveraging its managed services to streamline administration tasks. On the backend, an EC2 instance powered by Spring provided the backbone for my application's logic and data processing. For the frontend, the user interface found its home on AWS Amplify, simplifying the deployment of my React application with a focus on scalability and ease of use.

This journey wasn't just about deploying code; it was a navigation through the intricate landscape of AWS services, striking a balance between functionality and frugality. Join me as I unravel the threads of my experience, sharing the triumphs, challenges, and lessons learned in the pursuit of a fully functional, cost-effective full-stack application on the AWS Free Tier. Let this be a guide for those venturing into the cloud, where innovation meets the constraints of a tight budget. Welcome to the story of MySQL, Spring, and React on AWS Free Tier.

AWS Services used

For the database, I chose Amazon RDS (Relational Database Service) to manage the MySQL database. RDS simplifies database management with automated backups, patching, and scalability features. The benefits include reduced operational overhead, easy scalability, and enhanced security through encryption. However, the AWS Free Tier imposes limitations on instance types and storage, which may require monitoring to avoid additional charges.

On the server side, Amazon EC2 (Elastic Compute Cloud) was employed for hosting the Spring application on a docker container. EC2 provides scalable compute capacity with full control over virtual machines. This allows customization and flexibility in choosing instance types based on application needs. While the AWS Free Tier offers limited hours of t2.micro instances per month, additional charges may apply for data transfer and storage beyond the allotted limits.

For the frontend, AWS Amplify was selected to streamline React application deployment. Amplify simplifies the development process with automatic deployment, hosting on a global CDN, and a user-friendly CI/CD pipeline. Its benefits include quick setup and integration with other AWS services. However, limitations in build minutes and storage on the Free Tier, along with potential charges for data transfer out of the hosting environment, should be considered when utilizing Amplify for hosting the frontend.

Architecture

Our application's architecture is a sophisticated ecosystem designed for seamless interaction between its integral parts. The backbone of our backend data storage is the MySQL database hosted on Amazon RDS, offering scalability and managed services. Meanwhile, the application's logic resides in a Spring backend, encapsulated within a Docker container on an EC2 instance. This environment is orchestrated by Docker, intricately configuring the MySQL and the Spring application to communicate flawlessly over the EC2 and RDS.

The orchestration reaches its crescendo with the Continuous Integration and Continuous Deployment (CI/CD) workflow facilitated by GitHub Actions. Whenever code changes are pushed to our GitHub repository, the orchestrated symphony begins. A self-hosted runner on the EC2 instance takes center stage, fetching the latest changes and seamlessly updating our Spring backend. This ensures that our backend remains cutting-edge with every push.

Simultaneously, the frontend undergoes a transformation of its own. The React frontend code, residing in our GitHub repository, is automatically deployed to AWS Amplify, a platform offering scalable and managed hosting for our frontend. This dynamic deployment process guarantees that our users experience the most up-to-date version of our application without any manual intervention.

The Github Actions will utilize 3 workflows. First for Continuous Integration which will be triggered on every push to the repository, second for building the back-end app docker image and pushing it to our private dockerhub repository and the last one for continuous delivery which will begin execution when the second workflow completes execution. The continuous delivery workflow will be run on a self-hosted runner which will be running on the ec2 instance. It will pull the lastest uploaded backend app image and run it in a container.

In essence, this intricate dance of technologies integrates AWS services, Docker containerization, and robust CI/CD practices into a harmonious system. Each component plays a crucial role, contributing to the continuous deployment and enhancement of our full-stack application. This carefully orchestrated architecture not only ensures a smooth and automated workflow but also lays the foundation for a scalable and efficient application ecosystem.

Repository Structure

Link - https://github.com/saurabhthecodewizard/opus

This is how the folder structure will look like for this example.

1. The server folder will have spring application code.

2. The client folder will have react app code.

3. The .github/workflows will have the CI/CD workflows

RDS Setup for Database

1. Navigate to the AWS Management Console and open the Amazon RDS dashboard.

2. Click on the "Create database" button.

3. Choose the "Standard create" method.

4. In the "Engine options" section, select "MySQL" as the database engine and choose the latest engine version available.

5. Under "Templates," select "Free Tier" to ensure the usage falls within the free tier limits.

6. Provide a unique DB instance identifier of your choice.

7. Set a username and password for the database credentials, as these will be needed for connecting to the database.

8. Choose the "db.t4g.micro" instance type under "Free tier" to stay within the free tier limits.

9. For storage, select "gp2" as the storage type and select 20 GB storage since 20 GB is allocated for free tier, and uncheck the "Enable storage auto scaling" option.

10. In the "Connectivity" section, choose "Don't connect to an EC2 compute resource" and allow public access, as the database will be accessed locally and later from the EC2 instance.

11. Select the security group with EC2, RDS and AdministratorAccess.

12. Under the "Database authentication" section, choose "Password authentication."

13. In the "Additional configuration" section, uncheck "Automated backups," "Encryption," and "Minor version upgrade."

14. It may show you estimated cost, but we should be good as long as we are on free tier.

15. Finally, click on the "Create database" button to initiate the creation of the MySQL RDS instance.

Development Setup

1. Develop a Spring application in the server folder with a simple API fetching data from the database, using the RDS database configuration (The RDS database url can be take from endpoint from RDS instance details and the username and password should be the one you setup during the RDS instance creation).

2. This project uses flyway migrations for versioning the database. More information can be found here - https://www.baeldung.com/database-migrations-with-flyway

# application.properties

# Database configuration
spring.datasource.url=${SPRING_DATASOURCE_URL}
spring.datasource.username=${SPRING_DATASOURCE_USERNAME}
spring.datasource.password=${SPRING_DATASOURCE_PASSWORD}
spring.jpa.show-sql=true
# Flyway configuration
spring.flyway.baseline-on-migrate=true
spring.flyway.locations=classpath:db/migration

1. I have added a clients table and a single entity to it in the migration.

-- V1697817392__add_opus_to_clients.sql
CREATE TABLE clients (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    create_date DATE,
    status TINYINT(1), -- 1 for true (active), 0 for false (inactive)
    website VARCHAR(255),
    picture_url VARCHAR(255)
);

INSERT INTO clients (name, create_date, status, website, picture_url)
VALUES ('Opus', '2023-10-20', 1, 'https://www.opus.com', 'https://www.opus.com/image.jpg');

1. Add an endpoint for us to test the application

// Controller.java

@GetMapping("/")
public ClientDTO getOpus() {
    return clientService.getClientById(1L);
}

The api should be working now which will fetch our client entity from the rds instance

Docker Setup - Backend

1. Create a Dockerfile to ./server directory.

# ./server/Dockerfile
# Use the Maven 3.9.5 image as the build environment
FROM maven:3.9.5 AS build

# Set the working directory within the container to /app
WORKDIR /app

# Copy the content of the current directory into the /app directory in the container
COPY . .

# Run Maven to clean and install dependencies
RUN mvn clean install

# Use the OpenJDK 21 image as the base image for the final container
FROM openjdk:21

# Set the working directory within the container to /app
WORKDIR /app

# Copy the compiled JAR file from the build stage to the /app directory in the final container
COPY --from=build /app/target/*.jar server.jar

# Expose port 8080 to allow external connections
EXPOSE 8080

# Define the default command to run the Java application
CMD ["java", "-jar", "server.jar"]

You can test this by running the image locally by the following commands in the ./server directory

1. Build the server image

docker build -t server .

1. You can see if the image is built successfully by running docker image ls or in docker desktop app.

2. Run the image in container with appropriate port mapping and appropriate environment variables in the command

docker run -d -p 8080:8080 -e SPRING_DATASOURCE_URL=${DB_URL} -e SPRING_DATASOURCE_USERNAME=${DB_USERNAME} -e SPRING_DATASOURCE_PASSWORD=${DB_PASSWORD} -e SPRING_MAIL_USERNAME=${SPRING_MAIL_USERNAME} -e SPRING_MAIL_PASSWORD=${SPRING_MAIL_PASSWORD} --name server-container server

You can see the container running docker container ls or in the docker desktop app.

Github Secrets

Add the following github secrets which we will be using in our workflows for CI/CD as shown in the picture below.

Github Actions Setup

We will be creating 3 files in the .github/workflows directory.

1. Continuous Integration - server-intergartion.yml :-

   This GitHub Actions workflow file named "Server Integration" is triggered on each push event. The workflow runs on the latest version of Ubuntu and is configured to execute within the 'server/' directory. It sets environment variables for sensitive information such as database connection details and email credentials using GitHub Secrets. The workflow consists of three main steps: it checks out the source code, sets up Java 17 using the Temurin distribution, and builds the project using Maven. The Maven build command includes parameters for configuring the Spring datasource URL, username, password, as well as the email username and password, all sourced from the environment variables. This workflow is designed for integrating and building a Java server application with secure and customizable database and email configurations.

    # .github/workflows/server-intergartion.yml
   
    name: Server Integration
   
    on: [push]
   
    jobs:
   
      build:
   
        runs-on: ubuntu-latest
        defaults:
          run:
            working-directory: server/
        env:
            DB_URL: ${{ secrets.DB_URL }}
            DB_USERNAME: ${{ secrets.DB_USERNAME }}
            DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
            SPRING_MAIL_USERNAME: ${{ secrets.SPRING_MAIL_USERNAME }}
            SPRING_MAIL_PASSWORD: ${{ secrets.SPRING_MAIL_PASSWORD }}
        steps:
        - name: Checkout source
          uses: actions/checkout@v3
        - name: Setup Java
          uses: actions/setup-java@v3
          with:
            distribution: 'temurin'
            java-version: '17'
        - name: Build Project
          run: mvn clean install -D spring.datasource.url=${DB_URL} -D spring.datasource.username=${DB_USERNAME} -D spring.datasource.password=${DB_PASSWORD} -D spring.mail.username=${SPRING_MAIL_USERNAME} -D spring.mail.password=${SPRING_MAIL_PASSWORD} -B
   

2. Server Build - server-build.yml :-

   This GitHub Actions workflow file, named "Server Build," is configured to run on a manual workflow_dispatch event. The workflow is designed to build a Java server application and deploy it as a Docker image to Docker Hub. It runs on the latest version of Ubuntu, within the 'server/' directory. It utilizes environment variables, sourced from GitHub Secrets, for sensitive information such as Docker Hub credentials, database connection details, and email credentials. The workflow includes several steps: it checks out the source code, sets up Java 17 using the Temurin distribution, builds the project with Maven, logs in to Docker Hub, builds a Docker image tagged as 'skmahajan4998/opus-app:latest,' pushes the image to Docker Hub, and finally, deletes dangling Docker images to free up space. This workflow automates the process of building and deploying the server application with Docker, ensuring secure and efficient deployment practices.

    # .github/workflows/server-build.yml
   
    name: Server Build
   
    on: workflow_dispatch
   
    jobs:
   
      build:
   
        runs-on: ubuntu-latest
        defaults:
          run:
            working-directory: server/
        env:
          DOCKER_USERNAME: ${{secrets.DOCKER_USERNAME}}
          DOCKER_PASSWORD: ${{secrets.DOCKER_PASSWORD}}
          DB_URL: ${{ secrets.DB_URL }}
          DB_USERNAME: ${{ secrets.DB_USERNAME }}
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
        steps:
        - name: Checkout source
          uses: actions/checkout@v3
        - name: Setup Java
          uses: actions/setup-java@v3
          with:
            distribution: 'temurin'
            java-version: '17'
        - name: Build Project
          run: mvn clean install -D spring.datasource.url=${DB_URL} -D spring.datasource.username=${DB_USERNAME} -D spring.datasource.password=${DB_PASSWORD} -B
        - name: Login Dockerhub
          run: docker login -u $DOCKER_USERNAME -p $DOCKER_PASSWORD
        - name: Build the Docker image
          run: docker build -t skmahajan4998/opus-app .
        - name: Push to Dockerhub
          run: docker push skmahajan4998/opus-app:latest
        - name: Delete Dangling docker images
          run: docker image prune -f
   

3. Continuous Deployment - server-deploy.yml :-

   This GitHub Actions workflow file, named "Server Deploy," is triggered on the completion of the "Server Build" workflow. It runs on a self-hosted runner which will be hosted on our ec2 instance and is responsible for pulling the latest Docker image of the server application from Docker Hub, stopping and removing any existing container with the name 'opus-app-container,' and then running a new container with the pulled image. The environment variables for database connection details and email credentials are provided to the Docker container during the run. Specifically, the Docker container is started in detached mode (-d), mapped to port 8080 on the host, and named 'opus-app-container.' This workflow facilitates the deployment of the server application by updating the running container with the latest version of the application, ensuring a smooth and automated deployment process after the successful completion of the build workflow.

    # 
    name: Server Deploy
   
    on:
      workflow_run:
        workflows: ["Server Build"]
        types:
          - completed
   
    jobs:
   
      pull:
        runs-on: self-hosted
        env:
          DB_URL: ${{ secrets.DB_URL }}
          DB_USERNAME: ${{ secrets.DB_USERNAME }}
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
        steps:
        - name: Pull Docker Image
          run: sudo docker pull skmahajan4998/opus-app:latest
        - name: Delete Old Docker Container
          run: sudo docker rm -f opus-app-container || true
        - name: Run Docker Container
          run: sudo docker run -d -p 8080:8080 -e SPRING_DATASOURCE_URL=${DB_URL} -e SPRING_DATASOURCE_USERNAME=${DB_USERNAME} -e SPRING_DATASOURCE_PASSWORD=${DB_PASSWORD} --name opus-app-container skmahajan4998/opus-app
   

EC2 setup for back-end

1. Sign in to the AWS Management Console.

2. Open the EC2 dashboard.

3. Click on the "Instances" link in the left navigation pane.

4. Click the "Launch Instances" button.

5. Select Ubuntu Server

1. Select t2.micro to stay in the free tier

1. Create a Key pair of .pem type so we can login through SSH

1. Allow HTTP/HTTPS traffic from internet.

2. Launch the instance.

3. Change the inbound rules as given below

Github Runner setup on EC2

1. Navigate to .pem file

    cd /path/to/directory/with/pem/file
   

2. Connect to EC2 instance through SSH client

   Replace your-instance-ip with the actual public IP address of your EC2 instance and your-key-file.pem with the name of your .pem file. You can find this command when you click on connect instance and navigate to SSH client on AWS management console.

    chmod 400 "your-key-file.pem"
    ssh -i "your-key-file.pem" ubuntu@your-instance-ip
   

   If there are no errors, you should successfully establish a connection to your EC2 instance.

3. Update the package list on your EC2 instance

    sudo apt update
   

4. Upgrade the installed packages on your EC2 instance. The -y flag automatically confirms the upgrade.

    sudo apt-get upgrade -y
   

   The upgrade process should now be complete, and your EC2 instance is up-to-date.

5. Create Github Runner

   • Navigate to Github Repository -> Settings -> Actions -> Runners.

   • Click on Add a runner and select linux OS

   • You should be able to see commands in 2 sections, namely, Download and Configure

   • Ensure that you have Github secrets setup as shown in the Github Secrets section

6. Run all the commands provided through the Downlaod and Configure section of the github runner on our EC2 instance that we previously connected through SSH client.

7. Run the ./run.sh script in the background using the & operator to keep the process running in the background while freeing up the terminal.

8. Confirm runner connection

   • Go back to your GitHub repository.

   • Navigate to Settings -> Actions -> Runners.

   • Refresh the page to check if the runner is connected.

   • The runner status should show as Idle with a green dot, indicating that it is ready to execute workflows.

   • You can also check the terminal where you ran the runner script to ensure there are no errors and that the runner is connected successfully.

   • Your GitHub Runner should now be set up, configured, and connected to your repository. It is ready to execute workflows when triggered.

9. Install Docker on EC2 instance

   • Run the commands provided on the documentation - https://docs.docker.com/engine/install/ubuntu/

   • Login to docker with your credentials

       sudo docker login
     

   • No containers will be present currently. You can check by the below command.

       sudo docker ps
     

10. Trigger the CI/CD flow

• Push our code to the repository (This should automatically trigger the Server Build workflow).

• Trigger the Server Build workflow manually through github actions.

  

• The successful completion of Server Build workflow should automatically trigger the Server Deploy workflow.
  Note: If you have any errors in the server build or server integration, you will have to solve those locally and then trigger the CI/CD again.

• Your latest server build should now be successfully deployed on the EC2 instance and you can check by triggering the api we provided.

    curl 0.0.0.0:8080/
  

• You can also check the depoloyment by calling the api through browser with appropriate url. You can get the public IP from instance details and the rest of the api url as you configured in the spring application.

  

Setup nginx server on EC2 for proxy

Run the following commands on EC2 instance

1. Install nginx

    sudo apt update
    sudo apt install -y nginx
   

2. Get Docker container IP
   Find the IP address of your Docker container using the following command. Replace containerId with the actual ID. You can find the docker container id by running docker container ps.

    docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' containerId
   

3. Navigate to nginx sites-available directory

    cd /etc/nginx/sites-available/
   

4. Edit the default configuration

    sudo nano default
   

5. In the location / { ... } block, add the following line with the appropriate IP address and port:

    location / {
        proxy_pass http://172.17.0.2:8080;  # Replace with your Docker container's IP and port
        # Other proxy settings can be added here if needed
    }
   

6. Restart nginx

    sudo systemctl restart nginx
   

7. Check the Nginx configuration for syntax errors

    sudo nginx -t
   

   If there are no errors, you should see nginx: configuration file /etc/nginx/nginx.conf test is successful.

8. Nginx is now configured as a reverse proxy for your Docker container. Requests to the Nginx server will be forwarded to the Docker container. Make sure to replace the placeholder IP address and port with the actual values from step 2.

Setup HTTPS on EC2

You can setup HTTPS on EC2 if you have custom domain. Follow this process if you do not have custom domain.

1. Now, install Caddy on the server. Instructions can be found here. Caddy 2 is a powerful open source web server with automatic HTTPS. Caddy simplifies your infrastructure and takes care of TLS certificate renewals.

    yum install yum-plugin-copr
    yum copr enable @caddy/caddy
    yum install caddy
   

2. Next we'll create a Caddyfile with the following contents(Insert your ec2 public ip).

    <EC2 Public IP>.nip.io {
        reverse_proxy localhost:8080
    }
   

   Over here, we are using nip.io as a DNS. nip.io allows you to map any IP Address to a hostname without the need to edit a hosts file or create rules in DNS management. nip.io maps .nip.io in "dot", "dash" or "hexadecimal" notation to the corresponding .

   What we are doing here is basically setting up a proxy to forward all requests to port 8000 of our instance. Save the file as Caddyfile and run the command caddy run.

   This will start Caddy certificate management service and download a certificate for the indentifier <IP>.nip.io.

   Now if you go to your address <IP>.nip.io with the ec2 url in the browser you'll see that the connection is secure and the browser no longer complains about insecure connections.

   If you want to run Caddy in background all you have to do is run caddy start.

   

Front-end setup on AWS Amplify

1. Create a basic react app and consume the api we created in the Spring application with the ec2 URL

2. Navigate to AWS Amplify on AWS management console.

3. New app -> Host a web app

4. Select Github

5. Authorize the repository -> Select your repository -> Select your branch

6. (Optional) -> If the frontend application is not in the root directory, mention the correct directory of the app in the folder section

7. Next -> Next -> Save and Deploy

Note: You may need to make changes to the build commands or your react app based on the packages and libraries you are using

1. You can setup the backend url in environment variables in amplify if you want

2. Your app is now live

Conclusion

In conclusion, the journey of deploying a full-stack application on AWS Free Tier was a dynamic exploration that delved into the intricacies of cloud architecture and development. The experience not only involved the successful deployment of MySQL on RDS, Spring on EC2, and React on AWS Amplify but also incorporated a streamlined CI/CD pipeline. The backend server benefited from GitHub Actions, ensuring continuous integration and deployment, while AWS Amplify seamlessly handled the CI/CD for the frontend.

As I reflect on the project, it's clear that the CI/CD setup significantly contributed to the overall efficiency of development and deployment processes. GitHub Actions provided a robust solution for automating backend deployments, while AWS Amplify's integration with the frontend codebase streamlined the continuous delivery workflow. The synergy between these tools not only enhanced the development speed but also facilitated a more consistent and reliable release cycle.

While navigating through the intricacies of AWS services, I gained insights into best practices for cloud development, security considerations, and the critical role of scalability. The process wasn't without its hurdles, but each challenge presented an opportunity for growth and learning.

Sharing these experiences serves not only as a documentation of my journey but also as a guide for fellow developers venturing into the realm of AWS. By reflecting on the lessons learned and embracing the continuous learning ethos of cloud development, I believe the community can benefit from a shared knowledge pool that empowers developers to make informed decisions and build robust, scalable applications on AWS Free Tier.

This blog is your guide to unlocking Docker Compose's potential in building a fullstack app with MySQL, Spring Boot, and React. Docker Compose acts as the linchpin, streamlining the encapsulation, and management of each component.

We'll navigate setting up a development environment within Docker containers, explore the relationship between database design and Dockerized Spring Boot backends, and witness the magic of containerized React frontends. At every step, Docker Compose ensures cohesion and consistency across the development lifecycle.

Whether you're refining containerization skills or demystifying Docker, this blog empowers both seasoned developers and curious enthusiasts. Join us as we unravel Docker Compose's potential, elevating your fullstack development experience.

Fasten your seatbelt, and let’s sail through the realms of Docker Compose-driven fullstack development. 🚢✨

What are containers and how docker comes into picture?

Containers are lightweight, portable, and self-sufficient units that encapsulate software and its dependencies. They provide a consistent and isolated environment for running applications, allowing developers to package an application along with its dependencies, libraries, and runtime into a single container image. Containers are designed to be easily deployable across various environments, ensuring consistency from development to production.

Docker is a platform that enables the creation, deployment, and management of containers. It utilizes containerization technology to package applications and their dependencies into containers. Docker provides a set of tools and a runtime environment to build, ship, and run containers efficiently.

The typical Docker workflow involves creating a Dockerfile, which defines the steps to build a container image, and then using Docker commands to build, tag, and run containers based on that image. Docker Hub is a registry service provided by Docker, where container images can be stored and shared publicly or privately.

What does docker compose do?

Docker Compose is a tool for defining and running multi-container Docker applications. It allows you to define a multi-container environment using a simple YAML file, often named docker-compose.yml, and then use a single command to start and run the entire application stack. Docker Compose is particularly useful for managing the orchestration of complex applications that require multiple services and containers to work together.

Here are some key aspects and functionalities of Docker Compose:

1. Declarative Configuration: Docker Compose uses a declarative YAML file to define the services, networks, and volumes required for your application. This file specifies how containers should be configured and how they should interact.

2. Service Definition: Each containerized component of your application is defined as a service in the docker-compose.yml file. Services can include information such as the base Docker image, container name, ports to expose, environment variables, and more.

3. Networking: Docker Compose automatically creates a network for your services, allowing containers within the same docker-compose.yml file to communicate with each other using service names as hostnames.

4. Volume Sharing: You can define volumes in the docker-compose.yml file, enabling data persistence and sharing between containers. This is useful for scenarios where you want to persist data beyond the lifecycle of a single container.

5. Environment Variables: Docker Compose allows you to set environment variables for each service, making it easy to configure different aspects of your application without modifying the container images.

6. Orchestration and Scaling: Docker Compose simplifies the process of orchestrating multiple containers. You can start, stop, and scale your entire application with a single command. This makes it convenient for development, testing, and even production environments.

7. Ease of Use: Docker Compose provides a user-friendly command-line interface, making it accessible to both developers and system administrators. Common operations like starting, stopping, and inspecting the status of services are straightforward.

Pre-requisites

1. Install Docker

   • Windows

   • Mac

   • Ubuntu

2. Install Docker Compose if not already installed through the Docker installation above

    >docker -v 
    Docker version 24.0.7, build afdd53b
    >docker-compose -v
    Docker Compose version v2.23.3-desktop.2
   

3. Java & Maven - The example in this blog uses Java v21 and Maven v3.9.5

4. Node - The example in this blog uses node v18

5. The project structure used for the example in this blog is as follows:-

   docker-compose-demo

   |

   |____backend

   |

   |____frontend

Setup a spring application with docker configuration

1. Create a Spring project with appropriate dependencies like Spring Web, Spring Data JPA and MySQL Driver.

   

2. Insert your MySQL configuration in the application properties

    spring.datasource.url=jdbc:mysql://localhost:3306/product
    spring.datasource.username=product
    spring.datasource.password=password
    spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
    spring.jpa.hibernate.ddl-auto=update
   

    // Product.java
    @Entity
    public class Product {
   
        @Id
        @GeneratedValue(strategy = GenerationType.IDENTITY)
        private Long id;
        private String name;
        private double price;
   
        // constructors, getters and setters
    }
   

    // ProductController.java
   
    @RestController
    @RequestMapping("/api/products")
    @CrossOrigin("*")
    public class ProductController {
   
        private final ProductService productService;
   
        @Autowired
        public ProductController(ProductService productService) {
            this.productService = productService;
        }
   
        @GetMapping
        public List<ResponseProductDTO> getAllProducts() {
            return productService.getAllProducts();
        }
   
        @GetMapping("/{id}")
        public ResponseProductDTO getProductById(@PathVariable Long id) {
            return productService.getProductById(id);
        }
   
        @PostMapping
        public ResponseProductDTO saveProduct(@RequestBody RequestProductDTO product) {
            return productService.saveProduct(product);
        }
   
        @DeleteMapping("/{id}")
        public void deleteProduct(@PathVariable Long id) {
            productService.deleteProduct(id);
        }
    }
   

3. The back-end should be running at http://localhost:8080

Setup a React application with docker configuration

1. Create a react app and install axios to call apis

    npm create vite@latest .
    # Select React + TypeScript 
    npm install
    npm install axios
    npm run dev
   

2. The example in this blog uses a react project created by Vite, so we need to modify the vite.config.tsto run the app on fixed port 3000 in our machine as well as in the container. Ignore this step if you are not using vite.

    // vite.config.ts
    import { defineConfig } from 'vite'
    import react from '@vitejs/plugin-react'
   
    // https://vitejs.dev/config/
    export default defineConfig({
      plugins: [react()],
      server: {
        port: 3000
      },
      // To allow the host to be exposed from container
      preview: {
        host: true,
        port: 3000
      }
    })
   

3. Create a basic html table with Edit and Delete button for each row and add new product form below the table

    // App.tsx
    import { useEffect, useState } from 'react';
    import axios from 'axios';
   
    type Product = {
      id: number;
      name: string;
      price: number;
    };
   
    const App = () => {
      const apiUrl = 'http://localhost:8080/api/products';
   
      const [products, setProducts] = useState<Product[]>([]);
      const [newProductName, setNewProductName] = useState('');
      const [newProductPrice, setNewProductPrice] = useState('');
      const [editProductId, setEditProductId] = useState<number | null>(null);
      const [editProductName, setEditProductName] = useState('');
      const [editProductPrice, setEditProductPrice] = useState('');
   
      useEffect(() => {
        fetchProducts();
      }, []);
   
      const fetchProducts = async () => {
        try {
          const response = await axios.get(apiUrl);
          setProducts(response.data);
        } catch (error) {
          console.error('Error fetching products:', error);
        }
      };
   
      const addProduct = async () => {
        try {
          const response = await axios.post(apiUrl, {
            name: newProductName,
            price: parseFloat(newProductPrice),
          });
          setProducts((prevProducts) => [...prevProducts, response.data]);
          setNewProductName('');
          setNewProductPrice('');
        } catch (error) {
          console.error('Error adding product:', error);
        }
      };
   
      const deleteProduct = async (id: number) => {
        try {
          await axios.delete(`${apiUrl}/${id}`);
          setProducts((prevProducts) => prevProducts.filter((product) => product.id !== id));
        } catch (error) {
          console.error('Error deleting product:', error);
        }
      };
   
      const startEditingProduct = (id: number, name: string, price: number) => {
        setEditProductId(id);
        setEditProductName(name);
        setEditProductPrice(price.toString());
      };
   
      const cancelEditingProduct = () => {
        setEditProductId(null);
        setEditProductName('');
        setEditProductPrice('');
      };
   
      const updateProduct = async () => {
        try {
          await axios.put(`${apiUrl}/${editProductId}`, {
            name: editProductName,
            price: parseFloat(editProductPrice),
          });
          fetchProducts();
          cancelEditingProduct();
        } catch (error) {
          console.error('Error updating product:', error);
        }
      };
   
      return (
        <div style={{ display: 'flex', flexDirection: 'column', alignItems: 'center', justifyContent: 'center'}}>
          <h1 style={{ fontSize: '2rem', fontWeight: 'bold', marginBottom: '1rem' }}>Product List</h1>
          <table style={{ borderCollapse: 'collapse', width: '80%', margin: 'auto' }}>
            <thead>
              <tr style={{ borderBottom: '1px solid #ccc' }}>
                <th style={{ padding: '8px', textAlign: 'left' }}>ID</th>
                <th style={{ padding: '8px', textAlign: 'left' }}>Name</th>
                <th style={{ padding: '8px', textAlign: 'left' }}>Price</th>
                <th style={{ padding: '8px', textAlign: 'left' }}>Action</th>
              </tr>
            </thead>
            <tbody>
              {products.map((product) => (
                <tr key={product.id} style={{ borderBottom: '1px solid #ccc' }}>
                  <td style={{ padding: '8px', textAlign: 'left' }}>{product.id}</td>
                  {editProductId === product.id ? (
                    <>
                      <td style={{ padding: '8px', textAlign: 'left' }}>
                        <input
                          style={{ border: '1px solid #ccc', padding: '6px' }}
                          type="text"
                          value={editProductName}
                          onChange={(e) => setEditProductName(e.target.value)}
                        />
                      </td>
                      <td style={{ padding: '8px', textAlign: 'left' }}>
                        <input
                          style={{ border: '1px solid #ccc', padding: '6px' }}
                          type="text"
                          value={editProductPrice}
                          onChange={(e) => setEditProductPrice(e.target.value)}
                        />
                      </td>
                    </>
                  ) : (
                    <>
                      <td style={{ padding: '8px', textAlign: 'left' }}>{product.name}</td>
                      <td style={{ padding: '8px', textAlign: 'left' }}>{product.price}</td>
                    </>
                  )}
                  <td style={{ padding: '8px', textAlign: 'left' }}>
                    {editProductId === product.id ? (
                      <>
                        <button
                          style={{ backgroundColor: '#4CAF50', color: 'white', padding: '6px', borderRadius: '4px', marginRight: '4px' }}
                          onClick={updateProduct}
                        >
                          Update
                        </button>
                        <button
                          style={{ backgroundColor: '#ccc', padding: '6px', borderRadius: '4px' }}
                          onClick={cancelEditingProduct}
                        >
                          Cancel
                        </button>
                      </>
                    ) : (
                      <>
                        <button
                          style={{ backgroundColor: '#2196F3', color: 'white', padding: '6px', borderRadius: '4px', marginRight: '4px' }}
                          onClick={() =>
                            startEditingProduct(product.id, product.name, product.price)
                          }
                        >
                          Edit
                        </button>
                        <button
                          style={{ backgroundColor: '#f44336', color: 'white', padding: '6px', borderRadius: '4px' }}
                          onClick={() => deleteProduct(product.id)}
                        >
                          Delete
                        </button>
                      </>
                    )}
                  </td>
                </tr>
              ))}
            </tbody>
          </table>
          <div style={{ marginTop: '1rem' }}>
            <h2 style={{ fontSize: '1.5rem', fontWeight: 'bold', marginBottom: '0.5rem' }}>Add Product</h2>
            <label style={{ display: 'block', marginBottom: '0.5rem' }}>
              Name:
              <input
                style={{ border: '1px solid #ccc', padding: '6px' }}
                type="text"
                value={newProductName}
                onChange={(e) => setNewProductName(e.target.value)}
              />
            </label>
            <label style={{ display: 'block', marginBottom: '0.5rem' }}>
              Price:
              <input
                style={{ border: '1px solid #ccc', padding: '6px' }}
                type="text"
                value={newProductPrice}
                onChange={(e) => setNewProductPrice(e.target.value)}
              />
            </label>
            <button
              style={{ backgroundColor: '#2196F3', color: 'white', padding: '6px', borderRadius: '4px' }}
              onClick={addProduct}
            >
              Add Product
            </button>
          </div>
        </div>
      );
    };
   
    export default App;
   

4. The front-end should be running at http://localhost:3000

   Add some demo data to test the connection

   

Docker Compose Config

1. Create a Dockerfile in backend directory

    # Stage 1: Build the application using Maven
    FROM maven:3.9.5 AS build
   
    # Set the working directory within the container to /app
    WORKDIR /app
   
    # Copy all files from the current directory (.) to the container's working directory (/app)
    COPY . .
   
    # Run the Maven clean install command
    RUN mvn clean install
   
    # Stage 2: Create a lightweight container with only the necessary artifacts
    FROM openjdk:21
   
    # Set the working directory within the container to /app
    WORKDIR /app
   
    # Copy the built JAR file from the previous stage into the current stage
    COPY --from=build /app/target/*.jar server.jar
   
    # Expose port 8080 to allow external connections to the application
    EXPOSE 8080
   
    # Specify the command to run when the container starts - run the Java application using the JAR file
    CMD ["java", "-jar", "server.jar"]
   

2. Create a Dockerfile in frontend directory

    # Stage 1: Build the Node.js application
    FROM node:18-alpine as BUILD
   
    # Set the working directory within the container to /app
    WORKDIR /app
   
    # Copy package.json to the container's working directory
    COPY package.json .
   
    # Install dependencies based on package.json
    RUN npm install
   
    # Copy all files from the current directory (.) to the container's working directory (/app)
    COPY . .
   
    # Build the application
    RUN npm run build
   
    # Stage 2: Create a lightweight container for production
    FROM node:18-alpine as PROD
   
    # Set the working directory within the container to /app
    WORKDIR /app
   
    # Copy the build artifacts (dist folder) from the BUILD stage to the current stage
    COPY --from=BUILD /app/dist/ /app/dist/
   
    # Expose port 3000 to allow external connections to the application
    EXPOSE 3000
   
    # Copy package.json and vite.config.ts to the container's working directory
    COPY package.json .
    COPY vite.config.ts .
   
    # Install TypeScript
    RUN npm install typescript
   
    # Specify the command to run when the container starts - run the application in preview mode
    CMD [ "npm", "run", "preview" ]
   

3. Add a .dockerignore in the frontend directory to restrict node_modules directory to hold up space

    node_modules/
   

4. We can update the application.properties in the backend to support dynamic environment variables now.

    spring.datasource.url=${SPRING_DATASOURCE_URL}
    spring.datasource.username=${SPRING_DATASOURCE_USERNAME}
    spring.datasource.password=${SPRING_DATASOURCE_PASSWORD}
    spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
    spring.jpa.hibernate.ddl-auto=update
   

In the project source directory i.e. docker-compose-demo directory, we need to add a docker-compose.yml. The environment variables should be appropriately used in the docker-compose.yml and application.properties.

# Specify the version of the Docker Compose file format
version: '3.8'

# Define the services that will run in your application
services:

  # Configuration for the MySQL database service
  database:
    # Use the MySQL 8 Docker image
    image: mysql:8
    environment:
      # Set the root password for MySQL
      MYSQL_ROOT_PASSWORD: password
      # Specify the name of the database to be created
      MYSQL_DATABASE: product
      # Specify the MySQL user and its password
      MYSQL_USER: product
      MYSQL_PASSWORD: password
    volumes:
      # Mount a volume to persist MySQL data
      - mysql_data:/var/lib/mysql

  # Configuration for the backend application
  server:
    # Build the server image using the Dockerfile in the ./server directory
    build:
      context: ./backend
    # Expose port 8080 on the host and map it to port 8080 in the container
    ports:
      - "8080:8080"
    environment:
      # Set the Spring DataSource URL to connect to the MySQL database service
      SPRING_DATASOURCE_URL: jdbc:mysql://database:3306/product
      # Set the username for connecting to the MySQL database
      SPRING_DATASOURCE_USERNAME: product
      # Set the password for connecting to the MySQL database
      SPRING_DATASOURCE_PASSWORD: password
    # Depend on the database service, ensuring it starts before the server
    depends_on:
      - database

  # Configuration for the frontend application
  client:
    # Build the client image using the Dockerfile in the ./client directory
    build:
      context: ./frontend
    # Expose port 3000 on the host and map it to port 5173 in the container
    ports:
      - "3000:3000"
    # Depend on the server service, ensuring it starts before the client
    depends_on:
      - server

# Define a volume named mysql_data for persisting MySQL data
volumes:
  mysql_data:

Running the database, back-end and front-end containers in the docker network

1. Run the following command to create images of mysql, server and client services provided in docker-compose.yml, create and run the images in containers in a single network in detached mode i.e. run the containers in the background, detached from the terminal

    docker-compose up -d
   

   The command line should look something like this which shows the execution of the docker-compose.yml file by the configuration we provide by properties like ports, depends_on, etc.

   

   We should be able to see the containers running in a single network in out Docker desktop app.

   

   The backend and frontend servers should be running on the ports we assigned in the docker-compose.yml file.

   

2. We can use the following command to stop and remove the containers.

    docker-compose down
   

3. If we restart our containers again by docker-compose up -d, we should have our inserted data from before since we provided a volume named mysql_data in docker-compose.yml for persisting MySQL data.

Resources

1. Github repository to the provided example - Docker Compose Demo

2. Docker documentation

3. Docker Compose documentation

Conclusion

In conclusion, this blog covered the fundamental concepts of containers and how Docker facilitates their creation, deployment, and management. It delved into the role of Docker Compose as a tool for orchestrating multi-container Docker applications, emphasizing its declarative configuration, service definition, networking, volume sharing, environment variable setup, and ease of use.

The blog provides streamlined steps for configuring a Spring backend and a React frontend application with Docker, along with Dockerfiles for building container images. The Docker Compose configuration file is introduced briefly, emphasizing service setups and volume usage for data persistence.

The concluding section briefly guides readers on running the entire application stack with Docker Compose, underscoring the importance of volumes in persisting data.

In essence, this blog serves as a quick reference for developers seeking practical insights into containerization using Docker and Docker Compose, offering a simplified guide for a multi-container application environment.

As the first lines of code were written, and the initial hurdles were overcome, I found myself immersed in a world of algorithms, languages, and the sheer joy of creation. This blog is a reflection on those 100 days, a chronicle of the lessons learned, technologies embraced, and the triumphs and tribulations that came with them.

Join me as I navigated through the intricacies of different technologies, unraveling the threads of database management, front-end development, back-end development and Cloud computing, and discovering the fascinating world that lies beneath the surface of our favorite websites and applications. This was not just a coding challenge; it was a personal exploration, a commitment to growth, and a testament to the transformative power of perseverance in the face of complexity.

So, let's dive into the code and explore the milestones, the discoveries, and the unexpected joys that the 100DaysOfCode challenge brought into my coding journey.

Introduction to the Challenge

In the ever-evolving landscape of technology, the need for continuous learning and skill enhancement has become paramount. Recognizing this, the 100DaysOfCode challenge has emerged as a powerful and popular initiative within the coding community. The premise is simple yet transformative: dedicate at least one hour each day to coding for a consecutive 100 days.

This challenge serves as a catalyst for personal and professional growth, aiming to instill discipline, consistency, and a genuine love for coding. Whether you're a seasoned developer looking to expand your skill set or a novice eager to embark on a coding journey, the 100DaysOfCode challenge provides a structured and supportive framework to achieve your coding goals.

Beyond the mere act of coding, this challenge fosters a sense of community by connecting participants worldwide through social media platforms. Sharing progress, challenges, and insights with the hashtag #100DaysOfCode creates a collaborative atmosphere that encourages and motivates individuals throughout their coding odyssey.

Joining the 100DaysOfCode challenge isn't just about completing a hundred days of coding—it's about embracing a mindset of continuous improvement, breaking through barriers, and celebrating the small victories that collectively lead to significant progress. As countless developers have discovered, this challenge isn't just a commitment to code; it's a commitment to personal and professional development, one day at a time.

For more information on the origin of the challenge:-

https://www.100daysofcode.com/

Before the Challenge

Before embarking on the 100DaysOfCode challenge, my coding journey was characterized by a foundation of curiosity and a desire to learn. While confident in the front-end and back-end coding aspects, there were notable gaps in my knowledge, particularly in design, database management, and certain cloud computing and data structure concepts. Though comfortable with technologies like Java, Spring, React, and SQL, I didn't categorize myself a full-stack development professional due to these knowledge gaps.

My goals were aspirational, yet there was a noticeable gap between where I stood and where I envisioned myself in the ever-evolving world of technology. The prospect of handling back-end processes, understanding databases, and seamlessly integrating front-end and back-end development seemed daunting but immensely exciting.

In essence, I was at the foothills of a vast mountain of knowledge, eager to ascend and explore the panoramic views that awaited me in the realm of full-stack development.

Planning

Embarking on the 100DaysOfCode challenge requires thoughtful planning and a clear roadmap to navigate the coding journey successfully. Before diving into the daily coding sessions, I took the time to establish a structured plan, ensuring that the next 100 days would be both productive and rewarding.

• I outlined clear and ambitious goals centered around mastering key domains in full stack development and expanding my existing knowledge. My focus was on becoming proficient in Database Management, Back-end Development, Front-end Development, and Cloud Computing. Additionally, I aimed to delve into essential concepts like Data Structures, Containerization, and Linux.

• Recognizing the need for consistency, I divided my overarching goals into manageable sprints of 15 days each. Each sprint was dedicated to a specific topic or domain, ensuring a focused and immersive learning experience. This structured approach allowed me to balance depth and breadth in my coding journey.

• Selecting the right tools and technologies required meticulous research, considering various parameters such as industry relevance, personal interest, and scalability. Each choice was made with the goal of acquiring practical skills and knowledge that would contribute to my full-stack development proficiency.

• To track progress effectively, I established milestones to be completed at the end of every second sprint. These milestones served as checkpoints for significant achievements, whether it was successfully implementing a feature, completing a comprehensive tutorial, or building a functional project. Celebrating these milestones provided motivation and a sense of accomplishment.

• Flexibility was a key component of the plan. Recognizing that unexpected challenges could arise, I built in the flexibility to adapt the schedule and goals as needed. This adaptive approach allowed me to navigate unforeseen obstacles without derailing the overall progress.

• Regular reflection on my progress became a fundamental aspect of the planning process. This allowed me to assess what was working well, identify areas for improvement, and make necessary adjustments. The ability to adapt and refine the plan ensured that it remained dynamic and responsive to evolving learning needs.

In essence, the planning phase was not just about setting goals; it was about crafting a roadmap for a comprehensive and successful 100DaysOfCode challenge. As I moved through the meticulously planned sprints and milestones, each day became a purposeful step toward achieving mastery in full-stack development and beyond.

Tools and Technologies learned

General concepts:-

• Basics of Data Structures: Array, LinkedList, Stack, Queues

• Leetcode problems related to String, Arrays, HashMap, Linked List, Interval, backtracking, Stack, Sliding window & 2D matrix.

• Algorithms: Stack, Queue, Resize Arrays, Dequeue(Randomized), Union Find, Knuth Shuffle, Convex Hull, Selection Sort, Bubble sort, Insertion sort, Shell sort, Merge sort, Quick sort, Dijkstra Threeway, Heap sort, Heapify.

• Reversed heap, Binary Tree, Binary Search Tree, AVL Trees, Red Black Trees.

• Implementation of Symbol Tables, Kadanes algorithm.

• Containerization with Docker and Docker Compose.

• Docker compose a full-stack application.

Database management:-

• MySQL and Flyway Migration

• Indexing

• Database Principles

Backend Development

• Technologies: Java 17/21, Springboot 3, Python

• OpenAPI code generation

• RBAC system for user Authorization

• Data structures and algorithms with Python

Frontend Development

• OpenAPI Integration

• React Routing

• Common reusable components in React suitable for multiple projects

• Hands-on with React libraries like Framer Motion, Three.js

• NextJs, Tailwind CSS, Swiper.Js, and Framer Motion for the latest portfolio website

• Vite vs CRA (Create React App) concept

• Migration of a React application from CRA to Vite

Cloud Computing and DevOps

• AWS services like IAM, EC2, S3, ELB, ALB, ECR, ECS, EKS, RDS, AWS Amplify, etc.

• Deployment on various platforms like AWS EC2, S3, Netlify, Vercel, Render, etc.

• Proxy_pass with Nginx in EC2

• Setting AWS Cloudwatch logs with RDS, EC2, and ECS

• Full-stack project deployment with CI/CD

• Spring app CI/CD through Github Actions & deployment on EC2 instance (Free SSL with Caddy for testing) as a Docker container

• MySQL on AWS RDS with AWS Cloudwatch logs enabled & React app on AWS Amplify & Vercel

• Implemented a full-stack app in containers with Docker compose

• AWS Database and Analytics, Compute services, ECS, Lambda, Batch, Lightsail

• Cloud integrations, Cloud Monitoring, VPC and Networking, Security and Compliance & Machine Learning

Projects Showcase

1. Opus - A corporate management system

   Source code

2. Docker containers running in a single docker network with docker compose

   Source code

3. CI/CD of a fullstack application

   Source code

4. 3d portfolio developer website

   Source code

   Live Demo

5. Portfolio website

   Source code

   Live Demo

6. Data Structure and Algorithms

   Source code

   Source code

7. Python

   Source code

Learning Moments

• CSS layout was a significant challenge, especially when working on responsive designs. On Day 68, I dedicated time to master CSS Flexbox and Grid. The "aha" moment came when I realized how these tools could simplify complex layouts and streamline the design process. This newfound knowledge immediately translated into more visually appealing and structurally sound web pages.

• As the complexity of my projects increased, so did moments of self-doubt. Day 82 became a turning point when I faced and conquered imposter syndrome. Connecting with the coding community, sharing my struggles, and receiving encouragement helped me realize that setbacks were a natural part of the learning journey. It was okay not to have all the answers immediately.

• On Day 94, I built and deployed my first full-stack application, integrating server-side logic, databases, and client-side functionality. Simultaneously, I embraced continuous integration, setting up automated testing and deployment pipelines. This streamlined my development process, reinforcing the importance of code quality. Witnessing my code undergo automated testing and deployment with each push to the repository was a gratifying and efficient improvement, marking a significant step in enhancing the efficiency and reliability of my coding projects.

• As the 100DaysOfCode challenge concluded, the final learning moment was a reflective one. Looking back at the journey, I celebrated the accumulation of knowledge, the growth in problem-solving skills, and the newfound confidence in tackling diverse coding tasks. The challenge may have ended, but the learning journey continues.

Building Consistency

Consistency was the cornerstone of my 100DaysOfCode journey. Tracking and maintaining a consistent coding schedule not only kept me on course but also played a crucial role in my overall progress.

• Daily time commitment - I dedicated an average of at least 3-4 hours per day to coding, ensuring a balance between depth of learning and sustainable progress. On weekends, I adjusted my schedule, dedicating longer blocks of time (18-20 hours) to accommodate more complex projects and deep dives into challenging topics.

• Progress tracking - Each day, I maintained a coding journal, documenting the topics covered, challenges faced, and solutions discovered. This practice not only served as a reflection tool but also helped identify patterns in my learning journey. I organized my code repositories on platforms like GitHub, creating a visual timeline of my projects. This allowed me to track the evolution of my coding skills and revisit past projects for reinforcement.

• Learning resources - To maintain variety and avoid monotony, I diversified my learning resources. This included online courses, documentation, coding challenges, and community forums. Leveraging different formats kept the learning experience engaging and dynamic.

• Community engagement - Regular updates on social media platforms, using the #100DaysOfCode hashtag, allowed me to connect with the coding community. Sharing achievements, challenges, and insights fostered a sense of accountability and support.

• Adaptation & Flexibility - Recognizing that life can be unpredictable, I developed contingency plans for busy days or unexpected commitments. This ensured that even on challenging days, I could meet my minimum coding commitment. As the challenge progressed, I adapted my schedule based on peak productivity times. Identifying when I was most focused and adjusting my coding hours accordingly contributed to sustained consistency.

Building consistency was not just about meeting a daily coding quota; it was a holistic approach that considered time management, resource diversity, community engagement, and adaptability. These elements collectively formed the framework for a successful and rewarding 100DaysOfCode journey.

Community Engagement

• Consistent daily updates on Twitter (X) using the #100DaysOfCode hashtag played a crucial role in fostering accountability, connecting with a global coding community, and documenting my coding journey, turning social media into a platform for shared learning and encouragement.

• Regular GitHub contributions not only showcased my evolving skills through a visual timeline but also served as a personal portfolio, demonstrating coding proficiency and collaboration in open-source projects, thus enhancing my credibility as a developer.

• Utilizing Discord for real-time guidance provided immediate solutions to coding challenges, while engagement in discussions and project showcases facilitated constructive feedback and exposure to diverse coding perspectives, emphasizing the importance of collaborative learning.

• Sharing solutions to LeetCode challenges on both Discord and GitHub not only demonstrated problem-solving skills but also allowed me to actively participate in coding discussions, expanding my understanding of optimal strategies and enriching my problem-solving toolkit.

This multifaceted community engagement strategy, spanning Twitter (X), GitHub, Discord, and LeetCode, proved essential in transforming the 100DaysOfCode challenge into a dynamic and collaborative experience. It went beyond personal progress documentation, creating a supportive network and fostering shared enthusiasm for coding.

Issues Faced

• Juggling full-time work, personal commitments, and the 100DaysOfCode challenge required careful planning and adaptability to establish a consistent coding schedule.

• Intense daily coding sessions, particularly during challenging project phases, led to burnout and mental fatigue. Implementing breaks, relaxation techniques, and adjusting the daily workload helped mitigate these issues.

• Engaging with the coding community triggered impostor syndrome, especially when comparing progress with others. Recognizing this mindset and refocusing on personal goals played a crucial role in overcoming self-doubt.

• Long challenges led to monotony and plateaus in motivation. Implementing variety in coding tasks, exploring new projects, and occasionally participating in coding events helped reignite enthusiasm.

• External factors, such as family emergencies or unexpected work demands, disrupted the daily coding routine. Developing contingency plans and the ability to adapt became crucial in mitigating these disruptions.

• The abundance of coding resources sometimes led to decision paralysis. Selecting high-quality, relevant resources became crucial to avoid information overload and maintain a focused learning path.

Benefits & Impact

• Consistent daily coding sessions led to quantifiable progress, including faster problem-solving, efficient coding practices, and proficiency in various languages and frameworks.

• GitHub contributions created a visible portfolio, showcasing growth and proficiency, demonstrating adaptability and skills in diverse areas of web development.

• Active participation on Twitter (formerly known as X) and GitHub garnered recognition, evident through likes & retweets, providing motivation and a sense of accomplishment.

• Discord channels provided real-time problem resolution, with engagement from experienced developers and mentors offering insights and valuable advice.

• Regular participation in LeetCode challenges honed problem-solving skills and exposed diverse coding approaches, influencing real-world problem-solving strategies.

• Active participation in Discord project showcases offered constructive feedback, alternative perspectives, and collaborative learning experiences, refining coding practices.

• Public sharing of code snippets and project updates on social media contributed to increased confidence, with positive feedback reinforcing a sense of achievement.

The combination of daily Twitter updates, GitHub contributions, Discord engagement, and LeetCode challenges created a multifaceted learning experience, extending beyond technical skills to include community interaction, collaboration, and shared passion for coding.

After the Challenge

The 100DaysOfCode challenge fueled a substantial transformation in my skill set. Originating as a software engineer with proficiency in frontend and backend development, I strategically closed knowledge gaps during the challenge.

I enhanced my grasp of Data Structures, tackling Leetcode problems related to Array, LinkedList, Stack, Queues, and more. Projects evolved into industry-grade solutions, incorporating Java 17/21, Springboot 3, MySQL, Flyway Migration, OpenAPI, React, TypeScript, and Material UI. I explored RBAC system implementation, alongside frontend concepts like React Routing and reusable components.

Diverse topics, including SMPT server concepts & setup, Leetcode String problems, advanced JavaScript concepts, and Python basics for Data Structures and Algorithms, were covered. I revisited fundamental concepts like basic Linux commands and delved into Tree data structures, JavaScript topics like Parcel, Babel, and npm, as well as OOP with C++.

I showcased my skills with a cutting-edge portfolio project using NextJs, Tailwind CSS, Swiper.Js, and Framer motion. Migrating a React app from CRA to Vite and hands-on experience with AWS services (IAM, EC2, S3, ELB, ALB, ECR, ECS, EKS, RDS, AWS Amplify) marked key milestones. Deployments on AWS platforms, Netlify, Vercel, Render, and Docker/Docker Compose for containerization added to the journey.

This expertise significantly elevated my role as a developer, paving the way for continued growth in the dynamic technology landscape.

Resources

• DSA Roadmap in 90 Days

• DSA A2Z Sheet

• Algorithms - I

• Namaste React

• The Complete Python Bootcamp From Zero to Hero in Python

• Ultimate AWS Certified Cloud Practitioner CLF-C02

• Docker

• Github Actions

• NextJs

• 100 Days of Code

Conclusion

As the 100DaysOfCode challenge concludes, it leaves behind a trail of accomplishments and a profound sense of achievement. This coding odyssey, though challenging, was undeniably transformative.

Reflecting on these past hundred days, I'm reminded of the power of consistency and the incremental nature of learning. Beyond the syntax and frameworks, this journey strengthened my technical skills and instilled in me a sense of discipline and continuous learning.

Through the ups and downs, I've gained proficiency in various technologies and become part of a supportive coding community. The camaraderie with fellow learners added an invaluable layer to this experience, emphasizing that the journey is as important as the destination.

As this chapter concludes, I look forward to the next set of challenges and opportunities for growth. The 100DaysOfCode challenge was not just a commitment to code—it was a commitment to self-discovery and a reminder that learning is a lifelong journey.

To anyone considering a similar challenge, embrace the challenges, celebrate the victories, and, most importantly, enjoy the process. Happy coding!