DEV Community: Diego Brener

The Causes of Poor Software Architecture

Diego Brener — Sat, 10 Aug 2024 04:49:08 +0000

Understanding the Causes of Poor Software Architecture

At some point in their careers, many developers encounter software architectures that are true mazes of complexity, lacking apparent organization and challenging even for the most experienced. This scenario is particularly common when joining a new company, where you may be assigned to take over a legacy project or integrate with an ongoing team. The initial reaction is often one of frustration: complaints about the lack of tests, the need to change many lines of code in one place, and the total absence of standards are typical.

However, before we rush to criticize or even consider giving up, it's crucial to reflect on a key idea: "There is no bad architecture without context."

The Origin of Bad Architectures

A poor software architecture doesn’t emerge from nowhere. No one starts a project intending to create something dysfunctional or difficult to maintain. These problematic architectures result from a series of factors that accumulate over time. Let’s explore some of these factors:

Lack of Personnel and Resources
Poorly designed projects often stem from a shortage of human or financial resources. When a team is overwhelmed, lacking time or enough people, decisions are made reactively without proper long-term planning. This can lead to shortcuts in development, a lack of refactoring, and the accumulation of technical debt, which eventually turns into an architectural nightmare.
Poor Organizational Structure
As Conway’s Law states: "Organizations that design systems are constrained to produce designs that are copies of the communication structures of these organizations." If communication within a company is fragmented, with silos between departments and teams, the software architecture will reflect that fragmentation. System modules may be isolated, redundant, or poorly integrated, mirroring the lack of internal cohesion within the company.
Inadequate Management of Technical Debt
Technical debt is inevitable in any software project. However, when not managed properly, it can accumulate and become a critical issue. The lack of effective management of technical debt, where "debts" are continuously postponed, leads to an architecture that becomes increasingly difficult to maintain and expand.
Lack of a Quality Culture
Often, code quality is sacrificed in the name of quick delivery or meeting tight deadlines. In companies where there is no strong quality culture, developers may feel they lack the support or time needed to apply best practices, such as automated testing, code reviews, and continuous refactoring. This can lead to the creation of code that, in the short term, seems to meet needs, but in the long term, becomes unsustainable and difficult to maintain.
Legacy Dependencies and Technologies
In many projects, technological decisions are based on tools or frameworks that, while appropriate at the beginning, become obsolete over time. Maintaining these legacy dependencies can force developers to create complex and clumsy solutions to work around the limitations imposed by outdated technologies. The lack of updates and reluctance to adopt new technologies can exacerbate the problem, resulting in rigid and inflexible architecture.
Lack of Documentation and Shared Knowledge
Insufficient or nonexistent documentation is one of the main reasons why software architectures become confusing and difficult to work with. When knowledge is centralized in a few individuals or poorly documented, the departure of a team member can leave significant gaps in system understanding. This can lead to incorrect assumptions, duplication of efforts, and solutions that do not follow a consistent pattern, increasing the complexity and fragility of the architecture.

What Can We Do?

Before harshly judging a poor architecture, it's essential to understand the context that led to the situation. This allows us not only to better manage the current system but also to prevent these issues from recurring in the future.

Context Analysis: Understand the project’s history and the circumstances that led to its current state. This may include conversations with former team members, reviewing historical documentation, and analyzing code commits over time.
Continuous Refactoring: Establish a continuous process of refactoring and code improvement, focusing on critical areas where maintenance is most challenging.
Education and Training: Invest in training so the team understands the importance of good architectural practices and how to apply them daily.
Effective Communication: Work to improve communication between development teams and other areas of the company, ensuring that everyone is aligned with the project’s goals and best practices.
Adherence to Design Patterns: Respect and apply established design patterns to solve common problems in software design. Design patterns provide proven solutions and help maintain a consistent and scalable architecture.
Maintain a Strong Engineering Culture: Foster a culture that prioritizes engineering excellence, including code quality, adherence to best practices, and regular knowledge sharing. A strong engineering culture promotes best practices and continuous improvement, ensuring that architecture evolves in a healthy manner.
Implement Robust Testing Practices: Establish comprehensive testing strategies, including unit tests, integration tests, and end-to-end tests, to ensure that the architecture remains reliable and maintainable. Testing helps identify and address issues early in the development process, reducing the risk of accumulating technical debt.
Regular Code Reviews: Conduct regular code reviews to ensure that code quality standards are maintained and to catch potential issues before they become significant problems. Code reviews facilitate knowledge sharing and help enforce consistent coding practices across the team.

