System DesignClasses & Objects

Attributes and Methods

LevelBeginner

Duration60 mins

TopicClasses & Objects

3 / 4

Designing Meaningful Attributes

The Art of Choosing What to Remember

Choosing the right attributes for a class is more art than science. Every domain concept has infinite potential properties you could capture—the challenge is deciding which ones you should. A Person class could track name, age, height, weight, eye color, favorite food, shoe size, childhood pets, and countless other details. But which attributes actually serve your application's needs?

Meaningful attributes are those that capture the essential characteristics of an entity within the context of your system. They're neither too few (leaving the class unable to fulfill its responsibilities) nor too many (cluttering the class with irrelevant data).

What You Will Learn

By the end of this page, you will know how to identify essential attributes for your classes, apply principles for choosing appropriate types and granularity, avoid common attribute design mistakes, and create classes that accurately model your domain.

Context-Driven Attribute Selection

The attributes a class needs depend entirely on the context in which it exists. The same real-world entity modeled for different purposes requires different attributes.

Example: The "Person" Entity

Consider how a Person would be modeled in different systems:

HR System: name, employeeId, department, salary, hireDate, manager
Healthcare System: name, dateOfBirth, bloodType, allergies, medicalHistory
E-Commerce System: name, email, shippingAddresses, paymentMethods, orderHistory
Social Network: name, username, profilePicture, friends, posts, interests

Each context demands different attributes because each system cares about different aspects of a person. There's no universal "correct" set of person attributes—correctness is defined by purpose.

The Guiding Question

When selecting attributes, ask: 'What does this system need to know about this entity to fulfill its responsibilities?' Any attribute that doesn't contribute to answering this question is probably unnecessary.

The Principle of Essential Properties:

Attributes should capture essential rather than incidental properties:

Essential properties define what the entity is in your context. An Order without items isn't really an order. An Employee without an ID can't function in an HR system.
Incidental properties are nice-to-have but not fundamental. An employee's favorite color might be interesting but irrelevant to HR operations.

This distinction isn't absolute—what's incidental in one system is essential in another. A social network cares about favorite colors; an HR system doesn't.

Attribute Granularity

How do you decide when a concept should be a single attribute versus multiple attributes versus a separate class? This question of granularity affects maintainability and flexibility.

The Name Example:

Should a person's name be:

A single String name?
Separate firstName and lastName?
A structured Name object with prefix, firstName, middleName, lastName, suffix?

The answer depends on your needs:

If you only display names as strings, one field suffices
If you sort by last name or address people by first name, you need separation
If you handle international names, formal titles, or generational suffixes, you need structure

Granularity Decision Guide
Consideration	Favor Single Attribute	Favor Multiple/Structured
Operations needed	Only store and display	Parse, sort, search, format differently
Validation complexity	Simple validation	Different rules for each part
Data variations	Uniform format	Multiple formats or optional parts
Future flexibility	Unlikely to change	May evolve with new requirements
Reusability	Unique to this class	Same structure appears elsewhere

GranularityExamples.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// COARSE GRANULARITY: Simple but inflexible
public class Employee {
    private String address;  // "123 Main St, Springfield, IL 62701"
}
 
// FINE GRANULARITY: Flexible but verbose
public class Employee {
    private String streetNumber;
    private String streetName;
    private String city;
    private String state;
    private String zipCode;
    private String country;
}
 
// APPROPRIATE GRANULARITY: Structured as a reusable object
public class Employee {
    private Address address;  // Encapsulates address complexity
}
 
public class Address {
    private String streetLine1;
    private String streetLine2;
    private String city;
    private String state;
    private String postalCode;
    private String country;
    
    // Address can validate itself, format itself, compare itself
    public String formatForMailing() { ... }
    public boolean isInternational() { ... }
    public boolean isValid() { ... }
}

Extract When Behavior Emerges

A strong signal for extracting attributes into a separate class is when you find yourself writing methods that operate only on those attributes. If you're writing validateAddress(), formatAddress(), parseAddress()—the address concept deserves its own class.

Choosing Attribute Types

The type you choose for an attribute communicates intent and enforces constraints. Thoughtful type selection prevents entire categories of bugs.

Principle: Use the Most Specific Type That Fits

Rather than using generic types, prefer types that express constraints:

Instead of String for email → use an EmailAddress value object
Instead of int for quantity → use a constrained Quantity or PositiveInt
Instead of String for status → use an enum OrderStatus
Instead of long for money → use a Money or BigDecimal with currency
Instead of String for phone → use a PhoneNumber value object

