Az Tech said:
Hi people,
(Sorry for the somewhat long post).
I request some of the people on this group who have good experience
using object-orientation in the field, to please give some good ideas
for topics to include in a course on object-orientation that I'm going
to conduct.
The topic of this newsgroup is the ISO standard C++
programming language, not "object orientation."
(I will later summarize all the replies and discussion, for the
benefit of everyone.)
Please don't do so here.
The context:
I'm going to conduct a course on object-orientation for a small group
of developers, who have from 1 to 3 or 4 years of experience in C++ or
Java.
You're going to conduct a course about this, but you don't
know which topics to include, or in what order? Sounds like
you're not really qualified to teach such a course then.
However, they have not had any formal or even semi-formal training on
how to actually think and program in an object-oriented way, so as to
really get the benefits of OO.
Why are you so sure OO is going to benefit them?
OO is not a panacea for all programming tasks.
They will be working (actually, as
often happens in the real world, have already started to work) on a
somewhat large project that is going to (or should) use OO heavily,
Why do you think it should?
since it will use C++ and Java.
I don't know much about Java, but using C++ imposes
absolutely no requirements for using OO.
I, who am a member of the same team, will be conducting the course,
but am not highly experienced in OO either.
Then again, I'll say I don't think you're qualified to
teach such a course. Why not hire a real experienced
professional? (But first, I'd make sure that there is
indeed a real need for OO).
I have a development
background - a lot in C, some in Java and a little in C++. But
wouldn't consider myself as having a solid grasp of object-orientation
in the sense of being able to really apply it well in the real world
in such a way as to derive its true benefits.
Then you're not qualified to teach a course about it.
I have done some programming myself in C++ and Java, and have also
read some books on these languages and some on OO concepts, but still
feel that I have a long way to go to really consider myself tolerably
good at OO.
Then continue studying and practicing, and perhaps
take a course yourself.
Still, I came up with the idea of conducting the course, because I
strongly believe that just knowing the syntax and semantics of an OO
language is not enough
A successful conducting of a course needs an instructor
who really does know the material well. You admit that
you don't.
Also, you exhibit a misconception about C++. It is not
an 'OO language'. It's a language that supports several
paradigms, one of which is OO. One is not forced to write
OO code simply because the language is C++.
- that's not (only) what OO is really all
about,
Learn what C++ is all about. It's not *all* about OO.
and since no one else is available at short notice to conduct
such a course, I decided to try and develop and conduct it myself.
I'm envisioning the 'blind leading the blind'.
It takes quite a while to learn OO well. If you don't
'have time', you'll need to make some. A good instructor
can often expedite the learning process (provided the students
have motivation and patience), but it will still take some time.
I've done some research in books and on the Net and have collected
some material,
Since you profess to not be an expert in OO, how can you
know whether this material is correct or not? (There's far
more wrong information on the 'net than correct information
-- this can be said about almost any topic).
and also created some material of my own (concepts and
some code examples),
How do you know it is valid and correct?
based on whatever little knowledge of OO I have.
I just don't understand. You say you have 'little knowledge'
about a topic. But you want to teach it to others? What's
wrong with this picture?
But I'd like to get some ideas and suggestions from people who have
used OO in the trenches,
The people participating here do so because they use or
are interested in ISO C++. Some use it for OO, others
for other things. C++ is topical here, OO is not.
and really leveraged some of the claimed
benefits (which I'm not in doubt of)
Why not? Are you taking folks word about it at face value,
or has anyone actually explained these 'benefits' to you so
that you understand them? Such 'benefits' almost always
depend upon context.
of OO to develop more reusable /
flexible / maintainable software.
C++ (using its OO features or not) does help much with that imo.
As a matter of fact, I find that one of, if not 'the' greatest
strength of C++ is that it enhances programmer productivity.
This strength is not dependent upon using OO features.
As of now the structure of the course is something like this:
- mention some of the important OO concepts: the ones I've come up
with until now are :
abstraction,
Abstraction is not specific to OO. It's a more general
programming concept.
encapsulation, information hiding,
Same with those.
inheritance (single
and multiple), polymorphism,
These are OO concepts.
reuse, separating the interface from the
implementation,
These are not specific to OO. They're more general
programming concepts.
public vs. protected vs. private methods.
These are "OO-like", but not specific to OO.
They're more related to information hiding
and interfaces, which are not specific to OO.
I have some
material explaining some of these concepts
How do you know the material is correct?
and less in the form of
examples, but would like inputs that anyone can give on both the
concepts
I offered my two cents about those you enumerated above.
as well as good code examples
Many very good code examples for C++ are available in
quality C++ textbooks, some using OO, others not.
See
www.accu.org for peer reviews of books on C++.
for them (preferable in C++ and
/ or Java,
C++ is topical here. Neither Java nor OO are.
since those are the languages going to be used on the
project).
If you have questions or comments about the ISO standard
C++ programming language, by all means post them here.
But please refrain from posting material about anything
else, including Java or OO.
- try and give some short (or medium-sized) program examples - in C++
See above about C++ examples.
and Java - of the above concepts -
Neither of those are topical here.
the examples should be such that it
should be possible to actually see - with the help of some explanatory
text - the actual benefit obtained (in the code) from using that
particular OO feature or concept.
You can achieve this with a quality C++ textbook's
section(s) on its OO capabilites.
For example, if talking about the
concept "separating the interface from the implementation",
This is not specific to OO, but a more general programming concept.
I have an
example of only allowing access to data members of a class via methods
(getter and setter),
IMO well designed classes rarely need such direct
'getting' and 'setting', and only participate in
'internal implementation' of a given concept.
i.e. never or nearly never allowing data members
to be public.
That's a good 'rule of thumb', but beware of generalizations.
for this case (which will probably be
familiar to many of you), of a Point class with data members x and y,
representing a point in 2-dimensional space. Kept the data members as
private, and provided public getX/getY/setX/setY methods.
Why do you think you need those?
he example
talks about how this helps, by saying that, tomorrow, if for some
reason, I want to change the implementation of the data members to use
polar coordinates (r, the radius, or distance of the point from the
origin, and theta, the angle made by the positive x-axis and a line
drawn from the point to the origin (0,0) ), since I've kept the data
members private, I can easily do this without breaking any client code
Not necessarily. What about all the existing code that creates
and modifies these objects? Will the constructor and member function
arguments being passed still be valid?
Having such 'getter' and 'setter' functions leads you away
from flexibility, not toward it.
This is the opposite of separating the implemenation
from the interface.
instead of "return x;" , I now have " return r *
cos(theta); ".
Similarly for getY, and setX and setY, using the standard
mathematical
formulae for conversion between Cartesian and polar coordinates.
Part of the code of the Point class, in C++:
class Point
{
private:
double x_;
double y_;
public:
double getX() { return x_; }
double getY() { return y_; }
double distance_from_origin()
{
return sqrt( (x_ * x_) + (y_ * y_) );
// or:
return sqrt( (getX() * getX()) + (getY() * getY()) ); // !!!
}
};
[ Also, please look at the line with the comment // !!!.
Yes, I see it. Note that you're wasting function calls there.
Since this function is a member of the same class, it already
has direct access to the data members. You can replace the
calls to 'getX()' and 'getY()' with 'x_' and 'y_'.
IMO member functions should be the only entites which
have such direct access to private data. Your 'get'
and 'set' functions give them access from outside.
I would like comments on the pros and cons of using this second line
(second form of the return statement) instead of the line above it,
I believe the first line is the better way.
in
terms of OO benefits vs. slower performance.
The first line is more 'OO', and *might* have better
performance.
Someone in the course
raised this point;
What point?
my own opinion (which I said to him) is that the
second line is probably preferable,
Why?
even though it's within a method
internal to the class, and that optimizing compilers may convert it to
an equivalent of the first line, so we get both the benefits of
information hiding and performance, but wasn't able to convince him.
You haven't convinced me either.
Not sure myself if what I said to him is right. ]
And you propose to *teach* this stuff? Methinks you
should learn it first.
Now, I'm looking for help with adding to the list of concepts,
Your list has more problems than needing more items. Many
of them don't belong there. Even if the list were correct,
why do you feel there should be more items?
and
some examples for each of them. Some other concepts I have in mind to
include are:
- inheritance, polymorphism, metaclasses (I'm aware that metaclasses
are an advanced topic and not used much in day-to-day work, but would
like to mention the topic with a good example or two),
Metaclasses are not part of C++. I suppose one might
say they're OO.
frameworks
(thought of mentioning Java servlets and ACE as examples of
frameworks), and patterns
Niether 'frameworks' nor 'patterns' are C++ concepts
or OO concepts.
(since frameworks and patterns are often
used along with OO).
Yes, OO is sometimes used to implement frameworks and
patterns, but they can be implemented in many other
ways and/or languages.
For inheritance and polymorphism, since I somewhat understand the
concepts, and know of some examples in some good books, and also have
been able to come up with some small examples of my own,
You admit that you only 'somewhat' understand. How do you
know your examples are correct or effective?
I can manage
(though I still would appreciate any examples that anyone would care
to give).
Many very good examples of C++'s inheritance and polymorphism
features can be found in any quality textbook. Again, see
www.accu.org
For the other topics mentioned above, as well as any I have
not mentioned that anyone thinks are part of OO
Your problem is more with thinking certain things are
OO when they're not, not with leaving things out.
and should be
mentioned, I'd appreciate direct inputs and/or pointers to Net
resources or books that give the concepts and preferable some code
examples.
A good source of C++ information and resources is the
C++ FAQ:
http://www.parashift.com/c++-faq-lite/
Information about other topics, such as OO is not topical
here.
-Mike
