The Master, The Expert, The Programmer
-
I find this article very good, sharing it
"http://zedshaw.com/essays/master_and_expert.html":http://zedshaw.com/essays/master_and_expert.html
-
Thanks for your post, this is interesting.I am a novice programmer
and pretty hate one of the situation mention by this postmaking sure EVERY SINGLE CLASS HAS AN INTERFACE, and ending every class with “Impl”
I don't understand why there are so many people like to use
inheritance even they don't really need it, they just try to make
their codes become harder to maintain and induce unnecessary
burden to the machine.The weirdest thing is, many people
know nothing but OO, OO is like "god" to them, start with OO,
end with OO, everything should be OO. You should inherit it
anyway else it is not a good OO design -
The key is knowing when to use each design pattern. Obviously, giving EVERY class an interface is an overkill, and using the PIMPL pattern in small apps is silly.
OO isn't just about inheritance, it is also about encapsulation and structuring your project to make it MUCH easier to maintain.
The PIMPL pattern is great for libraries (like Qt). Why? Imagine this scenario: You develop a large Qt app that is very popular. However, it is a bit slow, because there was inefficient code in Qt. One day, someone improves the inefficient code by massively changing the internal code structure. Your users would love the performance boost! Now, how do you get this improvement out to your users?
If Qt had not used the PIMPL pattern, you would probably need to recompile your WHOLE app -- even if your code hasn't changed at all -- and then get your users to download the new app AND the new Qt libraries. However, since Qt uses PIMPL, you don't have to do that; just distribute the new Qt libraries, and run your old app as usual. No recompilation required!
That was only a small, simple example. You can read about why Qt uses PIMPL here: http://qt-project.org/wiki/Dpointer
-
Bruce Eckel - Thinking in C++ book:
"Evolution of C++ programmers
C programmers seem to acquire C++ in three steps. First, as simply a “better
C,” because C++ forces you to declare all functions before using them and is
much pickier about how variables are used. You can often find the errors in a C
program simply by compiling it with a C++ compiler.
The second step is “object-based” C++. This means that you easily see the
code organization benefits of grouping a data structure together with the
functions that act upon it, the value of constructors and destructors, and
perhaps some simple inheritance. Most programmers who have been working
with C for a while quickly see the usefulness of this because, whenever they
create a library, this is exactly what they try to do. With C++, you have the aid
of the compiler.
You can get stuck at the object-based level because you can quickly get there
and you get a lot of benefit without much mental effort. It’s also easy to feel
like you’re creating data types – you make classes and objects, you send
messages to those objects, and everything is nice and neat.
But don’t be fooled. If you stop here, you’re missing out on the greatest part of
the language, which is the jump to true object-oriented programming. You can
do this only with virtual functions.
Virtual functions enhance the concept of type instead of just encapsulating
code inside structures and behind walls, so they are without a doubt the most
difficult concept for the new C++ programmer to fathom. However, they’re
also the turning point in the understanding of object-oriented programming. If
you don’t use virtual functions, you don’t understand OOP yet." -
bq. If you don’t use virtual functions, you don’t understand OOP yet
These are right if programmers do not overuse virtual and inheritance.
Exceptional C++, items 20~25 give a very good explanation
on OOP.bq. You can get stuck at the object-based level because you can quickly get there
and you get a lot of benefit without much mental effortLooks like my experiences is a little bit different than yours?
I used to like to design a virtual base class for different
projects, but now I would not do that atleast I find out I really
need virtual.Maybe someday I would like to design my programs
as pure OO again, but not now.Besides, don't forget other abstraction powers offer by C++.
C++ support many paradigms, not only OO, there are generic
programming, functioanl programming(not as easy to use as haskell),
procedural programming and metaprogramming(like functional
programming, but much more harder to codes than haskell, and do not
support runtime polymorphism, yet it is very a very powerful compile time tool). -
[quote author="john_god" date="1354801536"]I find this article very good, sharing it
"http://zedshaw.com/essays/master_and_expert.html":http://zedshaw.com/essays/master_and_expert.html[/quote]
Brilliant read, thanks for sharing :)
-
OOP is being over-advertised, but it has its own drawbacks, virtual methods cannot be inlined and may end up costing significant performance. Object orientation is not always best suited for being cache friendly, and simple approaches to implement better data orientation can provide substantial performance increase by reducing cache misses and cache pollution.
-
This post is deleted!
