software dev final

OOP inheritance model

A parent (super) class sits at the top; child (sub) classes inherit its attributes and behaviors. Java supports single and hierarchical inheritance — one parent, many possible child branches.

Essential features of OOP inheritance

① Hierarchical org — tree structure; parent is general, children specialize and can override. ② Code reusability — no duplicate logic; refactoring is easier. ③ Method overriding & overloading. ④ Enables polymorphism and encapsulation.

What OOP enables in programming

OOP lets you decompose a problem into classes (entities), each with its own methods and data. Combines structured programming with inheritance, polymorphism, abstraction, and encapsulation — guided by S.O.L.I.D. principles.

5 phases of the SDLC

① Requirements & feasibility → ② Design (algorithms, UX) → ③ Implementation (code & debug) → ④ Testing (auto + human) → ⑤ Evolution: deploy + ongoing maintenance.

Key values of the Agile manifesto

① Individuals & interactions over processes & tools. ② Working software over comprehensive documentation. ③ Customer collaboration over contract negotiation. ④ Responding to change over following a plan.

Disadvantages of the Waterfall model

① High risk — bad fit for complex projects. ② Cannot accept requirement changes mid-development. ③ Going back to an earlier phase is expensive. ④ Testing happens late, so early risks are missed and hard to mitigate.

Abstract classes vs. interface classes

Abstract class: can have implemented methods + variables; a class can only inherit one. Interface: only method signatures, no implementation; a class can implement many. Abstract = "is-a" relationship. Interface = "can-do" capability.

Coding standard principles

Core principle: maintainability — ease of modifying software to fix bugs, meet new requirements, or cope with change. ~60–80% of a software system's lifetime cost goes to maintenance. Conventions aren't enforced by compilers — they're enforced by the team.

Good programming practices

① Methods: 1–25 lines, do only one job (high cohesion). ② Use meaningful variable names. ③ Return empty collections instead of null. ④ Close DB connections/file streams in a finally block. ⑤ Use try-catch with logging in the data layer.

When to use Agile methodology

Use Agile when: requirements change frequently, the team is experienced, you need to respond to market dynamics, requirements are ambiguous (e.g., R&D), or the project is complex and long-running.

4 SQL DDL commands

CREATE — makes a new table. ALTER — modifies an existing table. TRUNCATE — wipes all rows but keeps the structure. DROP — deletes the entire table (structure + data, permanently gone).

4 SQL DML commands

SELECT — queries data. INSERT INTO — adds new rows. UPDATE — modifies existing rows. DELETE — removes rows. These manipulate data inside tables (DDL shapes the tables themselves).

Purpose of a database connection

A channel between the client and SQL server through which commands are sent and results returned. Connections consume resources — always close them when done; don't rely on the OS. Multiple clients can connect to the same server simultaneously.

What a database schema diagram shows

A schema describes a collection of data using a data model. It shows tables, their columns/fields, primary and foreign keys, and how tables relate to each other — without showing the actual data stored inside.

Design pattern

Reusable abstract knowledge about a problem and its solution. It describes the problem and the essence of the solution — abstract enough to apply in many contexts, typically using OOP concepts like inheritance and polymorphism.

3 main categories of design patterns

① Creational — flexible object creation, separating creation from use. ② Structural — organizing classes/objects into larger structures using OOP constructs. ③ Behavioral — defining how objects communicate and interact.

Elements of a design pattern

① A name, ② a description of the problem it solves, ③ the essence of the solution using OOP, and ④ consequences/context — must be abstract enough to reuse across different settings.

Façade pattern — use cases

Provides a single, simplified interface to a complex set of subsystems. Example: wrapping complicated back-end database operations behind one clean API so callers don't need to know the internal complexity.

Decorator pattern — use cases

Extends an object's functionality at runtime without modifying its class. Example: adding a scrollbar or border to a GUI widget by wrapping it in a decorator rather than altering the original class.

Observer pattern — use cases

Automatically notifies multiple objects when the state of one object changes. Implements publish/subscribe. Example: multiple UI components that all refresh automatically when the underlying data model changes.

Strategy pattern — use cases

Dynamically selects the best-fit algorithm at runtime without changing the calling code. Example: an app that switches between different sorting algorithms depending on data type or size.

Singleton pattern — use cases

Ensures only one instance of a class exists across the entire application. Example: a central logging object accessible from anywhere, or a single shared database connection pool.

User requirements vs. system requirements

