Is it necessary or "class obsession" (opposite to primitive obsession) to create classes for non-business fields?

Question

I know there are some posts talk about primitive obsession : When is primitive obsession not a code smell?, Is "avoid the yo-yo problem" a valid reason to allow the "primitive obsession"?, but the posts mostly talk about business data fields like "ZipCode" and "Address" (I can't define what "business object" is accurately, but I think it may mean the data source comes from database, user input or something need validation...), how about some non business data fields? For example:

public class MyActivity extends Activity{
    private static boolean isFirstShown=false; //show welcome dialog when user enters this page first time

    private static int lastSelectedItemIndex; //reload last selection

    private int clickCount; //eg: show some Easter egg animations after some click
    .
    .
    .
    onResume(){
        if(!MyActivity.isFirstShown){
            //display welcome dialog
        }
        MyActivity.isFirstShown=true;
    }
}

The data field above is not from database, do I need to create a type for them? I prefer to use primitive type for them because:

1. If there are many these fields, it may have many little classes and hence harder to find required file to edit in file menu

2. It may decrease the readability of the code, for example, I need to change something like:

if(!MyActivity.isFirstShown){ 
    //display welcome dialog 
}

to

if(!MyActivity.isFirstShownObject.getValue()){
    //display welcome dialog
}

which has more characters and looks less natural to understand

3. Sometimes I rely on "whether it is primitive" to distinguish if it is a business object quickly, eg: if I see "int lastSelectedItemIndex", I can know it is not a field from database

4. I believe the scope of those fields are small, and the values are not from direct user input, I can handle it carefully so that the chance of having invalid values (eg:negative click counts) are small, less classes to yoyo can help everyone understand the program more easily, which the benefit outweighs the risk of having invalid values and interchanging fields (eg:lastSelectedItemIndex=click count).

Do I need to create types for those fields? It it necessary or "class obsession" (opposite to primitive obsession)?

Answer 1

If you want to put the dialog showing logic in another class then do it like you mean it.

public class MyActivity extends Activity{
    onResume(){
        welcome.considerShowingDialog();
    }
}

Now MyActivity.onResume doesn't have wade through every welcome dialog detail. It can stay at a higher level and focus on other stuff.

Answer 2

I believe there's no relation between something being represented by a primitive and it being or not being a field from database. Is it possible that's just a convention you chose to use? Following such a convention convention could lead to over-enginering and/or inaccurate assumptions. So it could be said that this is "class obsession" but it may also be considered other things.

In the example you gave there is no need to make an object out of isFirstShown, unless you want to wrap in inside an Optional<T> for better null management and functional programming (this is a Java example that may not apply to the language you're using).

Answer 3

It depends.

In your example, given the peculiarities of the Android SDK and activity lifecycle, it certainly is the easiest and least annoying solution. However, in some cases, the variable "isFirstShown" may also come with some related state like "customWelcomeMessage" or some other stuff. In which case you should probably wrap those 2 in a "WelcomeDialogState" class.

It may also be annoying to have a lot of unrelated private fields in a class to describe its state (it pollutes auto completion), at which point you may want to wrap all those unrelated fields in a class describing the state, but this is a matter of preference.

So it depends on stuff like: how the platform works, if any of the fields are interconnected in some way, your personal preference, coding styles etc.