ตัวปรับแต่งและรูปแบบตรวจสอบ-ผลกระทบ-การโต้ตอบ

A modifier is reusable code that runs before (or around) a function body. It is ideal for enforcing preconditions like access control without repeating the same checks everywhere.

The special _; placeholder marks where the function body executes. Code before it runs first; code after runs when the function returns.

Attach a modifier to a function declaration. The check runs automatically on every call, keeping the function body focused on logic.

Modifiers can take arguments, making them flexible for validating dynamic conditions such as minimum values.

You can apply several modifiers to one function; they run left to right. Keep them small and single-purpose so combinations stay predictable.

When a contract calls out to an external address, that address can call back into your contract before the first call finishes. This reentrancy can drain funds if state is updated too late.

The checks-effects-interactions pattern orders your function in three phases: validate inputs (checks), update state (effects), then call external contracts (interactions). External calls come last.

This sends ETH before zeroing the balance, leaving a reentrancy window.

Update state before the external call so a reentrant call sees a zero balance.

For extra safety, add a reentrancy guard modifier that sets a lock flag during execution, rejecting nested calls. Libraries like OpenZeppelin provide nonReentrant.

Use modifiers for the checks phase (access and validation), structure the body as effects-then-interactions, and add a guard on functions that move value. Together they form a strong defensive baseline.

You learned defensive Solidity patterns:

• Modifiers centralize preconditions like access control
• They can take parameters and be stacked
• Checks-effects-interactions orders functions to prevent reentrancy
• Add a reentrancy guard on value-moving functions

These patterns are foundational to writing secure contracts.