An Entity Manager is a core component of ORM (Object-Relational Mapping) frameworks, especially in Java (JPA – Java Persistence API), but also in other languages like PHP (Doctrine ORM).
Persisting:
Finding/Loading:
Retrieves an object by its ID or other criteria.
Example: $entityManager->find(User::class, 1);
Updating:
Tracks changes to objects and writes them to the database (usually via flush()
).
Removing:
Deletes an object from the database.
Example: $entityManager->remove($user);
Managing Transactions:
Begins, commits, or rolls back transactions.
Handling Queries:
Executes custom queries, often using DQL (Doctrine Query Language) or JPQL.
The Entity Manager tracks the state of entities:
managed (being tracked),
detached (no longer tracked),
removed (marked for deletion),
new (not yet persisted).
$user = new User();
$user->setName('Max Mustermann');
$entityManager->persist($user); // Mark for saving
$entityManager->flush(); // Write to DB
The Entity Manager is the central component for working with database objects — creating, reading, updating, deleting. It abstracts SQL and provides a clean, object-oriented way to interact with your data layer.
Aspect-Oriented Programming (AOP) is a programming paradigm focused on modularizing cross-cutting concerns—aspects of a program that affect multiple parts of the codebase and don't fit neatly into object-oriented or functional structures.
Typical cross-cutting concerns include logging, security checks, error handling, transaction management, or performance monitoring. These concerns often appear in many classes and methods. AOP allows you to write such logic once and have it automatically applied where needed.
Aspect: A module that encapsulates a cross-cutting concern.
Advice: The actual code to be executed (e.g., before, after, or around a method call).
Join Point: A point in the program flow where an aspect can be applied (e.g., method execution).
Pointcut: A rule that defines which join points are affected (e.g., "all methods in class X").
Weaving: The process of combining aspects with the main program code—at compile-time, load-time, or runtime.
@Aspect
public class LoggingAspect {
@Before("execution(* com.example.service.*.*(..))")
public void logBeforeMethod(JoinPoint joinPoint) {
System.out.println("Calling method: " + joinPoint.getSignature().getName());
}
}
This code automatically logs a message before any method in the com.example.service
package is executed.
Improved modularity
Reduced code duplication
Clear separation of business logic and system-level concerns
Can reduce readability (the flow isn't always obvious)
Debugging can become more complex
Often depends on specific frameworks (e.g., Spring, AspectJ)
Design by Contract (DbC) is a concept in software development introduced by Bertrand Meyer. It describes a method to ensure the correctness and reliability of software by defining clear "contracts" between different components (e.g., methods, classes).
In DbC, every software component is treated as a contract party with certain obligations and guarantees:
Preconditions
Conditions that must be true before a method or function can execute correctly.
→ Responsibility of the caller.
Postconditions
Conditions that must be true after the execution of a method or function.
→ Responsibility of the method/function.
Invariant (Class Invariant)
Conditions that must always remain true throughout the lifetime of an object.
→ Responsibility of both the method and the caller.
Clear specification of responsibilities.
More robust and testable software.
Errors are detected early (e.g., through contract violations).
class BankAccount {
private double balance;
// Invariant: balance >= 0
void withdraw(double amount) {
// Precondition: amount > 0 && amount <= balance
if (amount <= 0 || amount > balance) throw new IllegalArgumentException();
balance -= amount;
// Postcondition: balance has been reduced by amount
}
}
Clear contracts reduce misunderstandings.
Easier debugging, as violations are detected immediately.
Supports defensive programming.
Requires extra effort to define contracts.
Not directly supported by all programming languages (e.g., Java and C++ via assertions, Python with decorators; Eiffel supports DbC natively).
A Materialized View is a special type of database object that stores the result of a SQL query physically on disk, unlike a regular view which is computed dynamically every time it’s queried.
Stored on disk: The result of the query is saved, not just the query definition.
Faster performance: Since the data is precomputed, queries against it are typically much faster.
Needs refreshing: Because the underlying data can change, a materialized view must be explicitly or automatically refreshed to stay up to date.
Feature | View | Materialized View |
---|---|---|
Storage | Only the query, no data stored | Query and data are stored |
Performance | Slower for complex queries | Faster, as results are precomputed |
Freshness | Always up to date | Can become stale |
Needs refresh | No | Yes (manually or automatically) |
-- Creating a materialized view in PostgreSQL
CREATE MATERIALIZED VIEW top_customers AS
SELECT customer_id, SUM(order_total) AS total_spent
FROM orders
GROUP BY customer_id;
To refresh the data:
REFRESH MATERIALIZED VIEW top_customers;
For complex aggregations that are queried frequently
When performance is more important than real-time accuracy
In data warehouses or reporting systems
A Partial Mock is a testing technique where only certain methods of an object are mocked, while the rest of the object retains its real implementation. This is useful when you want to stub or mock specific methods but keep others functioning normally.
When you want to test a class but isolate certain methods.
When some methods are difficult to test (e.g., they have external dependencies), but others should retain their real logic.
When you only need to stub specific methods to control test behavior.
Suppose you have a Calculator
class but want to mock only the multiply()
method while keeping add()
as is.
class Calculator {
public function add($a, $b) {
return $a + $b;
}
public function multiply($a, $b) {
return $a * $b;
}
}
// PHPUnit Test with Partial Mock
class CalculatorTest extends \PHPUnit\Framework\TestCase {
public function testPartialMock() {
// Create a Partial Mock for Calculator
$calculator = $this->getMockBuilder(Calculator::class)
->onlyMethods(['multiply']) // Only mock this method
->getMock();
// Define behavior for multiply()
$calculator->method('multiply')->willReturn(10);
// Test real add() method
$this->assertEquals(5, $calculator->add(2, 3));
// Test mocked multiply() method
$this->assertEquals(10, $calculator->multiply(2, 3));
}
}
Here, add()
remains unchanged and executes the real implementation, while multiply()
always returns 10
.
Partial Mocks are useful when you need to isolate specific parts of a class without fully replacing it. They help make tests more stable and efficient by mocking only selected methods.
An object-oriented database management system (OODBMS) is a type of database system that combines the principles of object-oriented programming (OOP) with the functionality of a database. It allows data to be stored, retrieved, and managed as objects, similar to how they are defined in object-oriented programming languages like Java, Python, or C++.
Object Model:
Classes and Inheritance:
Encapsulation:
Persistence:
Object Identity (OID):
Complex Data Types:
Object-oriented databases are particularly useful for managing complex, hierarchical, or nested data structures commonly found in modern software applications.
Object Query Language (OQL) is a query language similar to SQL (Structured Query Language) but specifically designed for object-oriented databases. It is used to query data from object-oriented database systems (OODBs), which store data as objects. OQL was defined as part of the Object Data Management Group (ODMG) standard.
Object-Oriented Focus:
SQL-Like Syntax:
Querying Complex Objects:
Support for Methods:
Integration with Object-Oriented Languages:
Suppose there is a database with a class Person
that has the attributes Name
and Age
. An OQL query might look like this:
SELECT p.Name
FROM Person p
WHERE p.Age > 30
This query retrieves the names of all people whose age is greater than 30.
In practice, OQL is less popular than SQL since relational databases are still dominant. However, OQL is very powerful in specialized applications that utilize object-oriented data models.
Dynamic HTML (DHTML) is a combination of technologies used to create interactive and dynamic web content. It’s not a standalone standard or programming language but rather a collection of techniques and tools that work together. DHTML enables websites to update content dynamically and provide interactivity without reloading the entire page.
HTML (Hypertext Markup Language)
Provides the basic structure of the webpage.
CSS (Cascading Style Sheets)
Controls the appearance and layout of the webpage. CSS can be dynamically altered to create effects like hover states or style changes.
JavaScript
Adds interactivity and dynamic behavior, such as updating content without a page reload.
DOM (Document Object Model)
A programming interface that allows access to and manipulation of the webpage’s structure. JavaScript interacts with the DOM to change content or add new elements.
Here’s a simple example of a button changing text dynamically:
<!DOCTYPE html>
<html>
<head>
<style>
#text {
color: blue;
font-size: 20px;
}
</style>
<script>
function changeText() {
document.getElementById("text").innerHTML = "Text changed!";
document.getElementById("text").style.color = "red";
}
</script>
</head>
<body>
<p id="text">Original text</p>
<button onclick="changeText()">Click me</button>
</body>
</html>
Nowadays, DHTML has been largely replaced by modern techniques like AJAX and frameworks (e.g., React, Vue.js). However, it was a crucial step in the evolution of interactive web applications.
Data Definition Language (DDL) is a part of SQL (Structured Query Language) that deals with defining and managing the structure of a database. DDL commands modify the metadata of a database, such as information about tables, schemas, indexes, and other database objects, rather than manipulating the actual data.
1. CREATE
Used to create new database objects like tables, schemas, views, or indexes.
Example:
CREATE TABLE Kunden (
ID INT PRIMARY KEY,
Name VARCHAR(50),
Alter INT
);
2. ALTER
Used to modify the structure of existing objects, such as adding or removing columns.
Example:
ALTER TABLE Kunden ADD Email VARCHAR(100);
3. DROP
Permanently deletes a database object, such as a table.
Example:
DROP TABLE Kunden;
4. TRUNCATE
Removes all data from a table while keeping its structure intact. It is faster than DELETE
as it does not generate transaction logs.
Example:
TRUNCATE TABLE Kunden;
DDL is essential for designing and managing a database and is typically used during the initial setup or when structural changes are required.
The Document Object Model (DOM) is a standardized interface provided by web browsers to represent and programmatically manipulate structured documents, especially HTML and XML documents. It describes the hierarchical structure of a document as a tree, where each node represents an element, attribute, or text.
Tree Structure:
<html>
element, with child nodes such as <head>
, <body>
, <div>
, <p>
, etc.Object-Oriented Representation:
Interactivity:
<p>
element or insert a new <div>
.Platform and Language Agnostic:
1. Accessing an Element:
let element = document.getElementById("myElement");
2. Changing Content:
element.textContent = "New Text";
3. Adding a New Element:
let newNode = document.createElement("div");
document.body.appendChild(newNode);
The DOM is defined and maintained by the W3C (World Wide Web Consortium) standards and is constantly updated to support modern web technologies.