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 try 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 6 to 9
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 Chapter XX.
4.
Use existing class libraries
The
primary economic motivation for switching to C++ is the easy use of existing
code in the form of class libraries (in particular, the Standard C++ libraries,
which are covered later in this book). The shortest application development
cycle will result when you don’t have to write anything but
main( ).
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 in C++ usually produces (sometimes great) 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.
Management
obstacles
If
you’re a manager, your job is to acquire resources for your team, to
overcome barriers to your team’s success, and in general to try to
provide the most productive and enjoyable environment so your team is most
likely to perform those miracles that are always being asked of you. Moving to
C++ falls in all three of these categories, and it would be wonderful if it
didn’t cost you anything as well. Although moving to C++ may be cheaper
– depending on your constraints
[13]
– than the OOP alternatives for team of C programmers (and probably for
programmers in other procedural languages), it isn’t free, and there are
obstacles you should be aware of before trying to sell the move to C++ within
your company and embarking on the move itself.
Startup
costs
The
cost of moving to C++ is more than just the acquisition of C++ compilers (the
GNU C++ compiler, one of the very best, is free). Your medium- and long-term
costs will be minimized if you invest in training (and possibly mentoring for
your first project) and also if you identify and purchase class libraries that
solve your problem rather than trying to build those libraries yourself. These
are hard-money costs that must be factored into a realistic proposal. In
addition, there are the hidden costs in loss of productivity while learning a
new language and possibly a new programming environment. Training and mentoring
can certainly minimize these but team members must overcome their own struggles
to understand the issues. During this process they will make more mistakes
(this is a feature, because acknowledged mistakes are the fastest path to
learning) and be less productive. Even then, with some types of programming
problems, the right classes, and the right development environment, it’s
possible to be more productive while you’re learning C++ (even
considering that you’re making more mistakes and writing fewer lines of
code per day) than if you’d stayed with C.
Performance
issues
A
common question is, “Doesn’t OOP automatically make my programs a
lot bigger and slower?” The answer is, “It depends.” Most
traditional OOP languages were designed with experimentation and rapid
prototyping in mind rather than lean-and-mean operation. Thus, they virtually
guaranteed a significant increase in size and decrease in speed. C++, however,
is designed with production programming in mind. When your focus is on rapid
prototyping, you can throw together components as fast as possible while
ignoring efficiency issues. If you’re using any third-party libraries,
these are usually already optimized by their vendors; in any case it’s
not an issue while you’re in rapid-development mode. When you have a
system you like, if it’s small and fast enough, then you’re done.
If not, you begin tuning with a profiling tool, looking first for speedups that
can be done with simple applications of built-in C++ features. If that
doesn’t help, you look for modifications that can be made in the
underlying implementation so no code that uses a particular class needs to be
changed. Only if nothing else solves the problem do you need to change the
design. The fact that performance is so critical in that portion of the design
is an indicator that it must be part of the primary design criteria. You have
the benefit of finding this out early through rapid prototyping.
As
mentioned earlier, the number that is most often given for the difference in
size and speed between C and C++ is ±10%, and often much closer to par.
You may actually get a significant improvement in size and speed when using C++
rather than C because the design you make for C++ could be quite different from
the one you’d make for C.
The
evidence for size and speed comparisons between C and C++ tends to be anecdotal
and is likely to remain so. Regardless of the number of people who suggest that
a company try the same project using C and C++, no company is likely to waste
money that way unless it’s very big and interested in such research
projects. Even then, it seems like the money could be better spent. Almost
universally, programmers who have moved from C (or some other procedural
language) to C++ have had the personal experience of a great acceleration in
their programming productivity, and that’s the most compelling argument
you can find.
Common
design errors
When
starting your team into OOP and C++, programmers will typically go through a
series of common design errors. This often happens because of too little
feedback from experts during the design and implementation of early projects,
because no experts have been developed within the company. It’s easy to
feel that you understand OOP too early in the cycle and go off on a bad
tangent; something that’s obvious to someone experienced with the
language may be a subject of great internal debate for a novice. Much of this
trauma can be skipped by using an outside expert for training and mentoring.
On
the other hand, the fact that it is easy to make these design errors points to
C++’s main drawback: its backwards-compatibility with C (of course,
that’s also its main strength). To accomplish the feat of being able to
compile C code, the language had to make some compromises which have resulted
in a number of “dark corners.” These are a reality, and comprise
much of the learning curve for the language. In this book (and in others; see
the “Recommended Reading” appendix) I try to reveal most of the
pitfalls you are likely to encounter when working with C++, but you should
always be aware that there are some holes in the safety net.
[13]
Because of its productivity improvements, the Java language should also be
considered here.