Primitive Obsession

•String email — any string is accepted
•int quantity — negatives are valid
•double price — floating point errors
•String status — typos compile
•long timestamp — unclear units

Rich Domain Types

•EmailAddress email — validated on creation
•Quantity quantity — enforces >= 0
•Money price — precise, with currency
•OrderStatus status — only valid values
•Instant timestamp — clear semantics

RichTypes.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// VALUE OBJECT: Encapsulates validation and semantics
public final class EmailAddress {
    private final String value;
    
    public EmailAddress(String value) {
        if (value == null || !isValidEmail(value)) {
            throw new IllegalArgumentException("Invalid email: " + value);
        }
        this.value = value.toLowerCase().trim();  // Normalize
    }
    
    private static boolean isValidEmail(String email) {
        // Real validation logic
        return email.contains("@") && email.contains(".");
    }
    
    public String getValue() { return value; }
    
    public String getDomain() {
        return value.substring(value.indexOf('@') + 1);
    }
    
    // Equals, hashCode, toString...
}
 
// USAGE: Impossible to have invalid email in the system
public class User {
    private EmailAddress email;  // Can never be null or invalid
    
    public void setEmail(EmailAddress email) {
        this.email = Objects.requireNonNull(email);
    }
}

Fighting Primitive Obsession

Primitive obsession—using primitives for domain concepts—is a pervasive code smell. Every time you validate a string parameter for format, consider: should this be a type that validates on construction? If yes, create a value object.

Handling Optional Attributes

Not every piece of data is always present. Some attributes are optional—they might have a value, or they might not. Handling optionality explicitly prevents null-related bugs.

The Problem with Nullable Attributes:

When an attribute can be null, every piece of code that accesses it must check for null. Forget a check, get a NullPointerException. The type system doesn't help—String and String-that-might-be-null have the same type.

Solutions for Optional Attributes:

Use Optional<T> — Makes absence explicit in the type
Use null-safe annotations — @Nullable, @NonNull for documentation
Provide sensible defaults — Empty string, empty collection, zero
Split into required/optional classes — Two classes with different field requirements
Use the Null Object pattern — A special "empty" instance

OptionalHandling.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
public class CustomerProfile {
    // REQUIRED: Must always have a value
    private final String customerId;
    private final String email;
    
    // OPTIONAL: May or may not have a value
    private final String phoneNumber;      // Could be null
    private final LocalDate dateOfBirth;   // Could be null
    
    // OPTION 1: Return Optional from getters
    public Optional<String> getPhoneNumber() {
        return Optional.ofNullable(phoneNumber);
    }
    
    public Optional<LocalDate> getDateOfBirth() {
        return Optional.ofNullable(dateOfBirth);
    }
    
    // OPTION 2: Provide null-safe utility methods
    public boolean hasPhoneNumber() {
        return phoneNumber != null;
    }
    
    public String getPhoneNumberOrDefault(String defaultValue) {
        return phoneNumber != null ? phoneNumber : defaultValue;
    }
    
    // OPTION 3: For collections, never null - empty instead
    private List<Address> addresses = new ArrayList<>();  // Never null
    
    public List<Address> getAddresses() {
        return Collections.unmodifiableList(addresses);  // Never null
    }
}
 
// CALLER CODE: Clear handling of optionality
profile.getPhoneNumber()
    .ifPresent(phone -> sendSMS(phone, message));
 
String phone = profile.getPhoneNumber()
    .orElse("Not provided");

Collections Should Never Be Null

A null collection forces callers to check for null before every operation. Return empty collections instead. There's no difference between 'no items' and 'null list' semantically—both mean zero items. But empty lists are safe to iterate; null lists throw exceptions.

Attribute Naming Conventions

Well-named attributes are self-documenting. Poor names obscure meaning and invite bugs.

Naming Principles:

Use nouns or noun phrases — Attributes are things, not actions
Be specific — deliveryAddress over address when there are multiple
Be consistent — Same concept, same name across classes
Avoid abbreviations — customerId not custId or cid
Use domain language — Match terms stakeholders use

Attribute Naming Examples
Poor Name	Better Name	Why It's Better
data	customerProfile	Specific, indicates content
flag	isActive	Boolean intent clear
temp	temperatureCelsius	Includes unit, clear purpose
list1	pendingOrders	Describes what's in the list
dt	createdAt	Clear meaning, standard pattern
x	xCoordinate	Full word, clear context
mgr	reportingManager	Unabbreviated, relationship clear

