OO设计-该设计有缺陷吗？

Question

I am creating a logic for web application to managing consents from user.

The model class that is persisted in the DB will have multiple fields, from which only a set will be changed with user request. E. g. class will have 10 fields with various consents, but user will be willing to change only 2 of those. To avoid writing a big chain of if-else's I designed this classes, to harness polymorphism to do the job for me, but somehow this design seems flawed to me. Could you tell me if this is proper way to do it?

PROBLEM: Change values of only subset of fields from large set of fields in class.

For sake of simplicity I removed getter/setters methods and some fields. Main logic for changing consents:

public class GdprServiceImpl implements GdprService {

private final ConsentRepository consentRepository;

@Autowired
public GdprServiceImpl(ConsentRepository consentRepository) {
    this.consentRepository = consentRepository;
}

@Override
public void changeConsent(User user, List<ConsentDto> consents) {
    Optional<Consent> optionalConsent = consentRepository.findByUser(user);
    if(optionalConsent.isPresent()) {
        Consent consent = optionalConsent.get();
        for(ConsentDto consentDto : consents) {
            consentDto.apply(consent);
        }
        consentRepository.save(consent);
    }
    else {
        Consent consent = new Consent();
        consent.setUser(user);
        for(ConsentDto consentDto : consents) {
            consentDto.apply(consent);
        }
        consentRepository.save(consent);
    }
}

Model class:

public class Consent {

    private Boolean messageConsent;
    private Boolean recordConsent;
    /*CONSTRUCTOR, OTHER METHODS AND FIELDS OMITTED*/
}

Classes that will change a set of fields from Consent class:

public abstract class ConsentDto {

    public abstract void apply(Consent consent);
}



public class RecordConsentDto extends ConsentDto {

   private boolean consentValue;

   public RecordConsentDto(boolean consentValue) {
        this.consentValue = consentValue;
    }

    @Override
    public void apply(Consent consent) {
        consent.setRecordConsent(consentValue);
    }
}



public class MessageConsentDto extends ConsentDto {

    private boolean consentValue;

    public MessageConsentDto(boolean consentValue) {
        this.consentValue = consentValue;
    }

    @Override
    public void apply(Consent consent) {
        consent.setMessageConsent(this.consentValue);
    }
}

Answer 1

You are right about the design having a "smell".
This is because the DB design is not normalized.
having a list of consents in one record is an indication. while technically it is allowed, classic RDBMS design dictatets that arrays should be represented as either one-to-many or many-to-many relation between tables. Of course, same in the object model.

a Fully normalized solution will have a consent_catalog table and many-to-many relation to users:

table consent_catalog {
  int id // PK
  String name
}

The catalog acts as "consent enum", having one row per type of consent (record, message, etc)

table user_consents {
  int user_id references users(id)
  int consent_id references consent_catalog(id)
}

This table has rows only for consents accepted by the user. no "false" consents. This design opens up new possibilities like knowing which users have a specific consent or mulitple consents in common.

Answer 2

This design feels like an overkill. At the end of the day you are always calling consent.setMessageConsent() or similar it's wrapped with an enum field and a class implementing ConsumerDto (which is really a Consumer ). Generally DTO are not supposed to implement business logic yet one could argue that apply method is one.

It really would be cleaner to have UserConsent POJO with Boolean fields. The exception would be if triggering one consent should trigger other but it's not clear from your example.

Just my two cents. I'd prefer to see either an anemic POJO passed around or DDD aggregate root for user that manages consents but not something in between.