This leads to problems.
If you need both the old class and the new, you now have two similar source files.
If you have the source code for a class, you could copy the code and change it to do what you wanted. Before object oriented programming that was what was done. But there are at least two problems with this:
(i) It is hard to stay organized. Say that you already have several dozen classes which you need to keep and that you need additional classes based on the original ones. Also, say that you need several classes based on the new classes. You will end up with dozens of source files which are all versions of other source files that have been changed in various ways. Now say that a bug has been found in one of the source files. Some source files based on it need fixing; others, perhaps not. Without careful planning you will end up with an disorganized, inconsistent, buggy mess. (I speak from experience, here.)
(ii) You need to study the original code. Say that you have a complicated class that basically does what you want, but you need a small modification. If you edit the source code, even to make a small change, you risk breaking something. So you must study the original code to be sure that your changes are correct. This may not be easy.
The automatic inheritance mechanism of Java greatly relieves both of these problems.
In diagrams that show inheritance, an arrow points from the new class to the class it is based upon. The arrow is sometimes labeled "is a".
In these notes, clouds represent classes and rectangles represent objects. This style of representing classes comes from the book Object-oriented Analysis and Design, by Grady Booch (Addison-Wesley, 1994). In official UML (Unified Modeling Language) both classes and objects are represented with rectangles.
Say that class B is based upon class A. Which one would you call the parent class? Which one would you call the child class?