CRP is the component-level equivalent of which SOLID principle?

CRP is the component-level equivalent of which SOLID principle?

• A. SRP
• B. ISP
• C. LSP
• D. DIP

Answer: (B)

The main idea being tested is designing at the component boundary so interfaces stay small and focused, so clients or other components only depend on what they actually need. At the component level, this means exposing narrow, cohesive interfaces that cover just the required capabilities, rather than a broad interface that drags in unrelated functionality. That’s why the Interface Segregation Principle is the best match. It says no client should be forced to depend on methods it doesn’t use. When you think about components, this translates to offering focused interfaces for each capability and allowing components to implement multiple, smaller interfaces rather than one big one. Clients or other components depend only on the subset they require, which reduces coupling and makes it easier to swap or modify components without ripple effects. For example, if a component provides both reporting and authentication through a single large interface, a consumer that only needs reporting would have to depend on the authentication-related methods as well. Splitting those capabilities into separate interfaces—one for reporting, one for authentication—lets the consumer depend only on the reporting interface, aligning with ISP and the idea behind CRP at the component level. The other SOLID principles address different concerns: SRP focuses on separating responsibilities within a single class, LSP on substituting derived types without breaking correctness, and DIP on depending on abstractions rather than concrete implementations. While related in spirit, none target the idea of minimizing the consumer’s dependency surface at the component boundary as directly as ISP does.

The main idea being tested is designing at the component boundary so interfaces stay small and focused, so clients or other components only depend on what they actually need. At the component level, this means exposing narrow, cohesive interfaces that cover just the required capabilities, rather than a broad interface that drags in unrelated functionality.

That’s why the Interface Segregation Principle is the best match. It says no client should be forced to depend on methods it doesn’t use. When you think about components, this translates to offering focused interfaces for each capability and allowing components to implement multiple, smaller interfaces rather than one big one. Clients or other components depend only on the subset they require, which reduces coupling and makes it easier to swap or modify components without ripple effects.

For example, if a component provides both reporting and authentication through a single large interface, a consumer that only needs reporting would have to depend on the authentication-related methods as well. Splitting those capabilities into separate interfaces—one for reporting, one for authentication—lets the consumer depend only on the reporting interface, aligning with ISP and the idea behind CRP at the component level.

The other SOLID principles address different concerns: SRP focuses on separating responsibilities within a single class, LSP on substituting derived types without breaking correctness, and DIP on depending on abstractions rather than concrete implementations. While related in spirit, none target the idea of minimizing the consumer’s dependency surface at the component boundary as directly as ISP does.