In summary, poor architecture often reflects deeper organizational issues. By addressing these root causes with understanding and targeted strategies, we can transform problematic systems into robust and sustainable solutions.

Understanding the Observer Design Pattern in Java

Diego Brener — Sat, 03 Aug 2024 16:29:29 +0000

Understanding the Observer Design Pattern in Java

Problem

The Observer pattern addresses the need to automatically notify a set of objects (observers) when the state of another object (subject) changes. This is useful in scenarios where one object needs to stay updated with changes in another object, such as in event-driven systems or notification systems.

Solution

The Observer pattern involves two main components:

Subject: The object that holds some state and notifies observers about changes to this state.
Observer: The interface that defines the update method, which is called by the subject to notify observers of changes.

The subject maintains a list of observers and notifies them by calling their update methods whenever there is a change in its state.

Pros and Cons

Pros

Decoupling: The pattern promotes loose coupling between the subject and observers, allowing them to evolve independently.
Reactivity: Enables observers to automatically receive updates when the subject's state changes, supporting the development of reactive systems.
Extensibility: New observers can be added without modifying the existing subject or other observers' code.

Cons

Complexity: Can introduce additional complexity, especially in systems with many observers and frequent events.
Observer Management: Managing the lifecycle of observers, including registration and removal, can be complex.
Potential Performance Issues: Notifying a large number of observers can impact performance, especially if the update methods are complex.

Example of Real-World Application

A practical example of the Observer pattern is in social media notification systems, where users (observers) are notified of their friends' (subjects) activities, such as posts and status updates.

Example Code in Java


public interface Observer {
    void update(String message);
}

public interface Subject {
    void registerObserver(Observer observer);
    void removeObserver(Observer observer);
    void notifyObservers();
}

public class SocialMediaAccount implements Subject {
    private List<Observer> observers = new ArrayList<>();
    private String statusUpdate;

    @Override
    public void registerObserver(Observer observer) {
        observers.add(observer);
    }

    @Override
    public void removeObserver(Observer observer) {
        observers.remove(observer);
    }

    @Override
    public void notifyObservers() {
        for (Observer observer : observers) {
            observer.update(statusUpdate);
        }
    }

    public void postUpdate(String status) {
        this.statusUpdate = status;
        notifyObservers();
    }
}

public class Follower implements Observer {
    private String name;

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

    @Override
    public void update(String message) {
        System.out.println(name + " received update: " + message);
    }
}

public class Client {
    public static void main(String[] args) {
        SocialMediaAccount account = new SocialMediaAccount();

        Observer follower1 = new Follower("Alice");
        Observer follower2 = new Follower("Bob");

        account.registerObserver(follower1);
        account.registerObserver(follower2);

        account.postUpdate("Hello, followers!");
        account.postUpdate("Check out my new post!");

        account.removeObserver(follower1);
        account.postUpdate("Another update!");
    }
}

Understanding the Strategy Design Pattern in Java

Diego Brener — Fri, 26 Jul 2024 01:58:48 +0000

Understanding the Strategy Design Pattern in Java

Problem

The Strategy pattern addresses the need to define a family of algorithms, encapsulate each one, and make them interchangeable. This pattern lets the algorithm vary independently from the clients that use it. It is useful when you have multiple ways to perform a specific task and want to choose the algorithm at runtime.

Solution

The Strategy pattern involves three main components:

Context: The object that contains a reference to a strategy object and uses it to execute the algorithm.
Strategy: An interface common to all supported algorithms. The context uses this interface to call the algorithm defined by a concrete strategy.
Concrete Strategy: Classes that implement the strategy interface, providing specific algorithms.

The context delegates the execution of the algorithm to the strategy object, which allows the algorithm to be selected at runtime.

