Software Design Patterns

Creational patterns:
- Singleton: ensures a class has only one instance
- Factory: provides a way to create objects without specifying the exact class of object
- Abstract Factory: provides a way to create families of related objects
Structural patterns:
- Adapter: allows incompatible objects to work together
- Bridge: separates an object's abstraction from its implementation
- Composite: allows clients to treat individual objects and compositions of objects uniformly
Behavioral patterns:
- Observer: defines a one-to-many dependency between objects
- Strategy: defines a family of algorithms, encapsulates each one, and makes them interchangeable
- Template Method: defines the skeleton of an algorithm, allowing subclasses to fill in the details

Types of testing:
- Unit testing: tests individual units of code
- Integration testing: tests how units of code work together
- System testing: tests the entire system
- Acceptance testing: tests if the system meets the requirements
Debugging techniques:
- Print statements: adds print statements to identify the point of failure
- Breakpoints: pauses the execution of the program at a specific point
- Logging: records events and errors during the execution of the program

Requirements gathering:
- Interviews: one-on-one or group discussions with stakeholders
- Surveys: written or online questionnaires
- Observation: observing users in their natural environment
- Prototyping: creating a mock-up or a working model
Requirements specification:
- Functional requirements: describes what the system must do
- Non-functional requirements: describes how the system should perform
- User interface requirements: describes how the system should interact with the user

Coding principles:
- Don't Repeat Yourself (DRY): avoids duplication of code
- Keep It Simple, Stupid (KISS): favors simplicity over complexity
- Single responsibility principle (SRP): a class should have only one reason to change
Documentation:
- Code comments: explains the purpose and functionality of the code
- API documentation: describes the usage and parameters of functions and classes
- User documentation: provides instructions and guides for users

Singleton pattern ensures a class has only one instance, controlling object creation.
Factory pattern provides a way to create objects without specifying the exact class of object, promoting flexibility.
Abstract Factory pattern creates families of related objects, providing a way to encapsulate a group of individual factories.

Unit testing involves testing individual units of code, focusing on specific components.
Integration testing examines how units of code work together, ensuring seamless interactions.
System testing evaluates the entire system, verifying its functionality as a whole.
Acceptance testing determines if the system meets the requirements, ensuring it meets user needs.
Debugging techniques include print statements, adding temporary output to identify the point of failure.
Breakpoints pause the execution of the program at a specific point, allowing for inspection.
Logging records events and errors during the execution of the program, providing a trail of system activity.

Encapsulation hides internal implementation details from the outside world, protecting sensitive information.
Abstraction shows only necessary information to the outside world, simplifying complex systems.
Inheritance creates a new class based on an existing class, promoting code reuse and a hierarchical relationship.
Polymorphism allows objects of different classes to be treated as objects of a common superclass, increasing flexibility.
Composition enables an object to be composed of other objects or collections of objects, forming complex structures.

Requirements gathering involves interviews, one-on-one or group discussions with stakeholders to gather information.
Surveys use written or online questionnaires to collect data from a larger audience.
Observation involves observing users in their natural environment, providing insights into real-world usage.
Prototyping creates a mock-up or a working model, allowing for early testing and feedback.
Functional requirements describe what the system must do, outlining its core functionality.
Non-functional requirements describe how the system should perform, including aspects like speed and security.
User interface requirements outline how the system should interact with the user, ensuring an intuitive experience.

The Don't Repeat Yourself (DRY) principle avoids duplication of code, reducing maintenance and improving efficiency.
The Keep It Simple, Stupid (KISS) principle favors simplicity over complexity, making code easier to understand and maintain.
The Single responsibility principle (SRP) states that a class should have only one reason to change, promoting modularity and flexibility.
Code comments explain the purpose and functionality of the code, providing context for developers.
API documentation describes the usage and parameters of functions and classes, acting as a reference for developers.
User documentation provides instructions and guides for users, ensuring a smooth and efficient experience.