cecs 343 final part 1

implentation object model solid principles

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.