Pros and Cons

Pros

Encapsulation of Algorithms: Each algorithm is encapsulated in its own class, making it easy to switch between them and to add new algorithms without changing the context.
Single Responsibility Principle: The context class is simplified as it delegates the algorithm implementation to strategy classes.
Open/Closed Principle: New strategies can be introduced without altering the existing context or strategy classes.

Cons

Increased Number of Classes: The pattern increases the number of classes in the codebase due to the creation of new strategy classes for each algorithm.
Complexity in Switching Strategies: If not managed well, switching strategies dynamically at runtime can introduce complexity and potential errors.

Example of Real-World Application

A practical example of the Strategy pattern is in a payment processing system where different payment methods (e.g., credit card, PayPal, bank transfer) are implemented as different strategies. The client can choose the appropriate payment strategy at runtime.

Example Code in Java

Strategy pattern in code:

// Strategy Interface
public interface PaymentStrategy {
    void pay(int amount);
}

// Concrete Strategy 1
public class CreditCardPayment implements PaymentStrategy {
    private String cardNumber;

    public CreditCardPayment(String cardNumber) {
        this.cardNumber = cardNumber;
    }

    @Override
    public void pay(int amount) {
        System.out.println(amount + " paid with credit card " + cardNumber);
    }
}

// Concrete Strategy 2
public class PayPalPayment implements PaymentStrategy {
    private String email;

    public PayPalPayment(String email) {
        this.email = email;
    }

    @Override
    public void pay(int amount) {
        System.out.println(amount + " paid using PayPal account " + email);
    }
}

// Context
public class ShoppingCart {
    private PaymentStrategy paymentStrategy;

    public void setPaymentStrategy(PaymentStrategy paymentStrategy) {
        this.paymentStrategy = paymentStrategy;
    }

    public void checkout(int amount) {
        paymentStrategy.pay(amount);
    }
}

// Client code
public class Client {
    public static void main(String[] args) {
        ShoppingCart cart = new ShoppingCart();

        cart.setPaymentStrategy(new CreditCardPayment("1234-5678-9876-5432"));
        cart.checkout(100);

        cart.setPaymentStrategy(new PayPalPayment("user@example.com"));
        cart.checkout(200);
    }
}

Understanding the Memento Design Pattern in Java

Diego Brener — Wed, 24 Jul 2024 03:00:51 +0000

Problem

The Memento pattern addresses the need to capture and restore an object's internal state without violating its encapsulation. This is useful in scenarios where you want to implement undo/redo functionality, allowing an object to revert to a previous state.

Solution

The Memento pattern involves three main components:

Originator: The object whose internal state needs to be saved and restored.
Memento: An object that stores the internal state of the originator. The memento is immutable.
Caretaker: Responsible for requesting the originator to save or restore its state from a memento.

The originator creates a memento containing a snapshot of its current state. This memento can then be stored by the caretaker and used to restore the originator's state when needed.

Pros and Cons

Pros

Preserves Encapsulation: Allows an object's internal state to be saved and restored without exposing its implementation details.
Simple Undo/Redo: Facilitates the implementation of undo/redo functionality, making the system more robust and user-friendly.
State History: Allows maintaining a history of previous states of the object, enabling navigation between different states.

Cons

Memory Consumption: Storing multiple mementos can consume significant memory, especially if the object's state is large.
Additional Complexity: Introduces additional complexity to the code, with the need to manage the creation and restoration of mementos.
Caretaker Responsibility: The caretaker needs to manage mementos efficiently, which can add responsibility and complexity to the system.

Example of Real-World Application

A practical example of the Memento pattern is in text editors that offer undo/redo functionality. Each change to the document can be saved as a memento, allowing the user to revert to previous states of the document as needed.

Example Code in Java

Memento pattern in code:

// Originator
public class Editor {
    private String content;

    public void setContent(String content) {
        this.content = content;
    }

    public String getContent() {
        return content;
    }

    public Memento save() {
        return new Memento(content);
    }

    public void restore(Memento memento) {
        content = memento.getContent();
    }

