Why we need to create a class?
In the dawn of computing, programmers thought about programming in terms of statements. Throughout the 1970s and 1980s, programmers began thinking about programs in terms of routines. In the twenty-first century, programmers think about programming in terms of classes.
When working with the OOP languages, you will often see the term ‘class’, so what is the class?
I. What is a class?
A class is a collection of data and routines that share a cohesive, well-defined responsibility. It might also be a collection of routines that provides a cohesive set of services even if no common data is involved.
II. Why we need it?
A key to being an effective programmer is maximizing the portion of a program that you can safely ignore while working on anyone section of code. Classes are the primary tool for accomplishing that objective.
III. Reasons to create a class
Most people will get the idea that only reason to create a class is to model real-world objects.
But in practice, classes get created for many more reasons than that. Here is a list of good reason to create a class:
- Model real-world objects:
Modeling real-world objects might not be the only reason to create a class, but it’s still a good reason! Create a class for each real-world object type that your program models. Put the data needed for the object into the class, and then build service routines that model the behavior of the object.
Example: class Person with some attribute datas like eyes, nose, hands,…
- Model abstract objects:
Another good reason to create a class is to model an abstract object – an object that isn’t a concrete, real-world object but that provides an abstraction of other concrete objects.
Example: object Shape is an abstraction of specific shapes.
- Reduce complexity:
The single most important reason to create a class is to reduce a program’s complexity. Create a class to hide information so that you won’t need to think about it.
Sure, you’ll need to think about it when you write the class. But after it’s written, you should be able to forget the details and use the class without any knowledge of its internal workings.
Example: In Laravel, you will see something like this
- Isolate complexity:
Complexity in all forms – complicated algorithms, large data sets,… is prone to errors. If an error does occur, it will be easier to find if it isn’t spread through the code but is localized within a class.
Changes arising from fixing the error won’t affect other code because only one class will have to be fixed – other code won’t be touched.
If you find a better, simpler or more reliable algorithm, it will be easier to replace the old one if it has been isolated into a class.
During Development, it will be easier to try several designs and keep the code that works best.
- Limit effects of changes:
Isolate areas that are likely to change so that the effects of changes are limited to the scope of a single class or a few classes. Design so that areas that are most likely to change are the easiest to change.
- Hide global data:
If you need to use global data, you can hide its implementation details behind a class interface.
Working with global data through access routines provides several benefits compared to working with global data directly.
You can change the structure of the data without changing your program. You can monitor accesses to the data.
The discipline of using access routines also encourages you to think about whether the data is really global; it often becomes apparent that the “global data” is really just a data object.
- Streamline parameter passing:
If you are passing a parameter among several routines, that might indicate a need to factor those routines into a class that shares parameter as object data.
Streamlining parameters passing isn’t a goal, but passing lots of data around suggest that a different class organization might work better.
- Facilitate reusable code:
Code put into well-factored classes can be reused in other programs more easily than the code embedded in one large class.
Even if a section of code is called from only one place in the program and is understandable as part of a large class, it makes sense to put it into its own class if that piece of code might be used in another program.
- Plan for a family of programs:
If you expect a program to be modified, it’s a good idea to isolate the parts that you expect to change by putting them into their own classes.
You can then modify the classes without affecting the rest of the program, or you can put in completely new classes instead.
IV. When we need to avoid creating a class
While classes in general are good, you can run into a few gotchas. Here are some classes to avoid:
- Avoid creating god classes:
Avoid creating classes that are all-knowing and all-powerful. If a class spends its time retrieving data from other classes use Get() and Set() routines (that is, digging into their business and telling them what to do), ask whether that functionality might better be organized into those other classes rather than into the god class.
- Eliminate irrelevant classes:
If a class consists only of data but no behavior, ask yourself whether it’s really a class and consider demoting it so that its member data just becomes attributes of one or more other classes.
- Avoid classes named after verbs:
A class that has only behavior but no data is generally not really a class.
Example: Consider turning a class like DatabaseInitialization() or StringBuilder() into a routine on some other class.
Reason to create a class:
- Model real-world objects
- Model abstract objects
- Reduce complexity
- Isolate complexity
- Limit effects of changes
- Hide global data
- Streamline parameter passing
- Facilitate reusable code
- Plan for a family of programs
When we need to avoid creating a class:
- Avoid creating god classes
- Eliminate irrelevant classes
- Avoid classes named after verbs
Reference: Code Complete 2.