1/84
implentation object model solid principles
Name | Mastery | Learn | Test | Matching | Spaced |
---|
No study sessions yet.
Software Object
A programming construct that encapsulates data (attributes/state) and behavior (methods) into a single, self-contained unit.
Method (Operation)
A callable procedure defined inside an object that specifies an acceptable service the object can perform.
Method Signature
The name of a method together with its parameters, parameter types, and return type; defines how clients may call the method.
Interface
A set of method signatures that describes the services an object offers while hiding its internal state.
Encapsulation
The principle of hiding an objectâs internal state and exposing functionality only through its interface.
Client Object
An object that sends messages (method calls) requesting services from other objects.
Server Object
An object that receives messages, performs requested services, and returns results.
Message
A method call sent from a client object to a server object to request a service.
On-Demand Design
Design approach where interfaces and their implementations are created to satisfy the immediate needs of client objects rather than pre-defining features.
Attributes (State)
Variables maintained inside an object that represent its current condition or data.
Software Module
A loose grouping of subprograms and data; lacks the strict encapsulation enforced by objects.
Subprogram (Behavior)
A standalone procedure or function inside a module; equivalent to a method inside an object.
Composition
An object relationship in which one object contains references to other objects to use their services (has-a relationship).
Inheritance
An object relationship where a derived class acquires the attributes and methods of a base class (is-a relationship).
Change Propagation
The effect where modifications in a base class automatically affect derived classes, creating potential risk for new bugs.
UML Class Notation
A diagram element with three compartments: class name, attributes, and operations.
UML Interface
A stereotype «interface» element that lists only operation signatures, implemented by one or more classes.
Base Class
A general class whose properties are inherited by another class.
Derived Class
A class that extends a base class, inheriting and possibly overriding its behavior.
Front-End Class
In composition, the object that acts as a façade, delegating work to the contained (back-end) object.
Process-Oriented Approach
Development mindset centered on sequential steps and actions; intuitive but hard to scale for complex systems.
Object-Oriented Approach
Development mindset centered on organizing responsibilities among collaborating objects; scales better but is harder to design well.
Traceability
The ability to follow every requirement through design, implementation, and testing artifacts without unexplained gaps.
Test-Driven Development (TDD)
A practice where tests are written first and development proceeds only when code passes those tests.
Measurement (in SE)
The use of metrics and tools to monitor product quality and developer productivity.
Security Development Lifecycle (SDL)
Microsoftâs structured process for integrating security considerations throughout software development.
Prime Factorization
The expression of an integer as a product of prime numbers (e.g., 905 = 5 Ă 181).
Coprime (Relatively Prime)
Two integers with no common factor other than 1; equivalently, their greatest common divisor is 1.
Greatest Common Divisor (GCD)
The largest integer that divides two numbers without remainder; equals 1 for coprime pairs.
Rube Goldberg Machine (TDD Example)
Illustrates that passing a single test case doesnât guarantee robustness; a system may work for one scenario yet remain fragile.
Object-Oriented Design (OOD)
A discipline focused on designing software that is easy to modify, extend and maintain by organizing systems around interacting objects.
Object-Oriented Programming (OOP)
A programming paradigm based on objects containing data and behavior; language support alone is insufficient without proper design practices.
SOLID
A mnemonic coined by Robert C. Martin summarizing five key principlesâSRP, OCP, LSP, ISP, DIPâfor managing dependencies and creating flexible, maintainable software.
Single Responsibility Principle (SRP)
States that a class should have only one reason to change, encouraging high cohesion and separation of concerns.
Cohesion
The functional relatedness of elements within a module; high cohesion means a moduleâs elements change for the same single reason.
Open/Closed Principle (OCP)
Classes, modules, or functions should be open for extension but closed for modification, allowing new behavior without altering existing code.
Liskov Substitution Principle (LSP)
Subtypes must be substitutable for their base types without altering the correctness of a program, ensuring polymorphic behavior.
Interface Segregation Principle (ISP)
Clients should not be forced to depend on interfaces they do not use; many specific interfaces are better than one large, âfatâ interface.
Dependency Inversion Principle (DIP)
High-level and low-level modules should both depend on abstractions, not on concrete classes, thereby decoupling software layers.
Robert C. Martin ("Uncle Bob")
Software engineer and author who popularized the SOLID principles through books like âClean Codeâ and âAgile Software Development.â
Structured Programming
An earlier methodology emphasizing control structures over GOTO statements; precursor to object-oriented approaches for building complex software.
Fat Interface
An interface that contains methods unrelated to a particular clientâs needs, causing unnecessary coupling and violating ISP.
Abstraction (in DIP context)
A high-level definition (interface or abstract class) that both high-level and low-level modules depend upon, enabling flexibility and reuse.
Coupling
The degree to which one component relies on another; SOLID principles aim to minimize tight coupling and improve maintainability.
Reason to Change
A distinct cause that forces a class or module to be modified; SRP demands each class have exactly one such reason.
Coding Standards
Documented conventions that guide code formatting, naming, commenting, and banned constructs to ensure consistency across a project.
Characteristics of Good Implementation
Key qualitiesâreadability, maintainability, performance, traceability, correctness, and completenessâthat well-written code should possess.
Readability (Code)
The ease with which a human can understand the purpose, control flow, and data flow of source code.
Maintainability
How easily software can be modified to fix defects, improve performance, or adapt to a changed environment.
Performance (Software)
The efficiency with which a program uses resources such as CPU, memory, and I/O to perform its tasks.
Traceability
The ability to link code back to requirements, design documents, and test cases.
Correctness
The degree to which software adheres to specified functional requirements.
Completeness (Implementation)
Extent to which all required features are fully implemented in the software.
Naming Convention
A set of rules for choosing identifiers (classes, methods, variables, files) that promote clarity and consistency.
Global Identifier Naming Guideline
Use longer, descriptive names for globally visible identifiers; keep local names short.
Python lowerwithunder
Preferred Python style for functions, variables, modules, and packages (e.g., my_function).
CapWords (CamelCase)
Python recommendation for class and exception names (e.g., MyClass).
CAPSWITHUNDER
Python style for constants at module or class scope (e.g., MAX_SPEED).
GUI Prefix "btn"
Naming prefix indicating a button control, e.g., btnLogin.
GUI Prefix "chk"
Naming prefix indicating a checkbox control, e.g., chkStatus.
Function/Method Size Rule
Keep methods under ~50 lines to reduce error likelihood and simplify understanding.
FileâNaming Best Practice
Use short (<25 char), descriptive names without spaces or special characters; write conventions in a data-management plan.
ISO 8601 Date Format
YYYYMMDD representation recommended for embedding dates in file names (e.g., report_20241005.txt).
Avoid GOTO
Structured programming guideline that prohibits GOTO/setjmp/longjmp to preserve readable control flow.
Multiple Inheritance (Risk)
Discouraged practice because it can introduce ambiguity and complexity in object hierarchies.
Comment Smell: Code Repetition
Comment merely restates code and should be avoided.
Comment Type: Description of Intent
Most valuable comment; explains WHY the code exists, not what it literally does.
Coding Standards Repository
Central location (e.g., repo_standards/general.md) storing language-specific guidelines.
Debugging â Stabilization/Reproduction
Phase where a minimal test case that reliably triggers the defect is produced.
Debugging â Localization
Process of finding the exact code section responsible for a defect.
Debugging â Correction
Modifying code to eliminate the located defect.
Debugging â Verification
Confirming the fix and ensuring no regressions, often using tools like source comparators or interactive debuggers.
Source Code Comparator
Tool that highlights differences between code versions to aid verification (e.g., Code Compare).
Interactive Debugger
Tool that allows step-through execution, variable inspection, and breakpoint control during debugging.
Assertion
Executable statement that checks a condition assumed true; used for defensive programming.
Defensive Programming
Technique of writing code that anticipates and guards against possible errors or misuse.
Profiler
Performance tool that measures resource usage to guide optimization.
Refactoring
Improving code structure and readability without altering external behavior.
Code Smell
Surface indication that usually corresponds to a deeper problem (e.g., duplicated code, long methods).
Long Method (Smell)
Excessively lengthy routine; often refactored by extracting smaller functions.
Feature Envy (Smell)
Method that excessively uses data or methods of another class, suggesting a relocation of logic.
Three Golden Rules of UI Design
1) Place user in control, 2) Reduce user memory load, 3) Ensure consistency.
Place User in Control
UI principle where operations are reversible and users initiate actions rather than react to system behavior.
Reduce Userâs Memory Load
Design guidance to minimize the amount of information users must remember by keeping cues visible.
Consistent User Interface
Maintaining uniform visual and interaction patterns across an application to enhance learnability.