    // Memento
    public static class Memento {
        private final String content;

        public Memento(String content) {
            this.content = content;
        }

        private String getContent() {
            return content;
        }
    }
}

// Caretaker
public class History {
    private final Stack<Editor.Memento> history = new Stack<>();

    public void save(Editor editor) {
        history.push(editor.save());
    }

    public void undo(Editor editor) {
        if (!history.isEmpty()) {
            editor.restore(history.pop());
        }
    }
}

// Client code
public class Client {
    public static void main(String[] args) {
        Editor editor = new Editor();
        History history = new History();

        editor.setContent("Version 1");
        history.save(editor);
        System.out.println(editor.getContent());

        editor.setContent("Version 2");
        history.save(editor);
        System.out.println(editor.getContent());

        editor.setContent("Version 3");
        System.out.println(editor.getContent());

        history.undo(editor);
        System.out.println(editor.getContent());

        history.undo(editor);
        System.out.println(editor.getContent());
    }
}

Understanding the Abstract Factory Design Pattern

Diego Brener — Tue, 23 Jul 2024 14:40:09 +0000

Understanding the Abstract Factory Design Pattern

Problem

The Abstract Factory pattern addresses the need to create families of related or dependent objects without specifying their concrete classes. This is useful when a system needs to be independent of how its objects are created, composed, and represented, ensuring that products created together are compatible.

Solution

The Abstract Factory pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. This interface defines a set of methods for creating abstract products, which concrete factory classes implement to create concrete products. This promotes loose coupling by ensuring that client code interacts with the factory interface rather than concrete classes directly.

Pros and Cons

Pros

Decouples Client Code: Allows client code to work with an interface for object creation, promoting flexibility and maintainability.
Promotes Consistency: Ensures that products created by the factories are compatible with each other.
Supports Open-Closed Principle: New product families can be added without modifying existing client code, adhering to the Open-Closed Principle.

Cons

Complexity: Introduces additional complexity with the introduction of multiple factory and product classes.
Requires Subclassing: Each product family requires its own factory, potentially leading to a proliferation of classes in the codebase.
Not Suitable for Simple Cases: Overuse of the Abstract Factory pattern in simple scenarios can lead to unnecessary abstraction and complexity.

Example of Real-World Application

A practical example of the Abstract Factory pattern is in a UI toolkit that supports multiple themes. Depending on the selected theme (e.g., Windows, MacOS), a corresponding factory creates UI components (buttons, checkboxes) with the appropriate appearance and behavior.

Example Code in Java

Abstract Factory pattern in code


java
// Abstract Product A
public interface Button {
    void paint();
}

// Abstract Product B
public interface Checkbox {
    void paint();
}

// Concrete Product A1
public class WindowsButton implements Button {
    @Override
    public void paint() {
        System.out.println("Rendering a button in Windows style");
    }
}

// Concrete Product B1
public class WindowsCheckbox implements Checkbox {
    @Override
    public void paint() {
        System.out.println("Rendering a checkbox in Windows style");
    }
}

// Concrete Product A2
public class MacOSButton implements Button {
    @Override
    public void paint() {
        System.out.println("Rendering a button in MacOS style");
    }
}

// Concrete Product B2
public class MacOSCheckbox implements Checkbox {
    @Override
    public void paint() {
        System.out.println("Rendering a checkbox in MacOS style");
    }
}

// Abstract Factory
public interface GUIFactory {
    Button createButton();
    Checkbox createCheckbox();
}

// Concrete Factory 1
public class WindowsFactory implements GUIFactory {
    @Override
    public Button createButton() {
        return new WindowsButton();
    }

    @Override
    public Checkbox createCheckbox() {
        return new WindowsCheckbox();
    }
}

// Concrete Factory 2
public class MacOSFactory implements GUIFactory {
    @Override
    public Button createButton() {
        return new MacOSButton();
    }

    @Override
    public Checkbox createCheckbox() {
        return new MacOSCheckbox();
    }
}

// Client code
public class Application {
    private Button button;
    private Checkbox checkbox;

    public Application(GUIFactory factory) {
        button = factory.createButton();
        checkbox = factory.createCheckbox();
    }

