For non-container classes, are "better naming" and "ready for commented codes" good reasons not to declare the most abstract type?

Question

According to Why define a Java object using interface (e.g. Map) rather than implementation (HashMap), I know I should declare the most abstract type possible, but the question is about template class or containers, how about the non container class? For example, suppose I'm using a UI framework, cocos2d-x, which Label and Sprite are extended from Node, and the code to create the screen of UI:

Sprite* titleSprite=Sprite::create("welcome.png");
this->addChild(titleSprite);
titleSprite->setPosition(300,100);

Label* titleLabel=Label::create("Welcome,"+userInfo.name,"customFontType",32);
this->addChild(titleLabel);
//titleLabel->setFontColor(Color.RED);
titleLabel->setPosition(360,100);

It is not declaring most abstract type, so modified as follows:

Node* title1Node=Sprite::create("welcome.png");
this->addChild(title1Node);
title1Node->setPosition(300,100);

Node* title2Node=Label::create("Welcome,"+userInfo.name,"customFontType",32);
this->addChild(title2Node);
//title2Node->setFontColor(Color.RED);
title2Node->setPosition(360,100);

However, I found some disadvantages after declaring most abstract type:

1. It becomes harder to find a specific label from the variable name, eg: if I want to change a specific label, I may try to search for suffix of variables first, declaring most abstract type erases the extra information about the variables from suffix. Note: I don't want to declare with Node but name with suffix Sprite,eg:

Node* titleSprite=Sprite::create("welcome.png");

because I think it is misleading to have a variable name suffix different from the type actually.

2. There may some test code, which depends on the child type, eg:

//titleLabel->setFontColor(Color.RED);

which is necessary for testing (eg: let a new teammate to see the actual Label in the screen easily), but not required in production. Declaring with most abstract type voids the comment code, and becomes less convenient to run the test code.

3. If there are many UI components with same suffix, it may increase the chance of typing the desired UI variable name incorrectly, eg:

non most abstract type:

Sprite* brickSprite=...
Label* blockLabel=...
//brickLabel->setVisible(false);
//wrongly typing "brickLabel" would not compile because brickLabel does not exist

most abstract type:

Node* brickNode=...
Node* blockNode=...
//brickNode->setVisible(false);
//wrongly typing "brickNode" would compile...

4. I may accidentally using the wrong UI because of less strict typing, similar to problem of "primitive obsession", eg: I want to show fade in effect on Sprite but not Label (Which the fade in function is on parent class Node):

non most abstract type version:

class MyUIPageNode : Node{
    private:
        Sprite* sprite=NULL;
        Label* label=NULL;

    virtual void init(){
        .
        .
        .
        //interchanges 2 UI accidentally
        this->sprite=titleLabel;
        this->label=titleSprite;
        this->sprite->runAction(FadeIn::create(0.5));
        //not compile because titleLabel is not Sprite
    }
}

most abstract type version:

class MyUIPageNode : Node{
    private:
        Node* sprite=NULL;
        Node* label=NULL;

    virtual void init(){
        .
        .
        .
        //interchanges 2 UI accidentally
        this->sprite=titleLabel;
        this->label=titleSprite;
        this->sprite->runAction(FadeIn::create(0.5));
        //can compile, and fadeIn the Label actually instead of Sprite
    }
}

I think the code (especially for UI framework) declaring the exact type is more readable , more natural and less error prone. So my question is, are the problems above reasons to not declaring most abstract type?

Answer 1

Type strategy has nothing to do with what kind of class you're dealing with, it applies to Containers in the same way as to non-containers. If all you do is drive(), then you should deal with a Car rather than an ICECar, so that it can be more easily substituted with an ElectricCar later. This is no different from declaring a List rather than a LinkedList so that you can replace it with a better TurboList later.

However, if you do need type-specific information, e.g. you're building a car charger network, then you must declare ElectricCar (but still not Zoe or Tesla!), because Car is not, in fact, the most abstract type possible. That seems to be the case in your example.

Answer 2

Your problems boil down to two things:

1. The "most abstract type" depends on what you do with the object
2. Variable names should tell you what the reader needs to know, not what the compiler needs to know

Point 1 is the simplest: if you have code that needs to run a Label-specific operation on an object, then Label is the most abstract type. You have to choose the most abstract that is useful in your context, otherwise everything could just be declared as Object.

Point 2 is a bit more subtle: you (or your team) have decided on a naming convention that includes type information as a mnemonic for the reader. Your convention is equivalent to "Hungarian notation", and specifically what is known as "Systems Hungarian notation"

However, the same convention can be used with a different piece of information, equivalent to "Apps Hungarian notation". In that convention, the naming is based on the semantic type of the variable, not the system type.

For instance, the UI framework might have unrelated types for ImageNode and TextNode, either of which could be used for labelling something, so you would call the variable itemLabel, even though there is no type in the library called Label. This is not "misleading", as long as you have a specific convention of which "types" you are going to use in this way.