Special Naming Patterns:

Boolean attributes should read as assertions:

isActive, hasChildren, canEdit, shouldNotify
Avoid negatives: isValid not isNotInvalid

Collections should be plural:

orders, items, addresses
Consider the type: orderList (redundant), orders (better)

Timestamps should indicate the event:

createdAt, updatedAt, deletedAt, lastLoginAt

References to other objects should indicate relationship:

parentCategory, reportingManager, primaryAddress

Ubiquitous Language

Use the same terminology your domain experts use. If the business calls it a 'fulfillment center,' don't code it as 'warehouse.' Consistent language between code and domain reduces translation errors and improves communication.

Derived vs Stored Attributes

Some values can be either stored explicitly or computed from other data. Choosing correctly affects consistency, performance, and maintainability.

Stored Attributes:

Value is persisted directly
Fast to read (no computation)
Must be kept in sync manually
Can become stale if sources change

Derived Attributes:

Value is computed on demand
Always current (never stale)
Computation cost on every access
No synchronization burden

DerivedVsStored.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
public class Order {
    private List<OrderItem> items = new ArrayList<>();
    
    // DERIVED: Computed from source data
    // Always accurate, never stale, but computed each time
    public double getTotal() {
        return items.stream()
            .mapToDouble(OrderItem::getSubtotal)
            .sum();
    }
    
    public int getItemCount() {
        return items.size();
    }
    
    // Questions for each potential derived attribute:
    // 1. How expensive is the computation?
    // 2. How often is the value accessed?
    // 3. How often does source data change?
    // 4. How critical is it that the value is current?
}
 
// WHEN TO STORE INSTEAD:
public class HighVolumeOrder {
    private List<OrderItem> items = new ArrayList<>();
    private double cachedTotal;  // Stored for performance
    
    // Update cached value when items change
    public void addItem(OrderItem item) {
        items.add(item);
        cachedTotal += item.getSubtotal();  // Maintain cache
    }
    
    public void removeItem(OrderItem item) {
        if (items.remove(item)) {
            cachedTotal -= item.getSubtotal();  // Maintain cache
        }
    }
    
    public double getTotal() {
        return cachedTotal;  // O(1) access
    }
}

Default to Derived

Start with derived attributes. Only add caching (stored values) when profiling shows a performance problem. Premature caching adds complexity and synchronization bugs. The simplest correct solution is best until proven otherwise.

Common Attribute Design Mistakes

Experienced developers recognize these anti-patterns. Avoiding them leads to cleaner, more maintainable classes.

Anti-Patterns to Avoid

•God Objects — Classes with dozens of attributes covering unrelated concerns. Split into focused classes.
•Redundant Attributes — Storing values that can be derived from other attributes without performance justification.
•Stringly-Typed Data — Using String for everything: status, type, category, id. Use enums and value objects.
•Flag Explosion — Multiple boolean flags that control behavior: isActive, isDeleted, isArchived, isPending. Consider a state enum.
•Implicit Coupling — Attributes that only make sense together but aren't grouped: startDate/endDate, streetAddress/city/zip.
•Kitchen Sink Classes — Adding 'just one more attribute' repeatedly until the class is bloated. Refactor proactively.
•Nullable Everything — No distinction between required and optional. Be explicit about nullability.

RefactoringExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// BEFORE: Flag explosion, implicit coupling, stringly-typed
public class User {
    private String status;  // "active", "inactive", "suspended", "deleted"
    private boolean isVerified;
    private boolean hasCompletedOnboarding;
    private boolean is2FAEnabled;
    private String addressLine1;
    private String addressLine2;
    private String city;
    private String state;
    private String zipCode;
    private String country;
}
 
// AFTER: Enums, grouped attributes, clear structure
public class User {
    private UserStatus status;  // Enum: ACTIVE, INACTIVE, SUSPENDED, DELETED
    private UserFlags flags;    // Value object: verified, onboarded, 2fa
    private Address address;    // Value object: encapsulates address fields
}
 
public enum UserStatus {
    ACTIVE, INACTIVE, SUSPENDED, DELETED
}
 
public class UserFlags {
    private final boolean isVerified;
    private final boolean hasCompletedOnboarding;
    private final boolean is2FAEnabled;
    
    // Meaningful methods
    public boolean isFullyOnboarded() {
        return isVerified && hasCompletedOnboarding;
    }
}

