How to relate summary to detail data objects?

Question

My application I have two types of customers: individuals and business customers. My users sometimes need to be able to see the full details of one customer, but at other times they only need to see a brief summary with a few fields (e.g. in a list of search results). I currently have three classes: IndividualCustomer, BusinessCustomer, and CustomerSummary. These are plain old Java objects (aka POJOs) with getters and setters as their only methods.

I am contemplating whether to combine them using inheritance or possession. For example, maybe there should be a Customer interface which they all implement. In that case, perhaps the interface requires the methods of CustomerSummary so I can do away with that type. Or perhaps there should be a Customer class with a few fields (like the current implementation of CustomerSummary and it should "have a" BusinessCustomer or IndividualCustomer for the details.

The things that concern me are: if I make a Customer interface and eliminate CustomerSummary, then the types IndividualCustomer/BusinessCustomer will sometimes be only partially populated with details, having lots of null fields, and it would be a disaster if one of those "summaries" ended up hitting a .save() method and overwriting real data with nulls. If I go with the possession approach where a Customer object has a business or individual customer as a private field, then I have to do frequent type checks or type casts in order to be able to use the two types interchangeably.

What's the best design pattern for this kind of case, where an object is sometimes only partially populated (i.e. a "summary"), but can be populated with two different subtypes of details?

Does this answer your question? [Choosing the right Design Pattern](https://softwareengineering.stackexchange.com/questions/227868/choosing-the-right-design-pattern) — gnat, May 28 '20 at 18:57

score 2 · Answer 1 · answered May 28 '20 at 19:43

2

Objects are not supposed to be bags of data, and your problem comes directly from the object not in control of its data. The object-oriented solution would be to add your specific behavior to your object. One version may look like this:

public interface Customer {
   UIComponent displayFull();

   UIComponent displaySummary();

   ...potentially other stuff...
}

Note: an implementation of Customer may not necessarily hold any data at any particular time, may retrieve data as necessary depending on what functionality is accessed.

This has obvious advantages, one is that you don't have to concern yourself with what "data" is in the object. A second one is that this interface survives data changes. A third one is that it's object-oriented. Fourth, you can optimize each case arbitrarily, to the point of being one sql statement if need be. Fifth, it can be paged or whatever, the interface doesn't care. There are probably more advantages...

One disadvantage is that nobody does it this way. If I convinced you to do it using object-orientation you're on your own. :) You've been warned.

answered May 28 '20 at 19:43

Robert Bräutigam

11,473
1
17
36

"Customer" doesn't seem like a good name for this interface. I would have called it something like "DisplayBehavior" and declared the Customer class as `public class Customer implements DisplayBehavior`. – Robert Harvey May 28 '20 at 19:56
One of the reasons that nobody uses full object-orientation, at least in business programs, is that they don't lend themselves to full object-orientation. Most modern business applications use table-centric data stores using fourth normal form. To get any meaningful behavior from the corresponding objects, it's usually necessary to aggregate them. – Robert Harvey May 28 '20 at 20:02
An invoice is an aggregation of Customer, Address and Product objects. You can calculate a total on an invoice, and aggregate invoices and payments in a collection to reconcile an account. About all you can do with a Customer record is look up their name; in a fully-normalized database, even the Contact information is a separate abstraction. It's interesting that you chose a UI operation as an example; UI frameworks are one of the few good use cases for deeply-nested inheritance hierarchies. – Robert Harvey May 28 '20 at 20:03
I think "data holders" is a distinct category from "logic capsules", but unfortunately in Java we have to use the same construct, an object, for both. Java has a new construct called "records" coming out on the horizon, meant for simple data holders, but for now I still have to use objects to hold data like this. – workerjoe May 28 '20 at 20:06
The enhancements described in [JEP 359](https://openjdk.java.net/jeps/359) seem perfectly reasonable to me. – Robert Harvey May 28 '20 at 20:10
@RobertHarvey [Java Records are basically a way of legalizing bad designs](https://javadevguy.wordpress.com/2019/09/20/java-records-making-bad-designs-more-convenient/), they are not reasonable to me. Java is basically saying: people program procedurally, so let's just give them structs. Fair enough, but let's be honest about it. – Robert Bräutigam May 28 '20 at 21:18
@RobertHarvey We had this discussion I think :) Few people use object-orientation for the same reason few people (relatively) use functional programming. It's hard and you have to learn it, practice it, and it'll still be difficult. And for OO there are very few good reasources, but many-many bad ones. It's simple as that. It has nothing to do with databases or tables. – Robert Bräutigam May 28 '20 at 21:23
While there is merit to the "objects are not supposed to be bags of data" argument, I'm struggling to think of how you're going to tackle a data report without something to represent the rows of data. The assumption that your data class somehow renders the UI itself is massively conflating two very different responsibilities, and doesn't always apply (since your business layer may be consumed by several different frontends/apis). – Flater May 28 '20 at 22:24
@Flater "The assumption that your data class somehow renders the UI itself is massively conflating two very different responsibilities". 1. There is no data class, objects are living things, not bags of data. 2. It doesn't render the UI itself, it uses other UI-related collaborators to do that. 3. Different responsibilities according to whom? How do you measure that? Is `subtract()` a different responsibility than `add()`? – Robert Bräutigam May 29 '20 at 07:56
@RobertHarvey I'm looking forward to "records" but they won't be in a long-term support version of java until September 2021 so they're off limits for my enterprise system for now. – workerjoe May 29 '20 at 13:20

score 2 · Answer 2 · answered May 28 '20 at 22:13

First thoughts

Inheritance is meant for generalisation and specialisation. But a CustomerSummary is not some kind of Customer, nor is a Customer some kind of a CustomerSummary. So forget using inheritance here.

Composition would be a better choice: both an IndividualCustomer and BusinessCustomer have a CustomerSummary that can be used for similar purposes. But that's not the end of the story.

OO design vs DB design

If you have a hammer in your hand, every problem looks like a nail.

Similarly, if you have tables and columns in your mind, every class design will look like properties bundled in a POJO. And this might be misleading: redundant columns does not look very normal to an RDBMS expert ;-). And one mental trap leads to another: you'll quickly feel the need to partition theses columns between non-overlapping classes... OUCH! Wait a moment! Didn't we say object-oriented?

Accelerated OO design primer for data oriented developers

To avoid this mental trap, you need to abstract and embrace the law of demeter. The CustomerSummary is no longer a bundle of properties: it's a black box that can contain anything that summarizes a customer. For example a graphical picture such as a QR-Code or a DataMatrix, or a sound to be incorporated in your latest latest voice user interface ("Hey Siri, which customers shall I visit?").

As long as you do not decide anything about its properties, your mind will remain free. So focus on how a CustomerSummary could be used and how it would interact with the other classes. You'll end up with a nicely thought and robust interface.

Then you stay free: you can start with one implementation of the interface (the common fields), you may prefer to specialize the implementation (the legal form really makes sense for a business customer), or you may decide to have different summary implementation based on the kind of interface you're targeting. Dependency injection can even help you to make this dynamic.

At this moment in the thought process, you'd realize that it makes no sense to make the properties of the customer dependent of the content of the black box. This is how you'll get a BusinessCustomer and IndividualCustomer completely decoupled from a CustomerSummary If there is a dependency for populating the object, it would rather be Customer Summary that would be populated from a Customer object and not directly from the DB.

score 1 · Answer 3 · answered May 28 '20 at 22:22

Using SwiftUI, my implementation would look like the following:

protocol Customer {
  func showBriefSummary() -> AnyView
  func showFullSummary() -> AnyView
}

final class BusinessCustomer: Customer {
  func showBriefSummary() -> AnyView {
    // return view
  }

  func showFullSummary() -> AnyView {
    // return view
  }
}

let customer: Customer = BusinessCustomer()
customer.showBriefSummary()

score 0 · Answer 4 · answered May 29 '20 at 08:19

It is important to distinguish between data structures (which are simply a collection of data fields) and objects (which expose behavior without direct access to fields). They both have their uses and you should pick the right one for the job.

If you're building a simple CRUD application without any significant behavior, then all you need is data structures (three in your case) to transfer data between the database and the UI.

Most applications, though, will have some interesting behavior (such as validation and business rules). In this case, your business layer will be modeled using objects that encapsulate these business rules, and you will use data structures to transfer data to and from the UI. For example, a Customer might be an object (perhaps with two subtypes IndividualCustomer and BusinessCustomer having their own rules) but a CustomerSummary is simply a data structure used to present a subset of customer data on the UI. You could ask any Customer object to give you a CustomerSummary, or if you don't want to load all the customer data, you can directly query the database for the summary.

To close out with your question:

What's the best design pattern for this kind of case, where an object is sometimes only partially populated (i.e. a "summary"), but can be populated with two different subtypes of details?

An object (or the corresponding data in the database) is never partially populated, and the methods in your object should guarantee that. What you can have is a data structure that represents a partial view of an object.

How to relate summary to detail data objects?

4 Answers4

First thoughts

OO design vs DB design

Accelerated OO design primer for data oriented developers