0

I often face this problem when new requirements come along, but have never seen it discussed anywhere. In this case, I have an existing list of items (staves in a musical score). The requirement is that a user can add and remove new items - but they are not allowed to remove the original items. So what do I name the new stored state?

An enum property with values Original and CreatedByUser reflects the original setter context, and is potentially useful in other actions like rename, copy, etc. I would usually also add a read-only isDeletable property that refers to the enum.

A bool isDeletable property reflects the new requirement, and potentially allows other contexts to set the value depending on yet more requirements.

Is one better than the other? Are there any links that describe or discuss this duality of state variables better?

  • A 3rd option would be to have a separate editable list of "userAddedItems". You avoid an extra property, but you will often have to iterate over both lists. Depends on your language and framework if this is a good option or not. – user949300 Jan 6 '18 at 5:23
  • Do you need the information "added by user" for any other purpose than to decide deletability? If not, this info is irrelevant to the future computation, and you should not name things after it. – Kilian Foth Jan 6 '18 at 8:35
  • 1
    Agree with Killian; more info is needed from other design requirements; what if a score may be edited by multiple users, with some logic around which users may delete which other users efforts (wikisymphony.com?) - then store the user who created a stave, with a special user or null for system read only staves, and the ability to work out of the current user can delete a particular stave? There's perhaps not enough info in your question to answer a "what is the best way.." for this context.. – Caius Jard Jan 6 '18 at 8:45
2

I would say that your dilemma is between Data and Logic.

Note.State is data, it wont change unless the note changes

Note.IsDeletable() is logic. It can change overtime as requirements change.

This is a good argument against Object Orientated programming because IsDeletable only has meaning in the context of the MusicEditor application.

If I have another application, (or part of a large application), say MusicPlayer , with the same notes the data of the note still makes sense, but the logic doesn't. Either notes are no longer deletable at all, or even worse they are deletable but have different requirements.

This leads you to having multiple versions of 'the same' object MusicEditor.Note, MusicPlayer.Note you can no longer talk about notes in a generic way.

The same is true to a lesser extent when requirements change over time.

The answer is to take an ADM approach and put your logic into services, keeping only the data on the object.

Note.State
MusicEditor.IsDeletable(Note note)

I can now have a separate MusicPlayer service with completely different logic and methods but which still works with the same note data objects.

Similarly I can have different versions of the MusicEditor service over time

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.