User requirements: plain language + diagrams describing what the system does; written for customers. System requirements: structured, detailed technical document defining functions, services, and constraints; for developers — often part of a formal contract.

Functional vs. non-functional requirements

Functional: specific services, behaviors, and reactions to inputs (the features). Non-functional: constraints like speed, reliability, security, or mandated tools. Non-functional applies to the whole system — if unmet, the system may be useless even if all features work.

Benefits of code review

① Shares knowledge, prevents info silos. ② Discovers bugs early. ③ Maintains standards and compliance. ④ Enhances security. ⑤ Increases team collaboration. ⑥ Improves overall code quality.

Approaches to code review

① Pair programming — two devs work simultaneously; great for knowledge transfer. ② Over-the-shoulder — reviewer watches author; fast but less objective. ③ Tool-assisted — pull requests + automation; scalable and measurable. ④ Email passing — async; easy to start but hard to track progress or verify changes.

Things to look for in code review

Design · Functionality (behaves as intended?) · Complexity (could it be simpler?) · Tests (correct & automated?) · Naming (variables and methods clear?) · Comments (useful?) · Style (follows guides?) · Documentation (updated?).

JavaDoc

A Sun Microsystems tool that generates HTML API documentation from special comment tags (/** ... */) written directly in Java source code. Annotate classes, methods, constructors, and fields in-code, and JavaDoc builds the full reference automatically.

DoxyGen

A documentation generator (1997) that scans source code for embedded comments and produces comprehensive docs. Outputs HTML, PDF, RTF, LaTeX, man pages. Works across C++, C, Java, and Python — broader than JavaDoc's Java-only scope.

Benefit JavaDoc offers a program

Developers embed formatted comments in Java code instead of maintaining separate documents. JavaDoc auto-generates up-to-date HTML API documentation, keeping docs in sync with the code and making the codebase easier to maintain and onboard new developers.

Types of databases — by function

Analytical (OLAP): read-only, tracks statistics and trends, used for analysis. Operational (OLTP): read-write, supports live transactions and real-time data manipulation.

Types of databases — by data model

Flat file: no links between files, lots of data repetition. Relational: tables linked by keys (most common today). Object-oriented: stores media and objects, not just text. NoSQL: non-relational umbrella — document, key-value, column-oriented, and graph databases.

Data model in software development

A data model is a collection of concepts for describing data. A schema is a specific description of a data collection using that model. The relational model (tables with rows + columns) is the most widely used. The schema defines columns, field types, and table relationships.

Test-Driven Development (TDD)

Write a failing test before writing any code. Implement just enough to pass it, then refactor and repeat in small increments. Never move on until the current test passes. Benefits: full code coverage, easy regression testing, and tests serve as living documentation.

TRUNCATE TABLE vs. DROP TABLE

TRUNCATE TABLE: deletes all rows but keeps the table structure — the table still exists and can receive new data. DROP TABLE: removes the entire table including its structure — it no longer exists in the database at all.

SQL injection attack

Injecting unauthorized SQL into a database through an insecure web app that doesn't validate input. Most common website vulnerability — a coding problem, not a DB problem. Prevention: use parameterized queries (Java: PreparedStatement; Python: SQLAlchemy) — never concatenate raw SQL strings.

Version control (VC) in software development

A system (e.g., Git) used during the Implementation phase to track every change to source code. Ensures team compatibility, confirms goals are met, supports documentation, and lets you roll back to any prior state.

Pipeline in DevOps

In DevOps (CI/CD), a pipeline automates the steps moving code from development → testing → production. Enables fast, reliable, repeatable software delivery without manual hand-offs. DevOps is itself an Agile methodology.

Code coupling

How much modules depend on each other. Data coupling (loosest/best): modules share only simple data parameters. Stamp coupling (tighter): a whole record is passed when only one field is needed. Goal: keep coupling loose so changes don't ripple everywhere.

Cohesion in software design

The degree to which a module's elements all serve a single, well-defined purpose. Each method should do only one job. High cohesion = easier to test, maintain, and understand. Dr. Johnson's rule: "Encapsulation = good cohesion."

Purpose of packages in software development

Packages group related classes and interfaces, prevent naming conflicts, control access visibility, and keep large codebases organized. They enforce encapsulation at the module level and are one of Java's core foundations.

Abstraction vs. data encapsulation

Abstraction: hides irrelevant details — emphasizes what an object does, not how it works internally. Primary tool for managing complexity in large programs. Encapsulation: bundles data + methods, restricts direct access via private fields + public getters/setters — protects data integrity and lets internals change without breaking callers.