    public void paint() {
        button.paint();
        checkbox.paint();
    }

    public static void main(String[] args) {
        GUIFactory factory;
        String osName = System.getProperty("os.name").toLowerCase();
        if (osName.contains("mac")) {
            factory = new MacOSFactory();
        } else {
            factory = new WindowsFactory();
        }
        Application app = new Application(factory);
        app.paint();
    }
}

Understanding the Factory Method Design Pattern

Diego Brener — Tue, 23 Jul 2024 05:20:02 +0000

Understanding the Factory Method Design Pattern

Problem

The Factory Method pattern addresses the need to create objects without specifying the exact class of object that will be created. This is useful when you have multiple subclasses of a superclass and want to delegate the object creation to a specific subclass based on certain conditions or parameters.

Solution

The Factory Method pattern provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created. This promotes loose coupling by ensuring that the client code interacts with the factory interface rather than the concrete classes directly.

Pros and Cons

Pros

Decouples Client Code: Allows client code to work with an interface or abstract class for object creation, promoting flexibility and maintainability.
Promotes Code Reuse: Subclasses can reuse the same object creation logic defined in the factory method.
Supports Open-Closed Principle: New subclasses can be added without modifying existing client code, adhering to the Open-Closed Principle.

Cons

Complexity: Introduces additional complexity with the introduction of multiple subclasses and factory methods.
Requires Subclassing: Each product type requires its own subclass, potentially leading to a proliferation of classes in the codebase.
Not Suitable for Simple Cases: Overuse of the Factory Method pattern in simple scenarios can lead to unnecessary abstraction and complexity.

Example of Real-World Application

A practical example of the Factory Method pattern is in a framework for creating documents. Depending on the type of document (e.g., PDF, HTML), a corresponding document factory creates the document object with appropriate formatting and features.

Example Code in Java

Factory Method pattern in code

// Product interface
public interface Document {
    void open();
    void close();
}

// Concrete Product 1
public class PDFDocument implements Document {
    @Override
    public void open() {
        System.out.println("Opening PDF document");
    }

    @Override
    public void close() {
        System.out.println("Closing PDF document");
    }
}

// Concrete Product 2
public class HTMLDocument implements Document {
    @Override
    public void open() {
        System.out.println("Opening HTML document");
    }

    @Override
    public void close() {
        System.out.println("Closing HTML document");
    }
}

// Creator interface
public interface DocumentFactory {
    Document createDocument();
}

// Concrete Creator 1
public class PDFDocumentFactory implements DocumentFactory {
    @Override
    public Document createDocument() {
        return new PDFDocument();
    }
}

// Concrete Creator 2
public class HTMLDocumentFactory implements DocumentFactory {
    @Override
    public Document createDocument() {
        return new HTMLDocument();
    }
}

// Client code
public class Client {
    public static void main(String[] args) {
        DocumentFactory factory1 = new PDFDocumentFactory();
        Document pdfDocument = factory1.createDocument();
        pdfDocument.open();
        pdfDocument.close();

        DocumentFactory factory2 = new HTMLDocumentFactory();
        Document htmlDocument = factory2.createDocument();
        htmlDocument.open();
        htmlDocument.close();
    }
}

Understanding the Singleton Design Pattern

Diego Brener — Tue, 23 Jul 2024 03:21:45 +0000

Problem

The Singleton pattern addresses two primary problems simultaneously, which can lead to violating the Single Responsibility Principle:

Single Instance Requirement: Sometimes, you need to ensure that a class has only one instance. This is typically to control access to a shared resource such as a database connection or a file. Unlike regular constructors, which create new instances each time they are called, a Singleton guarantees that subsequent calls return the same instance.
Global Access: Alongside ensuring a single instance, Singleton provides a global access point to that instance. This is akin to using global variables but with the added benefit of preventing accidental overwrite or misuse of the instance by other parts of the codebase.

Solution

Implementing a Singleton involves two common steps across all implementations:

