This article provides an overview of the elements of C++; specifically, the 'C' portion of C++.
Note how section 2.2 describes tokens as the "minimal chunks of a program". The root goal of programming is solving problems using the 'chunks' of a programming language. Of course, the chunks must be appropriate for the type of problems to be solved. Generally, smaller chunks are applicable to many types of tasks, but involve more effort; larger chunks involve less effort, but are designed for more specific tasks.
Strategies for transition
If you buy into OOP, your next question is probably, "How can I get my manager/colleagues/department/peers to start using objects?" Think about how you – one independent programmer – would go about learning to use a new language and a new programming paradigm. You've done it before. First comes education and examples; then comes a trial project to give you a feel for the basics without doing anything too confusing. Then comes a "real world" project that actually does something useful. Throughout your first projects you continue your education by reading, asking questions of experts, and trading hints with friends. This is the approach many experienced programmers suggest for the switch from C to C++. Switching an entire company will of course introduce certain group dynamics, but it will help at each step to remember how one person would do it.
Guidelines
Here are some guidelines to consider when making the transition to OOP and C++:
1. Training
The
first step is some form of education. Remember the company's investment
in plain C code, and try not to throw everything into disarray for six
to nine months while everyone puzzles over how multiple inheritance
works. Pick a small group for indoctrination, preferably one composed of
people who are curious, work well together, and can function as their
own support network while they're learning C++.
An
alternative approach that is sometimes suggested is the education of
all company levels at once, including overview courses for strategic
managers as well as design and programming courses for project builders.
This is especially good for smaller companies making fundamental shifts
in the way they do things, or at the division level of larger
companies. Because the cost is higher, however, some may choose to start
with project-level training, do a pilot project (possibly with an
outside mentor), and let the project team become the teachers for the
rest of the company.
2. Low-risk project
Try
a low-risk project first and allow for mistakes. Once you've gained
some experience, you can either seed other projects from members of this
first team or use the team members as an OOP technical support staff.
This first project may not work right the first time, so it should not
be mission-critical for the company. It should be simple,
self-contained, and instructive; this means that it should involve
creating classes that will be meaningful to the other programmers in the
company when they get their turn to learn C++.
3. Model from success
Seek
out examples of good object-oriented design before starting from
scratch. There's a good probability that someone has solved your problem
already, and if they haven't solved it exactly you can probably apply
what you've learned about abstraction to modify an existing design to
fit your needs. This is the general concept of design patterns, covered in Volume 2.
4. Use existing class libraries
The
primary economic motivation for switching to OOP is the easy use of
existing code in the form of class libraries (in particular, the
Standard C++ libraries, which are covered in depth in Volume two of this
book). The shortest application development cycle will result when you
don't have to write anything but main( ), creating and using
objects from off-the-shelf libraries. However, some new programmers
don't understand this, are unaware of existing class libraries, or,
through fascination with the language, desire to write classes that may
already exist. Your success with OOP and C++ will be optimized if you
make an effort to seek out and reuse other people's code early in the
transition process.
5. Don't rewrite existing code in C++
Although compiling your C code with a C++ compiler usually produces (sometimes tremendous) benefits by finding problems in the old code, it is not usually the best use of your time to take existing, functional code and rewrite it in C++. (If you must turn it into objects, you can "wrap" the C code in C++ classes). There are incremental benefits, especially if the code is slated for reuse. But chances are you aren't going to see the dramatic increases in productivity that you hope for in your first few projects unless that project is a new one. C++ and OOP shine best when taking a project from concept to reality.