In object-oriented programming, a BaseBean is a utility object from which concrete entities are derived (via subclassing). Proper design suggests that the inherited functionality should be provided via delegation instead. The BaseBean is an example of an anti-pattern (where the "Bean" part of the name comes from the standard Java naming convention for a generic entity object, or JavaBean).
Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class. For example, an order is not a vector, although an order may contain a vector of line items.
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass, as the inheriting class may behave improperly when used as a replacement of the parent class, thus violating the Liskov substitution principle. Instead, delegation (has-a relationship) could be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance. In some cases a static utility class can be created to contain necessary functionality. Object-oriented programming emphasizes that objects should be meaningful and should communicate with each other in the way that resembles the real-world entities they are emulating. A "BaseBean" is not a real-world object, nor is it descriptive. Likely, it needs to be refactored as a more meaningful class and referenced rather than extended.
This pattern is somewhat related to the CallSuper anti-pattern, in which a derived class has the requirement to call into the parent class to complete its work.