Step 0: Understand & Restate the Problem with Inheritance in Mind

Section 9.6 Step 0: Understand & Restate the Problem with Inheritance in Mind

When applying Step 0 (Understand & Restate), you typically paraphrase the problem, clarify inputs, outputs, and constraints, and document assumptions and edge cases. When planning a class hierarchy, this step should explicitly highlight overlapping or repeated requirements that suggest a superclass or an inheritance relationship.

🔗

For example, imagine you have the following problem statement:

🔗

"We need to implement a social media application that allows users to create different types of posts: text-only posts, photo posts with captions, and video posts with descriptions. All posts need to track the author, timestamp, number of likes, and comments. Users should be able to like any post type and add comments to any post. Additionally, photo and video posts need to track media size and resolution."
🔗

🔗

Applying Step 0 with inheritance explicitly in mind, you might restate the problem like this:

🔗

Example 9.6.1. Restatement with Inheritance Focus.

"We need classes to represent various post types in our social media application: TextPost, PhotoPost, and VideoPost. All posts share common attributes and behaviors: each has an author, timestamp, likeCount, and a collection of comments. All posts support operations like addComment() and like(). Media-based posts,specifically PhotoPost and VideoPost, share additional attributes related to the media itself, such as fileSize and resolution. Recognizing these similarities suggests we should introduce a general Post superclass for common fields and methods, and possibly an intermediate class like MediaPost to capture media-related properties."

🔗

Notice how clearly stating these overlaps early on gives you a roadmap for your class hierarchy even before defining any fields or writing any methods. In this step, you don’t yet commit to a final design. You simply identify potential inheritance relationships based on common functionality or data.

🔗

Subsection 9.6.1 Identifying Common Attributes and Behaviors

When analyzing requirements for a system with multiple classes, pay special attention to phrases that indicate shared characteristics:

🔗

"All posts must track likes and comments"

🔗
"Every user type needs a username and password"

🔗
"Each notification requires a timestamp and message"

🔗

These common requirements often signal potential superclasses or shared interfaces. For example:

🔗

Creating a social media app with the following post types:

🔗

Text posts with content, author, timestamp, likes

🔗
Photo posts with image, caption, author, timestamp, likes

🔗
Video posts with video file, description, author, timestamp, likes

🔗

Creating a social media app with various post types that share common attributes:

🔗

Common to all posts: author, timestamp, likes, comments

🔗
Post-specific: content type (text/image/video) and related properties

🔗
Probable superclass: Post with common fields and methods

🔗
Subclasses: TextPost, PhotoPost, VideoPost with specialized content

🔗

When analyzing requirements, create a simple table to track common vs. specialized attributes:

🔗

Entity	Common Attributes	Specialized Attributes
TextPost	author, timestamp, likeCount, 🔗 comments, addComment(), like() 🔗	textContent, wordCount
PhotoPost	author, timestamp, likeCount, 🔗 comments, addComment(), like() 🔗	imageFile, caption, resolution
VideoPost	author, timestamp, likeCount, 🔗 comments, addComment(), like() 🔗	videoFile, description, duration, resolution

From this analysis, we can clearly see that the "Common Attributes" column identifies potential fields and methods for a Post superclass, while the "Specialized Attributes" belong in the respective subclasses.

🔗

Subsection 9.6.2 Documenting Potential Hierarchies

As part of Step 0, start documenting potential class hierarchies using simple diagrams or bullet-point lists:

🔗

Post (superclass)
 ├── TextPost
 ├── MediaPost (intermediate class)
 │    ├── PhotoPost
 │    └── VideoPost

This early documentation serves as a working hypothesis for your class structure that you’ll refine in subsequent steps of the design recipe.

🔗

Note 9.6.2. Going Beyond "is-a" Relationships.

While looking for superclasses, also consider potential interfaces for capabilities that cross hierarchies. For example, both posts and user profiles might be Likeable but belong to different class hierarchies. This might suggest an interface like Likeable with methods such as like() and getLikeCount().

🔗

Insight 9.6.3. Anticipate Future Extensions.

While restating the problem, consider potential future expansions or new classes you might add later. Ask yourself questions like:

🔗

"Could we add more post types later (e.g., Poll posts or Event posts)? What would they have in common?"

🔗
"Would future content types share existing fields and methods? If yes, our superclass design becomes even more valuable."

🔗
"Are there scenarios where inheritance might complicate rather than simplify our structure (e.g., Stories that disappear after 24 hours)?"

🔗

Explicitly documenting these thoughts helps you choose inheritance strategically rather than automatically.

🔗

You have attempted of activities on this page.

🔗

Prev Top Next