Problem
I'll simplify my problem to be understood better. Let's say that we want to model and implement app which displays user's favourite number series. For example:
1 2 3 4 5
All series have one thing in common - bestIndex. If it's equal 2 then it means that in above example user choosed number 3 (index enumerated from 0) as his best number.
Most of the series have two things in common - numbersCount and multiplier. In above example numbersCount was 5 and multiplier was 1. However there is one special series which is completely defined by user, thus it doesn't have numbersCount and multiplier.
Some examples to make it clear. This is "increasing series" with numbersCount 3 and multiplier 2:
2 4 6
This is "constant series" with numbersCount 4 and multiplier 3:
3 3 3 3
This is "plus one series" with numberCount 3 and multiplier 1:
2 3 4
And finally this is "user defined series":
2 5 1 7 3
Since user will type it by hand we don't want to set numberCount for that and multiplier doesn't have sense too.
From UI perspective I would create RadioGroup for choosing series type (increasing, constant, plus1, userDefined) and edit fields / spinners for setting bestIndex, numberCount and multiplier (last two would be unavailable when userDefined RadioButton is toggled). That's pretty obvious but I'm wondering how this should be modelled, taking into consideration that in future we may want to add more standard series.
Potential solutions
One way I see it would be to create SeriesModel class which would have:
- enum type for specifying which series it is
- bestIndex
- numberCount (equals 0 for user defined series)
- multiplier (equals 0 for user defined series)
- List of user defined numbers (null if standard series are choosed)
However everywhere in functions like getNumberAtIndex or toString we would have to have checks for type and different implementation for each series type. Please bare in mind that in future new series may be added, so such class could quickly grow and even toString would be hard to analyze. Besides this class has some logic like getNumberAtIndex, so should it still be treated as a Model?
Anyway it has an advantage because such code in View would work fine:
<EditText android:id="@+id/multiplier"
android:text="@{viewModel.seriesModel.multiplier}" />
Second way I was thinking of is to create Series abstract class with functions like getNumberAtIndex and bestIndex field. Which would then be implemented by abstract StandardSeries class (numberCount + multiplier) and concrete UserDefinedSeries (List of user defined numbers). Further StandardSeries would be extended by concrete IncreasingSeries, ConstantSeries and Plus1Series classes. However in this case I still have logic in Model, what's more now I also have abstract classes there. Now when I write ViewModel and use abstract Series class I would still have to cast this object to at least StandardSeries and UserDefinedSeries which I guess would be hard do bind and maintain. Besides since abstract Series is not aware of e.g. multiplier I couldn't write such code:
<EditText android:id="@+id/multiplier"
android:text="@{viewModel.series.multiplier}" />
On the other hand I could create all concrete classes in ViewModel, set them to null and when e.g. Plus1Series RadioButton is toggled I would create this object in ViewModel class but still I wouldn't be able to write code like this:
<EditText android:id="@+id/multiplier"
android:text="@{viewModel.plus1Series.multiplier}" />
because at the moment of writing View I don't know if plus1Series exists or increasingSeries or something else.
Question
Do you see a better way of handling such case?
Aucun commentaire:
Enregistrer un commentaire