Frontend

Shared Concepts Study Portal

Cross-cutting frontend patterns and practices
Flash Cards Practice
Frontend / Shared Concepts / I Interface Segregation Principle ISP / Quick recall Q&A

I Interface Segregation Principle ISP · Quick recall Q&A

2 min read
Mid-level2 min read
Rapid overview

Quick recall Q&A

Q: How does ISP improve React component reusability? A: Components with minimal prop requirements can be used in more contexts. A <Button onClick={...}> is more reusable than <Button form={formObject}> that requires a fat form interface.
  • Accept props they never use
  • Pass entire objects when they only need one or two properties
  • Implement optional methods that throw "not supported" errors
  • Have any or overly broad types to avoid interface constraints
Q: What's a sign you need ISP in React? A: Components that:
// Bad - hook requires entire user service
function useUserName(userService: UserService) {
  // Only uses getName method
}

// Good - hook requires only what it needs
function useUserName(getName: (id: string) => string) {
  // Minimal dependency
}
Q: How does ISP relate to React hooks? A: Custom hooks should accept focused dependencies:
providers: [
  UserService,
  { provide: ReadableUserService, useExisting: UserService },
  { provide: WritableUserService, useExisting: UserService }
]

// Components inject what they need
constructor(private users: ReadableUserService) {}
Q: How do interface segregations interact with dependency injection in Angular? A: Inject only the interface you need. Angular allows providing multiple interfaces with the same implementation:
  • Change together (all CRUD operations might stay together)
  • Serve the same use case
  • Have similar client needs
Q: How do you avoid explosion of tiny interfaces? A: Segregate by cohesive responsibilities, not per method. Group operations that:

Don't create one interface per method unless methods truly serve different concerns.

// Easy to mock
const mockPlayable: Playable = {
  play: jest.fn(),
  pause: jest.fn(),
  stop: jest.fn()
};

// vs mocking a 20-method interface
Q: How does ISP benefit testing? A: Smaller interfaces mean simpler mocks:
// Over-segregated
interface Clickable { onClick(): void; }
interface Hoverable { onHover(): void; }
interface Focusable { onFocus(): void; }

// Better - cohesive interaction interface
interface Interactive {
  onClick(): void;
  onHover(): void;
  onFocus(): void;
}
Q: Can over-segregation hurt? A: Yes. Too many tiny interfaces create noise:

Balance between focused and practical.

// Bad - single fat context
const AppContext = createContext({
  user, setUser,
  theme, setTheme,
  notifications, addNotification,
  settings, updateSettings
});

// Good - segregated contexts
const UserContext = createContext({ user, setUser });
const ThemeContext = createContext({ theme, setTheme });
const NotificationContext = createContext({ notifications, addNotification });
const SettingsContext = createContext({ settings, updateSettings });

// Components consume only what they need
function Avatar() {
  const { user } = useContext(UserContext); // Only user context
  return <img src={user.avatar} />;
}
Q: How does ISP apply to React Context? A: Split large contexts into focused ones:
// Bad - component depends on entire state shape
function UserProfile({ state }: { state: AppState }) {
  return <div>{state.user.profile.name}</div>;
}

// Good - component depends on minimal data
function UserProfile({ userName }: { userName: string }) {
  return <div>{userName}</div>;
}

// Container uses focused selector
const mapStateToProps = (state: AppState) => ({
  userName: selectUserName(state) // Minimal interface
});
Q: How does ISP apply to Redux/state management? A: Create focused selectors and action creators instead of exposing the entire store:
// Can import and use AudioPlayer without pulling in video codec dependencies
import { AudioPlayer } from '@/players';
Q: How does ISP help with bundle size? A: Segregated interfaces enable better tree-shaking. Import only the interfaces/implementations you need:
  • Interfaces have single, clear purposes
  • Components don't accept props they never use
  • Services don't implement methods that throw "not supported"
  • Type definitions match actual usage patterns
  • No large "god objects" passed around
Q: How do you enforce ISP in code reviews? A: Check that:

See also