Low-Level Designing:
Low-Level Designing (LLD) is a phase in software development where the high-level design of a system is broken down into detailed and concrete specifications. It involves defining individual modules, their relationships, and their functionalities. LLD focuses on implementation details, such as data structures, algorithms, and interfaces, to create a blueprint for building the software.
Design Principles:
Design principles are fundamental guidelines that guide developers in designing maintainable, scalable, and robust software systems. These principles help create software with desirable qualities, such as flexibility, modularity, and reusability.
Why should we use design principles:
Using design principles is essential to ensure that the software remains maintainable and adaptable over time. By following these principles, developers can avoid common design pitfalls and create code that is easier to understand and modify. Design principles also enhance collaboration among team members and contribute to the overall quality of the software.
Design Patterns:
Design patterns are proven solutions to recurring design problems in software development. They represent best practices that have evolved over time and are used to address specific design challenges. Design patterns provide reusable and standardized solutions that make the software more robust and easier to maintain.
Difference between the design pattern and principles:
Design principles are general guidelines that help make design decisions and shape a software system's architecture. They provide high-level concepts and rules that govern the overall design. On the other hand, design patterns are specific solutions to common design problems that emerge from applying design principles. Design patterns are more focused on the implementation level and provide detailed solutions for specific scenarios.
Design Principles:
SOLID principles
SOLID is an acronym for five design principles that were introduced by Robert C. Martin to guide object-oriented software design:
S: Single Responsibility Principle (SRP):
This principle states that a class should have only one reason to change, meaning it should have a single responsibility. Each class should focus on doing one thing and doing it well. Adhering to SRP makes the code more maintainable and less prone to bugs.
Example: Consider a "User" class that handles both user authentication and user profile management. Applying SRP, the class should be split into two separate classes - one for authentication and another for user profile management.
O: Open-Closed Principle (OCP):
The Open-Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. It encourages developers to design software in a way that new functionality can be added without altering existing code.
Example: Instead of modifying an existing "PaymentProcessor" class to add support for a new payment gateway, the class should be extended to create a new class specifically for the new gateway while keeping the existing code untouched.
L: Liskov Substitution Principle (LSP):
The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. In other words, subclasses should be able to be used interchangeably with their base class.
Example: If you have a "Shape" base class with subclasses like "Circle" and "Square," any method that accepts a "Shape" parameter should work correctly with instances of "Circle" or "Square" without any issues.
Breaking the Liskov Substitution Principle (LSP) in software design can lead to various consequences, primarily affecting the correctness, maintainability, and robustness of the codebase. When LSP is violated, unexpected behaviors and errors may arise, making the software more challenging to understand, modify, and extend. Here are some consequences of breaking the Liskov Substitution Principle:
- Incorrect Behavior: When a subclass does not properly adhere to the contract defined by its superclass, it may behave differently than expected when used in place of the superclass. This can result in unpredictable and incorrect behavior, leading to bugs and unexpected outcomes in the software.
- Tight Coupling: Breaking LSP often forces the client code to make assumptions about the behavior of the subclasses, leading to tight coupling between the client and the subclasses. Changes in the subclasses may then require modifications in the client code, making the system more brittle and less flexible.
- Reduced Reusability: If subclasses cannot be substituted for their base class without causing issues, their reusability is diminished. Developers may be hesitant to reuse or extend the subclasses in other parts of the application, leading to code duplication and reduced maintainability.
These design principles provide a solid foundation for creating maintainable and scalable software systems and are widely used in modern software development practices.
Assessment: https://www.bosscoderacademy.com/blog/lld-2-assessment
