An opaque type hides its representation behind a stable interface. Clients use the exposed operations without depending on private structure, so the implementation can change without breaking them. section 1.4.1
The pattern divides a subsystem into an unstable private implementation and a stable public interface. In C, a public opaque type and the procedures that operate on it form the interface; in typed domain models, hiding constructors can also prevent invalid states. section 1.4.1 section 3.3.2
Expose only the surface clients need:
- Declare a type without revealing its structure, then provide functions for creating, using, and destroying its values. section 1.4.1
- Use smart constructors when unrestricted constructors could combine values incorrectly; export the valid construction paths while hiding representation details. section 3.3.2
- Choose deliberately between fully public types, internal modules for tests, and abstract data types with hidden structure. section 3.3.2
C interface with opaque pointers
A client can hold MYPROCOBJECT and MYPROCTYPE values and call visor_proc_CreateObject or visor_proc_DestroyObject, without accessing either structure's fields. The subsystem can therefore revise its representation behind the same procedural boundary. section 1.4.1
Preventing invalid device definitions
A public ComponentDef constructor permits an invalid controller built with a sensor passport. Smart constructors instead create sensor and controller definitions with the corresponding internal class, while the internal module keeps the representation available only at an explicit stability risk. section 3.3.2 section 3.3.2
#1
#2
typedef struct MYPROCOBJECT_Tag MYPROCOBJECT; #3
typedef struct MYPROCTYPE_Tag MYPROCTYPE;
MYPROCOBJECT *visor_proc_CreateObject(MYPROCTYPE *type, #4
const char *name,
void *context);
void visor_proc_DestroyObject(MYPROCOBJECT *obj);
Inspect the compact C declaration that separates opaque type names from the procedures clients use. section 1.4.1