Summary: Designing Meaningful Attributes

We've explored the principles and practices of attribute design. Let's consolidate:

Key Takeaways

•Context determines attributes — The same domain entity needs different attributes in different systems.
•Choose appropriate granularity — Single attribute, multiple attributes, or separate class—let the operations guide you.
•Use rich types over primitives — Value objects that validate on creation prevent invalid states.
•Handle optionality explicitly — Use Optional, annotations, or defaults. Never null for collections.
•Name with intention — Clear, specific, consistent names using domain language.
•Prefer derived over stored — Compute values to avoid synchronization; cache only when proven necessary.
•Avoid common anti-patterns — No god objects, flag explosions, or stringly-typed data.

What's Next:

We've covered how to design meaningful attributes. The final page in this module addresses the flip side: designing cohesive methods—methods that work together harmoniously, each with a clear purpose, creating classes that are focused and maintainable.

Page Complete

You now understand how to select and design attributes that serve your domain effectively. You can choose appropriate types and granularity, handle optionality, name attributes meaningfully, and avoid common pitfalls. Next, we'll design cohesive methods.

3 / 4

Loading learning content...

System DesignClasses & Objects

Attributes and Methods

LevelBeginner

Duration60 mins

TopicClasses & Objects

3 / 4

Designing Meaningful Attributes

The Art of Choosing What to Remember

What You Will Learn

Context-Driven Attribute Selection

The attributes a class needs depend entirely on the context in which it exists. The same real-world entity modeled for different purposes requires different attributes.

Example: The "Person" Entity

Consider how a Person would be modeled in different systems:

HR System: name, employeeId, department, salary, hireDate, manager
Healthcare System: name, dateOfBirth, bloodType, allergies, medicalHistory
E-Commerce System: name, email, shippingAddresses, paymentMethods, orderHistory
Social Network: name, username, profilePicture, friends, posts, interests

Each context demands different attributes because each system cares about different aspects of a person. There's no universal "correct" set of person attributes—correctness is defined by purpose.

The Guiding Question

The Principle of Essential Properties:

Attributes should capture essential rather than incidental properties:

Essential properties define what the entity is in your context. An Order without items isn't really an order. An Employee without an ID can't function in an HR system.
Incidental properties are nice-to-have but not fundamental. An employee's favorite color might be interesting but irrelevant to HR operations.

This distinction isn't absolute—what's incidental in one system is essential in another. A social network cares about favorite colors; an HR system doesn't.

Attribute Granularity

How do you decide when a concept should be a single attribute versus multiple attributes versus a separate class? This question of granularity affects maintainability and flexibility.

The Name Example:

Should a person's name be:

A single String name?
Separate firstName and lastName?
A structured Name object with prefix, firstName, middleName, lastName, suffix?

The answer depends on your needs:

If you only display names as strings, one field suffices
If you sort by last name or address people by first name, you need separation
If you handle international names, formal titles, or generational suffixes, you need structure

Granularity Decision Guide
Consideration	Favor Single Attribute	Favor Multiple/Structured
Operations needed	Only store and display	Parse, sort, search, format differently
Validation complexity	Simple validation	Different rules for each part
Data variations	Uniform format	Multiple formats or optional parts
Future flexibility	Unlikely to change	May evolve with new requirements
Reusability	Unique to this class	Same structure appears elsewhere

GranularityExamples.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// COARSE GRANULARITY: Simple but inflexible
public class Employee {
    private String address;  // "123 Main St, Springfield, IL 62701"
}
 
// FINE GRANULARITY: Flexible but verbose
public class Employee {
    private String streetNumber;
    private String streetName;
    private String city;
    private String state;
    private String zipCode;
    private String country;
}
 
// APPROPRIATE GRANULARITY: Structured as a reusable object
public class Employee {
    private Address address;  // Encapsulates address complexity
}
 
public class Address {
    private String streetLine1;
    private String streetLine2;
    private String city;
    private String state;
    private String postalCode;
    private String country;
    
    // Address can validate itself, format itself, compare itself
    public String formatForMailing() { ... }
    public boolean isInternational() { ... }
    public boolean isValid() { ... }
}

Extract When Behavior Emerges

Choosing Attribute Types

The type you choose for an attribute communicates intent and enforces constraints. Thoughtful type selection prevents entire categories of bugs.

Principle: Use the Most Specific Type That Fits

Rather than using generic types, prefer types that express constraints:

Instead of String for email → use an EmailAddress value object
Instead of int for quantity → use a constrained Quantity or PositiveInt
Instead of String for status → use an enum OrderStatus
Instead of long for money → use a Money or BigDecimal with currency
Instead of String for phone → use a PhoneNumber value object

Primitive Obsession

•String email — any string is accepted
•int quantity — negatives are valid
•double price — floating point errors
•String status — typos compile
•long timestamp — unclear units

Rich Domain Types

•EmailAddress email — validated on creation
•Quantity quantity — enforces >= 0
•Money price — precise, with currency
•OrderStatus status — only valid values
•Instant timestamp — clear semantics

RichTypes.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// VALUE OBJECT: Encapsulates validation and semantics
public final class EmailAddress {
    private final String value;
    
    public EmailAddress(String value) {
        if (value == null || !isValidEmail(value)) {
            throw new IllegalArgumentException("Invalid email: " + value);
        }
        this.value = value.toLowerCase().trim();  // Normalize
    }
    
    private static boolean isValidEmail(String email) {
        // Real validation logic
        return email.contains("@") && email.contains(".");
    }
    
    public String getValue() { return value; }
    
    public String getDomain() {
        return value.substring(value.indexOf('@') + 1);
    }
    
    // Equals, hashCode, toString...
}
 
// USAGE: Impossible to have invalid email in the system
public class User {
    private EmailAddress email;  // Can never be null or invalid
    
    public void setEmail(EmailAddress email) {
        this.email = Objects.requireNonNull(email);
    }
}

Fighting Primitive Obsession

Handling Optional Attributes

Not every piece of data is always present. Some attributes are optional—they might have a value, or they might not. Handling optionality explicitly prevents null-related bugs.

The Problem with Nullable Attributes:

Solutions for Optional Attributes:

Use Optional<T> — Makes absence explicit in the type
Use null-safe annotations — @Nullable, @NonNull for documentation
Provide sensible defaults — Empty string, empty collection, zero
Split into required/optional classes — Two classes with different field requirements
Use the Null Object pattern — A special "empty" instance

OptionalHandling.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
public class CustomerProfile {
    // REQUIRED: Must always have a value
    private final String customerId;
    private final String email;
    
    // OPTIONAL: May or may not have a value
    private final String phoneNumber;      // Could be null
    private final LocalDate dateOfBirth;   // Could be null
    
    // OPTION 1: Return Optional from getters
    public Optional<String> getPhoneNumber() {
        return Optional.ofNullable(phoneNumber);
    }
    
    public Optional<LocalDate> getDateOfBirth() {
        return Optional.ofNullable(dateOfBirth);
    }
    
    // OPTION 2: Provide null-safe utility methods
    public boolean hasPhoneNumber() {
        return phoneNumber != null;
    }
    
    public String getPhoneNumberOrDefault(String defaultValue) {
        return phoneNumber != null ? phoneNumber : defaultValue;
    }
    
    // OPTION 3: For collections, never null - empty instead
    private List<Address> addresses = new ArrayList<>();  // Never null
    
    public List<Address> getAddresses() {
        return Collections.unmodifiableList(addresses);  // Never null
    }
}
 
// CALLER CODE: Clear handling of optionality
profile.getPhoneNumber()
    .ifPresent(phone -> sendSMS(phone, message));
 
String phone = profile.getPhoneNumber()
    .orElse("Not provided");

Collections Should Never Be Null

Attribute Naming Conventions

Well-named attributes are self-documenting. Poor names obscure meaning and invite bugs.

Naming Principles:

Use nouns or noun phrases — Attributes are things, not actions
Be specific — deliveryAddress over address when there are multiple
Be consistent — Same concept, same name across classes
Avoid abbreviations — customerId not custId or cid
Use domain language — Match terms stakeholders use

Attribute Naming Examples
Poor Name	Better Name	Why It's Better
data	customerProfile	Specific, indicates content
flag	isActive	Boolean intent clear
temp	temperatureCelsius	Includes unit, clear purpose
list1	pendingOrders	Describes what's in the list
dt	createdAt	Clear meaning, standard pattern
x	xCoordinate	Full word, clear context
mgr	reportingManager	Unabbreviated, relationship clear

Special Naming Patterns:

Boolean attributes should read as assertions:

isActive, hasChildren, canEdit, shouldNotify
Avoid negatives: isValid not isNotInvalid

Collections should be plural:

orders, items, addresses
Consider the type: orderList (redundant), orders (better)

Timestamps should indicate the event:

createdAt, updatedAt, deletedAt, lastLoginAt

References to other objects should indicate relationship:

parentCategory, reportingManager, primaryAddress

Ubiquitous Language

Derived vs Stored Attributes

Some values can be either stored explicitly or computed from other data. Choosing correctly affects consistency, performance, and maintainability.

Stored Attributes:

Value is persisted directly
Fast to read (no computation)
Must be kept in sync manually
Can become stale if sources change

Derived Attributes:

Value is computed on demand
Always current (never stale)
Computation cost on every access
No synchronization burden

DerivedVsStored.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
public class Order {
    private List<OrderItem> items = new ArrayList<>();
    
    // DERIVED: Computed from source data
    // Always accurate, never stale, but computed each time
    public double getTotal() {
        return items.stream()
            .mapToDouble(OrderItem::getSubtotal)
            .sum();
    }
    
    public int getItemCount() {
        return items.size();
    }
    
    // Questions for each potential derived attribute:
    // 1. How expensive is the computation?
    // 2. How often is the value accessed?
    // 3. How often does source data change?
    // 4. How critical is it that the value is current?
}
 
// WHEN TO STORE INSTEAD:
public class HighVolumeOrder {
    private List<OrderItem> items = new ArrayList<>();
    private double cachedTotal;  // Stored for performance
    
    // Update cached value when items change
    public void addItem(OrderItem item) {
        items.add(item);
        cachedTotal += item.getSubtotal();  // Maintain cache
    }
    
    public void removeItem(OrderItem item) {
        if (items.remove(item)) {
            cachedTotal -= item.getSubtotal();  // Maintain cache
        }
    }
    
    public double getTotal() {
        return cachedTotal;  // O(1) access
    }
}

Default to Derived

Common Attribute Design Mistakes

Experienced developers recognize these anti-patterns. Avoiding them leads to cleaner, more maintainable classes.

Anti-Patterns to Avoid

•God Objects — Classes with dozens of attributes covering unrelated concerns. Split into focused classes.
•Redundant Attributes — Storing values that can be derived from other attributes without performance justification.
•Stringly-Typed Data — Using String for everything: status, type, category, id. Use enums and value objects.
•Flag Explosion — Multiple boolean flags that control behavior: isActive, isDeleted, isArchived, isPending. Consider a state enum.
•Implicit Coupling — Attributes that only make sense together but aren't grouped: startDate/endDate, streetAddress/city/zip.
•Kitchen Sink Classes — Adding 'just one more attribute' repeatedly until the class is bloated. Refactor proactively.
•Nullable Everything — No distinction between required and optional. Be explicit about nullability.

RefactoringExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// BEFORE: Flag explosion, implicit coupling, stringly-typed
public class User {
    private String status;  // "active", "inactive", "suspended", "deleted"
    private boolean isVerified;
    private boolean hasCompletedOnboarding;
    private boolean is2FAEnabled;
    private String addressLine1;
    private String addressLine2;
    private String city;
    private String state;
    private String zipCode;
    private String country;
}
 
// AFTER: Enums, grouped attributes, clear structure
public class User {
    private UserStatus status;  // Enum: ACTIVE, INACTIVE, SUSPENDED, DELETED
    private UserFlags flags;    // Value object: verified, onboarded, 2fa
    private Address address;    // Value object: encapsulates address fields
}
 
public enum UserStatus {
    ACTIVE, INACTIVE, SUSPENDED, DELETED
}
 
public class UserFlags {
    private final boolean isVerified;
    private final boolean hasCompletedOnboarding;
    private final boolean is2FAEnabled;
    
    // Meaningful methods
    public boolean isFullyOnboarded() {
        return isVerified && hasCompletedOnboarding;
    }
}

Summary: Designing Meaningful Attributes

We've explored the principles and practices of attribute design. Let's consolidate:

Key Takeaways

•Context determines attributes — The same domain entity needs different attributes in different systems.
•Choose appropriate granularity — Single attribute, multiple attributes, or separate class—let the operations guide you.
•Use rich types over primitives — Value objects that validate on creation prevent invalid states.
•Handle optionality explicitly — Use Optional, annotations, or defaults. Never null for collections.
•Name with intention — Clear, specific, consistent names using domain language.
•Prefer derived over stored — Compute values to avoid synchronization; cache only when proven necessary.
•Avoid common anti-patterns — No god objects, flag explosions, or stringly-typed data.

What's Next:

Page Complete

3 / 4