Concept questionEasy~5 minC# OOP & Type Design Essentials / 1 of 15

Interview question

When you model a business feature in C#, how do you decide what should become an object and what responsibility it should own?

Model objects around responsibilities and invariants

Starts object-oriented design from cohesive state and behavior instead of creating classes for every noun in a requirement.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I start with behavior and rules: what decisions must the software make, and which state must stay consistent while making them? An Order can own valid order transitions, while Money can own amount and currency rules. A request DTO may only carry data and does not need domain behavior. I keep responsibilities together when they change for the same reason.

Full answer below

Practice focus

State, behavior, cohesion, invariants, value objects, services, data transfer objects, and avoiding noun-driven class diagrams.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A useful object owns a coherent concept and the behavior needed to keep that concept valid. Object-oriented design is not the exercise of turning every noun in a requirement into a class.
I start with behavior and rules: what decisions must the software make, and which state must stay consistent while making them? An Order can own valid order transitions, while Money can own amount and currency rules. A request DTO may only carry data and does not need domain behavior. I keep responsibilities together when they change for the same reason.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I look for invariants that should hold regardless of which endpoint or job invokes the operation. Those rules belong behind an object or policy API rather than being repeated in controllers. I avoid objects that merely expose every field through getters and setters while a generic service performs all decisions. I also avoid forcing simple reference data into rich models when plain data is honest and sufficient.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I test whether the model reduces invalid states and change blast radius. If one rule change touches many unrelated objects, the responsibility is fragmented; if one object knows persistence, email, pricing, and authorization, it is overloaded. Aggregate boundaries follow consistency and concurrency needs rather than the shape of an object graph. I evolve the model from real use cases and repeated changes, keeping public behavior stable while internals improve. The goal is understandable ownership, not a perfect mirror of business vocabulary.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Creating a class for every noun.
Putting all behavior in one generic service.
Giving every property a public setter.
Building a rich domain model for simple lookup data.

Red flagsCandidateSigns the object design is fragileSignals that an interviewer may treat as risky.Open details

Details

No type clearly owns an invariant.
One rule is duplicated across several entry points.
Objects expose data but cannot perform meaningful operations.
A single object depends on every technical subsystem.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Can a DTO be intentionally behaviorless?
What makes a responsibility cohesive?
How do invariants influence object boundaries?

Continue the section

Next in C# OOP & Type Design Essentials: Encapsulation

Step 2 of 15

Encapsulation and protecting object invariants

Opening drill

Concept questionEasy~5 minC# OOP & Type Design Essentials / 1 of 15

Interview question

When you model a business feature in C#, how do you decide what should become an object and what responsibility it should own?

Model objects around responsibilities and invariants

Starts object-oriented design from cohesive state and behavior instead of creating classes for every noun in a requirement.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

State, behavior, cohesion, invariants, value objects, services, data transfer objects, and avoiding noun-driven class diagrams.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A useful object owns a coherent concept and the behavior needed to keep that concept valid. Object-oriented design is not the exercise of turning every noun in a requirement into a class.
I start with behavior and rules: what decisions must the software make, and which state must stay consistent while making them? An Order can own valid order transitions, while Money can own amount and currency rules. A request DTO may only carry data and does not need domain behavior. I keep responsibilities together when they change for the same reason.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I look for invariants that should hold regardless of which endpoint or job invokes the operation. Those rules belong behind an object or policy API rather than being repeated in controllers. I avoid objects that merely expose every field through getters and setters while a generic service performs all decisions. I also avoid forcing simple reference data into rich models when plain data is honest and sufficient.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I test whether the model reduces invalid states and change blast radius. If one rule change touches many unrelated objects, the responsibility is fragmented; if one object knows persistence, email, pricing, and authorization, it is overloaded. Aggregate boundaries follow consistency and concurrency needs rather than the shape of an object graph. I evolve the model from real use cases and repeated changes, keeping public behavior stable while internals improve. The goal is understandable ownership, not a perfect mirror of business vocabulary.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Creating a class for every noun.
Putting all behavior in one generic service.
Giving every property a public setter.
Building a rich domain model for simple lookup data.

Red flagsCandidateSigns the object design is fragileSignals that an interviewer may treat as risky.Open details

Details

No type clearly owns an invariant.
One rule is duplicated across several entry points.
Objects expose data but cannot perform meaningful operations.
A single object depends on every technical subsystem.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Can a DTO be intentionally behaviorless?
What makes a responsibility cohesive?
How do invariants influence object boundaries?

Continue the section

Next in C# OOP & Type Design Essentials: Encapsulation

Step 2 of 15

Encapsulation and protecting object invariants

When you model a business feature in C#, how do you decide what should become an object and what responsibility it should own?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

When you model a business feature in C#, how do you decide what should become an object and what responsibility it should own?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section