The survival kit has been great so far. We identified its class and also defined a builder to help us create new kits the fun way.
That was until @kyle decided that there can be one without a TShirt. So how would you go on about it?
There is the option to create a new SurvivalKit class without the TShirt. But in doing so you have to also think of all the relationships that it has. Like SurvivalKitOrder or the ForrstController. Will you create extra classes for those relationships as well? Your code isn't that DRY anymore.
You could use a base survival kit which includes everything but a TShirt and have your SurvivalKit extend that, adding a TShirt. You are abusing inheritance now.
You can simply use your existing SurvivalKit class and just use a null value anytime you don't want a TShirt. By doing so though you will end up having to check every time you access the TShirt if it's null or not. What's worse is if you have to make a decision based on that when you really shouldn't.
How will you handle a future SurvivalKit that may have less or even more items (Hint) that go with it? You start to notice that this doesn't scale well.
The real question you have to ask yourself is, "How much different are those SurvivalKit(s)?". Talking about different survival kit's is more directly related to different implementations rather on the properties that make it up.
If you rethink of what defines a SurvivalKit you will come to realise that it's merely the items that is has. So you could say that the TShirt, the Mug, the Wristband and the Sticker are all SurvivalKitItem(s).
From the description of the kit we can't really tell anything about a SurvivalKitItem yet we can simply define a marker interface that designates all the items that can be added to the kit.
All you have to do is have each implement the SurvivalKitItem interface.
You can see that the SurvivalKit#build no longer returns a new kit. So where do we specify the custom kit that we want?