Method signature

Additional TopicsEntry

The Question

What defines a method signature and why does it matter?

What a Strong Answer Covers

• Name + parameters." self/cls distinction. Type hints vs runtime.

Senior-Level Answer

A method signature is the contract that describes how a method is called. It consists of:

**1. Method name** — the identifier used to call it.

**2. Parameter list** — the ordered set of parameters, each with a name and optionally a type. In statically typed languages like Java or TypeScript, parameter types are part of the signature and are enforced at compile time. In Python, type annotations are optional hints that tools like mypy enforce statically but the runtime does not.

**3. Return type** — what the method produces. Void/None means no meaningful return value. In Python this is annotated as `-> None` or `-> str`, etc.

In some languages, the signature also includes: - **Access modifiers** (public, private) — Java, C# - **Exceptions** in the throws clause — Java checked exceptions - **Generic type parameters** — `def process(items: list[T]) -> T`

**Overloading** (Java, C#, C++) allows multiple methods with the same name but different signatures — the compiler selects the correct one based on argument types and count. Python does not support true overloading; `@overload` decorators from `typing` are for type checkers only and do not affect runtime dispatch.

**Why signatures matter:** - They are the unit of abstraction in interfaces and abstract base classes — implementing a class means providing methods with matching signatures - They define API contracts: callers depend on the signature remaining stable - Documentation generators and IDEs use signatures to show usage hints - Type checkers enforce that call sites pass compatible types

A well-designed signature is narrow: it takes exactly the data the method needs and returns exactly what callers need, no more. 'Tell, don't ask' and the Principle of Least Knowledge both operate at the signature level.

What Separates a 2/3 from a 3/3

Common Mistakes

• Confusing signature with implementation — the body is not part of the signature
• Claiming Python supports overloading at runtime — it does not
• Forgetting return type as a signature component
• Not connecting signatures to interface/contract design

Follow-Up Questions

• How does method overloading differ from method overriding? — Overloading is multiple methods with the same name but different parameters (compile-time); overriding is a subclass replacing a parent's method (runtime).
• What is the Liskov Substitution Principle and how does it relate to signatures? — LSP says a subclass method must accept at least the parent's parameter types and return at most the parent's return type.
• How do Python's @overload decorators work? — They are type-checker hints only — the runtime sees only the last non-decorated implementation.
• Why should you avoid changing a public method's signature in a library? — It breaks all callers — semantic versioning requires a major version bump for signature-breaking changes.

Related Questions

• CAP theorem
• SQL vs NoSQL
• Big O basics
• N+1 problem
• AI tools in workflow