CONCEPT Cited by 1 source

Base-class instrumentation¶

Definition¶

Base-class instrumentation is the practice of placing cross-cutting measurement / logging / analytics logic into an ancestor class that all relevant subclasses inherit from — so every subclass receives the behaviour automatically, without adding per-subclass code. It's an inheritance-based realisation of the broader aspect-oriented pattern of moving cross-cutting concerns out of the call sites and into the substrate.

Pinterest's 2026-04-08 post is the canonical wiki instance: "we built the Visually Complete logic into the base UI class (e.g. BaseSurface). Therefore, the Perceived Latency of any UI surface (existing or new) will be automatically measured as long as the feature is built on top of this base UI class." (Source: sources/2026-04-08-pinterest-performance-for-everyone).

Why inheritance is the right tool here¶

The key property being exploited: every feature screen on Pinterest Android must inherit BaseSurface by convention / by compiler-enforced contract / by framework requirement. That shared ancestor is the natural place to put:

Lifecycle-aware logic (screen appeared / disappeared / paused).
Tree-walking logic (every screen has a view-tree root).
Emission logic (every screen has a screen-name, user-session, traffic-segment).
Sampling and dispatch logic.

Subclasses get the behaviour for free without touching their own code, and the platform team can iterate (add new metrics, fix bugs, tune sampling) by editing one class rather than 60+ feature modules.

What this enables — and how it connects to economics¶

Instrumentation engineering cost collapses: Pinterest disclosed a pre-platform cost of two engineer-weeks per surface to add User Perceived Latency measurement. After moving the logic into BaseSurface plus requiring a small opt-in tag-views step from product engineers, 60+ Android surfaces are continuously measured with essentially zero per-surface engineering cost (Source: sources/2026-04-08-pinterest-performance-for-everyone).

What it trades off¶

Base-class instrumentation buys coverage, but:

Opacity — behaviours inherited from the base class can surprise subclasses; debugging "why did my screen emit a latency timestamp at that weird moment?" requires reading BaseSurface code.
Coupling — every subclass is coupled to the base class's behaviour; changes in BaseSurface can break every screen simultaneously.
Requires the base-class contract to exist — if screens can be implemented without inheriting from BaseSurface, coverage is incomplete. Pinterest's "as long as the feature is built on top of this base UI class" qualifier is load-bearing: teams that bypass the base class are not instrumented.
Single-inheritance languages cap extensibility — Java/Kotlin (Android) have single inheritance, so BaseSurface is the only ancestor; stacking multiple base-class-instrumentation layers requires either deeper hierarchies or composition.

Framework middleware — HTTP handler middleware, gRPC interceptors, web framework filters — the stateless analogue for request/response pipelines.
Function-of-function decorators — higher-order function wrappers that add behaviour around a wrapped call; used heavily in Python, JavaScript, Go.
Bytecode instrumentation / AOP — Java agents, @Aspect in AspectJ; attach behaviour to any matched call site rather than requiring inheritance.
Framework lifecycle callbacks — iOS UIViewController.viewDidAppear, React useEffect, Android onResume; different surfaces of the same idea — let the framework invoke your code at the right moment.
Composition over inheritance — delegates and protocol conformance can achieve the same without inheritance, at the cost of opt-in boilerplate per subclass.

Pinterest's BaseSurface + PerfView marker interfaces is a hybrid: base-class provides the measurement loop, opt-in marker interfaces let product engineers control what counts toward the predicate. This combines automatic instrumentation with explicit tagging.

Caveats¶

Pattern-form canonicalisation is at patterns/base-class-automatic-instrumentation — this page is the conceptual framing.
The "all subclasses inherit from one base" contract may not hold in real Android projects — feature teams can introduce intermediate base classes or bypass the convention. Pinterest's post treats the contract as universal on Android surfaces but doesn't discuss enforcement.
Does not apply to UIs with no base-class convention (e.g. SwiftUI's declarative-view graph) — there, the analogue is typically a view-modifier or environment-value injected at the App / Scene entry point.

Seen in¶

2026-04-08 Pinterest — Performance for Everyone (sources/2026-04-08-pinterest-performance-for-everyone) — canonical; Visually Complete logic built into BaseSurface, paired with opt-in marker interfaces; 60+ Android surfaces instrumented for free post-rollout.