Is it meaningful to have abstract classes just for purpose of layering structure?

Assume a Java class (e.g. a helper class), which has a great bundle of methods that might be able to be separated into different "layers". By "layers", I mean a design of clearer responsibilities of each class and a reduction of complexity. Is it meaningful in this case, by using abstract class, to achieve the goal, in the sense of clean code and software design?

I encounted the situation in project that there is a helper class having too much complexity and simply too many rows. The class is somehow playing vital roles, acting as a kind of type helper assiting other objects to fetch and manipulate type information. Each time a new/existing type would need extra type info, this class come into help, therefore becomes heavier and more complicated in implementing methods. Though I can surely categorize and separate those methods into many classes. I found there be a structural corelation of those methods. Please see the code example below:

Assume a Type can have some TypeProperty:s. Assume also in code that there is a Type class and a TypeProperty class, both with essential getters and setters, meanwhile a Helper class Helper.

public class Helper{

    static final T CONSTANT_A = new A(...);
    static final T CONSTANT_B = new B(...);

    final Type theType;

   //constructor etc.

    Type getType(){
        return theType;
    }

    Type getTypeByKey(Key typeKey){
        //...
    }

    Collection<TypeProperty> getPropertiesByType(Type t){
        //...
    }

    Collection<TypeProperty> getProperties(){
       return theType.getProperties();
    }

    TypeProperty findSpecificPropertyInTypeByKey(Key propertyKey){
        Set<TypeProperty> properties= theType.getProperties();
        //loop through the properties and get the property,  
        //else return null or cast exception if not found
    }

    boolean isTypeChangeable(){
        return findSpecificPropertyInTypeByKey().isChangeable();
    }

    //many more methods
}

I expect to refactor the Helper class so that the code is easier to maintain and expand, as well as, to be of less complexity. I think it is possible to separate the methods into different classes, however this might lead to too many classes and the responsibilities are not straight-forward as they are not in helper class(es). While at the meantime, the idea of utilizing abstract classes comes into my mind. Would it be meaningful then? Say that after refactoring, there would be

• a TopLevelHelper having methods revolving the type itself, e.g. isTypeChangeable & getType(), as well as, all Constants;

• a SecondLevelHelper extending TopLevelHelper, which bears the logics as middleware, e.g. getProperties and getPropertiesByType;

• a LastLevelHelper extending SecondLevelHelper, which does the concrete and detailed works, e.g. findSpecificPropertyInTypeByKey.

Though, none of these classes would have abstract methods but concrete implementations since none of the methods in higher level helpers would be overriden. It does not seem that such design is a appropriate usage of abstract classes, still I feel it separates responsibilities into three layers. Is that meaningful to do so or should other techniques be used in this situation?