Private Constructor: The class's default constructor is made private to prevent other objects from using the new operator to instantiate it directly.
Static Creation Method: A static method is provided within the Singleton class to act as a constructor. This method ensures that only one instance of the class is created and provides a global access point to that instance. The method typically checks if an instance already exists; if it does, it returns the existing instance; if not, it creates a new instance and returns it.

Additional Considerations

While the Singleton pattern effectively solves the problems of single instance management and global access, it comes with trade-offs and additional considerations:

Violates Single Responsibility Principle: By managing its own instantiation and providing global access, a Singleton class may take on multiple responsibilities. This can complicate the class's design and increase its coupling with other parts of the system.
Concurrency Concerns: In multi-threaded environments, special care must be taken to ensure that the Singleton instance is properly initialized and accessed without race conditions. Techniques like double-checked locking or synchronization can be used to handle concurrent access safely.
Testing Challenges: Testing code that depends on a Singleton can be challenging due to its static nature and global access. Mocking or replacing the Singleton instance for testing purposes may require additional effort or workaround solutions.
Potential Misuse: Developers may misuse the Singleton pattern by applying it where it isn't necessary or appropriate, potentially leading to overcomplicated designs or unnecessary constraints on object instantiation.

Example of Real-World Application

A practical example where the Singleton pattern is beneficial is in a logging service within an application. By ensuring there is only one instance of the logging service, all parts of the application can log to the same output, facilitating easier monitoring and debugging.

Example Code in Java

Just a simplified implementation of a Singleton in Java:


public class Singleton {
    private static Singleton instance;

    // Private constructor to prevent instantiation from outside
    private Singleton() {}

    // Lazy initialization (creates instance only when needed)
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }

    // Example method
    public void showMessage() {
        System.out.println("Hello, Singleton!");
    }

    // Example usage
    public static void main(String[] args) {
        Singleton singleton = Singleton.getInstance();
        singleton.showMessage();
    }
}

Layered Architecture Pattern

Diego Brener — Sun, 21 Jul 2024 19:42:59 +0000

The layered architecture pattern is a widely used approach in software design, where components(code) are organized into distinct layers of subtasks, arranged hierarchically. Each layer performs specific functions and operates independently of the others, enabling modifications within a layer without impacting the rest. This pattern, often referred to as 'N-tier architecture,' is prevalent in the design of many software systems and typically comprises four primary layers.

Layers of the Pattern

Presentation Layer: This is the user interface layer, where users interact with the application by entering and viewing data.
Business Layer: Responsible for executing business logic according to the application's requirements.
Application Layer: Acts as an intermediary, facilitating communication between the presentation and data layers.
Data Layer: Manages data storage and retrieval, often involving databases.

Advantages

Scalability: Each layer can be scaled independently, allowing for performance optimization without affecting the entire system.
Flexibility: Different technologies can be implemented within each layer without impacting others, promoting innovation and adaptation.
Maintainability: Since layers are independent, changes or updates in one layer do not necessarily affect the others, simplifying maintenance.

Disadvantages

Complexity: Introducing additional layers can increase system complexity, making it more challenging to manage.
Performance Overhead: Multiple layers can introduce latency due to the additional communication required between them.
Strict Layer Separation: Enforcing strict separation can sometimes lead to inefficiencies and increased development effort.

Java Beans

Diego Brener — Sun, 21 Jul 2024 00:12:39 +0000

Java Beans are reusable software components according to the specification. A Java Bean can encapsulate many objects into a single object, and we can use them through "get" and "set" methods in various places in our application. Besides providing easy maintenance, it also allows our objects to be eligible for other tools, such as persistence tools.

To be defined as Java Beans, the class must follow some conventions, such as:

Implement the java.io.Serializable interface (to allow the object's state to be persisted and retrieved).
Have a no-argument constructor (no-arg constructor).
Have private properties accessible by "get" and "set" methods.

Example of a bean:

// Implements Serializable
public class Pessoa implements java.io.Serializable {

    // Has private properties
    private String nome;

    // Get methods
    public String getNome() {
        return nome;
    }

    // Set methods
    public void setNome(String nome) {
        this.nome = nome;
    } 


    /* No-argument constructor */
    public Pessoa() {
        this.nome="";
    }
}