Heres' the design of the new UNC Admissions Calculator, which uses the Decorator Design Pattern:

I changed things around from the original specification. An application consists of several public fields. If a field such as GRE is null, that means the applicant didn't take the GRE (and therefore better not be applying to graduate school since this will be regarded as the same as not passing the GRE.) One field is the boolean accepted field, which is initially true. The goal of each decorator is to try to set this field to false.
The new version of the UNC Admissions Calculator delegates to some object masquerading as an IEvaluator:
I had to use the Adapter Pattern to adapt the legacy GPAEvaluator to the IEvaluator interface:
The purpose of the EvaluatorDecorator, the base class of all decorators, is to maintain a piointer called delegate to the next object in the decorator chain.
The goal of each decorator is to try to set this field to false:
The test code is in:
Note how decorator chains are created. In theory, we would create a decorator chain for each type of application.
Here's the output it produces:
accepted = false
accepted = true
accepted = false