Consider designing a single class. Tipically, this is not a good idea. Concepts do not exist in isolation; rather, a concept is defined in the context of other concepts. Similarly, a class does not exist in isoolation but is defined together with logically related classes. Typically, on e works on a set of related classes. Such a set is often called a class library or a component. Sometimes all the classes in a component constitue a single class hierarchy, sometimes they are members of a single namespace, and sometimes they are a more ad-hoc collection of declarations.
The set of classes in a component is united by some logical criteria, often by a common style and often by a reliance on common services. A component is thus the unit of design, documentation, ownership, and often reuse. This does not mean that if you use one class from a component, you must understand and use all the classes from the component or maybe get the code for every class in the component loaded into your program. On the contrary, we typically strive to ensure that a class from a componentcan be used with only minimal overhead in machine resources and human effort.