By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,209 Members | 1,100 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,209 IT Pros & Developers. It's quick & easy.

C++ Coding Standards : 101 Rules, Guidelines, and Best Practices

P: n/a
C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
Herb Sutter, Andrei Alexandrescu is now a month or so away from
release. What is people's opinion on this...is it going to be a
seminal work or lackluster

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #1
Share this Question
Share on Google+
27 Replies


P: n/a
"Stuart Gerchick" <sg*******@bloomberg.net> wrote in message
news:e2**************************@posting.google.c om...
C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
Herb Sutter, Andrei Alexandrescu is now a month or so away from
release. What is people's opinion on this...is it going to be a
seminal work or lackluster


If I were capable of predicting the future, I'd be heading
for Las Vegas or Wall Street. And I can't give an opinion
about the literature itself, since I haven't seen it. However
I suspect it will be of value to many, based upon the reputations
of Herb & Andrei.

-Mike
Jul 22 '05 #2

P: n/a
On 31 Oct 2004 06:17:29 -0500, sg*******@bloomberg.net (Stuart Gerchick)
wrote:
C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
Herb Sutter, Andrei Alexandrescu is now a month or so away from
release.


In North America, it should be available in bookstores around now. Andrei
and I got our first copies a week ago, and it was available for sale at
OOPSLA. I haven't looked at my local Barnes & Noble or Borders yet.

More at http://pluralsight.com/blogs/hsutter...0/07/2709.aspx
...

Herb

---
Herb Sutter (www.gotw.ca) (www.pluralsight.com/blogs/hsutter)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Architect, Developer Division, Microsoft (www.gotw.ca/microsoft)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #3

P: n/a
apm
sg*******@bloomberg.net (Stuart Gerchick) wrote in message
news:<e2**************************@posting.google. com>...
C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
Herb Sutter, Andrei Alexandrescu is now a month or so away from
release. What is people's opinion on this...is it going to be a
seminal work or lackluster


Judging from the table of contents, it looks good. It seems to sum up
several pearls of wisdom from sources such as Meyers I, II, III and
GoTW. It looks like it is going to avoid the more contravesial
style-oriented guidelines, and so to me, does not appear to be like
other coding guidelines. I think it is more tutorial in nature and
thus may not be suitable for use by QA during code review. But who
knows, until it is actually published?

Regards,

Andrew Marlow

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #4

P: n/a
Herb Sutter <hs*****@gotw.ca> wrote in message news:<re********************************@4ax.com>. ..
On 31 Oct 2004 06:17:29 -0500, sg*******@bloomberg.net (Stuart Gerchick)
wrote:
>C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
>Herb Sutter, Andrei Alexandrescu is now a month or so away from
>release.


In North America, it should be available in bookstores around now. Andrei
and I got our first copies a week ago, and it was available for sale at
OOPSLA. I haven't looked at my local Barnes & Noble or Borders yet.

More at http://pluralsight.com/blogs/hsutter...0/07/2709.aspx
..

Herb


I didn't expect Herb Sutter himself to respond to this posting. I am
eagerly awaiting it actually and cant wait to have it in my hands.
Unfortunately, I am in the UK most of the time these days, and will
have to wait a bit for the release. I have it on order and it should
arrive soon.

Thank for for your time Herb. I appreciate it

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #5

P: n/a
>What is people's opinion on this...is it going to be a seminal work or
lackluster

With the book not released, how are we supposed to judge? And what do
people's opinions matter, at all, with so little to go on?

Stephen Howe

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #6

P: n/a
sg*******@bloomberg.net (Stuart Gerchick) wrote in message
news:<e2**************************@posting.google. com>...
C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
Herb Sutter, Andrei Alexandrescu is now a month or so away from
release.
At least some of the people I know have seen actual copies of the
printed book. (On the other hand, Amazon says "not yet been released".)
What is people's opinion on this...is it going to be a seminal work or
lackluster


How can anyone tell if they've not actually seen the book. And I'm not
quite sure what you mean by "seminal" -- I wouldn't have considered it
an antonym for lackluster. Given the authors, I expect lots of useful
information, and a readable style. Given the authors, I also expect
some information "just for fun", and some information which won't be
immediately usable because compilers and/or collegues who have to read
and understand the code aren't up to date. On the other hand, by
"seminal", I understand something that will change the way we think
about the language -- a priori, I don't expect either author to present
new ideas that they haven't already discussed here, for example. (In
the industry, from a pratical point of view, "seminal" often means,
"interesting, but not usable in the next ten years". While some of
Andrei's work might fall into that category -- especially if you have
difficulty getting updates for your collegues:-), for the most part, I
expect that most of the information in the book will be immediately
usable.)

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #7

P: n/a
"Stephen Howe" <st**********************************@eu.uu.net> wrote in
message news:<41*********************@reading.news.pipex.n et>...
What is people's opinion on this...is it going to be a seminal work or

lackluster

With the book not released, how are we supposed to judge? And what do
people's opinions matter, at all, with so little to go on?

Stephen Howe


As Herb Sutter said above it was available for sale at OOPSLA. People
have now seen it. The kinds of people who are on comp.lang.c++

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 22 '05 #8

P: n/a
sg*******@bloomberg.net (Stuart Gerchick) wrote in message news:<e2**************************@posting.google. com>...
C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
Herb Sutter, Andrei Alexandrescu is now a month or so away from
release. What is people's opinion on this...is it going to be a
seminal work or lackluster

I approach it from the standpoint that book (my copy showed up
yesterday) - as the title says - is a collection of 'best practices'.

Paragraph 3, page xiii states

" The coding standards introduced by this book are collection of
guidelines for writing high-quality C++ code. They are distilled
conclusions of a rich collective experience of the C++ community.
Much of this body of knowledge has only been available in bits and
pieces spread throughout books, or as word-of-mouth wisdom. This
book's intent is to collect that knowledge into a collection of rules
that is terse, justified, and easy to understand and follow".

The key IMO starts here "This book's intenet .. follow".

Here's one that I'm still confused - if you will - on what constitutes
the ideal implementation approach.

42 per the text. Dont give away your internals

Accessor and mutator as I understand it are - for the most part -
design flaws.
The example in the text shows a GetBuffer member function returing a
char*
In any event, when data needs to be shared among classes this
accessor/mutator beats the alternative (public member data) so I've
never quite understood this one.
A host of get and sets - I suspect - are signs of poor design. I'd
still like to see a concrete example that shows the solution.

My 2cents for what it's worth.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #9

P: n/a
Hi!

Stuart Gerchick wrote:
People
have now seen it. The kinds of people who are on comp.lang.c++


There are also European people on this newsgroup, like me. And
they don't have the book yet.

Frank
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #10

P: n/a
ma740988 wrote:
42 per the text. Dont give away your internals

Accessor and mutator as I understand it are - for the most part -
design flaws.
The example in the text shows a GetBuffer member function returing a
char*
In any event, when data needs to be shared among classes this
accessor/mutator beats the alternative (public member data) so I've
never quite understood this one.
A host of get and sets - I suspect - are signs of poor design. I'd
still like to see a concrete example that shows the solution.


OO design is about behavior. Classes should tell others what to do. If a
class takes data out of another, manipulates it, and puts it back in, then
the behavior is in the wrong class.

If you indeed share data, then this "data transfer object" should be a
separate thing, without any behavior, and the classes should pass it around.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #11

P: n/a
Phlip wrote:

OO design is about behavior. Classes should tell others what to do. If a
class takes data out of another, manipulates it, and puts it back in, then
the behavior is in the wrong class.
I don't know how widely shared that opinion is. One view of OOP is
expressed in Roman Mäder's _Computer Science With Mathematica_ as follows:
"An object is, therefore, a collection of data elements together with the
functions operating on them."
If you indeed share data, then this "data transfer object" should be a
separate thing, without any behavior, and the classes should pass it
around.


So, for example, and int should have a wrapper class called Integer?
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #12

P: n/a
Steven T. Hatton wrote:
Phlip wrote:

OO design is about behavior. Classes should tell others what to do. If a
class takes data out of another, manipulates it, and puts it back in, then the behavior is in the wrong class.


I don't know how widely shared that opinion is. One view of OOP is
expressed in Roman Mäder's _Computer Science With Mathematica_ as follows:
"An object is, therefore, a collection of data elements together with the
functions operating on them."


Designing a program means organizing the relations between its structure in
memory and their behavior in time.

OO design is about partitioning that behavior with polymorphism.

I am aware that the entry-level tutorials describe objects as data and the
functions that operate on them. You can also find tutorials that say "OO
objects are like real-world objects".
If you indeed share data, then this "data transfer object" should be a
separate thing, without any behavior, and the classes should pass it
around.


So, for example, and int should have a wrapper class called Integer?


Why?

It's the same question as before - what is an int's behavior? If it has only
a little, then it's a "value object", and unbeholden to any one class.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

Jul 22 '05 #13

P: n/a
Phlip wrote:
Steven T. Hatton wrote:
Phlip wrote:
> OO design is about behavior. Classes should tell others what to do. If
> a class takes data out of another, manipulates it, and puts it back in, then > the behavior is in the wrong class.


I don't know how widely shared that opinion is. One view of OOP is
expressed in Roman Mäder's _Computer Science With Mathematica_ as
follows: "An object is, therefore, a collection of data elements together
with the functions operating on them."


Designing a program means organizing the relations between its structure
in memory and their behavior in time.

OO design is about partitioning that behavior with polymorphism.


Not all classes exhibit polymorphism. How do the so-called concrete classes
fit into your model?
I am aware that the entry-level tutorials describe objects as data and the
functions that operate on them. You can also find tutorials that say "OO
objects are like real-world objects".


What I quoted from is a textbook used at ETH in Zrich. Perhaps you've heard
of the University? It's where Einstein got his degree in Physics.
> If you indeed share data, then this "data transfer object" should be a
> separate thing, without any behavior, and the classes should pass it
> around.


So, for example, and int should have a wrapper class called Integer?


Why?

It's the same question as before - what is an int's behavior? If it has
only a little, then it's a "value object", and unbeholden to any one
class.


I guess I'm confused about what you mean by shared data. Using set and get
methods is not typically considered sharing data. If I have a class called
Arrow which has different properties such as color, length, position,
rotation, etc., how am I supposed to manipulate objects of that class in
order to change these properties? Am I expected not to be interested in
the current value of these objects at runtime? If I am interested in
observing these values, then how am I expected to access them without 'get'
methods?

If I understand the opinion that I should not use set and get methods, it
means I should not have code such as that shown below. Is that what you
are trying to suggest?

class Light{
//...
virtual const array<GLfloat,4>& ambient() const {return _ambient; }

virtual void ambient(const array<GLfloat,4>& ambient_)
{
_ambient = ambient_;
}
virtual const array<GLfloat,4>& diffuse() const {return _diffuse; }

virtual void diffuse(const array<GLfloat,4>& diffuse_)
{
_diffuse = diffuse_;
}
virtual const array<GLfloat,4>& specular() const {return _specular; }

virtual void specular(const array<GLfloat,4>& specular_)
{
_specular = specular_;
}
virtual const array<GLfloat,4>& ambientModel() const
{
return _ambientModel;
}

virtual void ambientModel(const array<GLfloat,4>& ambientModel_)
{
_ambientModel = ambientModel_;
}

virtual GLenum light() const {return _light; }

virtual void light(GLenum light_)
{
_light = light_;
}
protected:
array<GLfloat,4> _position;
array<GLfloat,4> _ambient;
array<GLfloat,4> _diffuse;
array<GLfloat,4> _specular;

array<GLfloat,4> _ambientModel;

GLenum _light;
};

--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

Jul 22 '05 #14

P: n/a
Steven T. Hatton wrote:
Designing a program means organizing the relations between its structure
in memory and their behavior in time.

OO design is about partitioning that behavior with polymorphism.
Not all classes exhibit polymorphism. How do the so-called concrete

classes fit into your model?
Another aspect of design is how easily it can change. Most methods should
not be virtual, and most re-use should be delegated, not inherited.
I am aware that the entry-level tutorials describe objects as data and the functions that operate on them. You can also find tutorials that say "OO
objects are like real-world objects".


What I quoted from is a textbook used at ETH in Zrich. Perhaps you've

heard of the University? It's where Einstein got his degree in Physics.
I'm sitting on the same landmass as Cal Tech. Perhaps you have heard of Cal
Tech? It's where they invented something that I decline to look up with
Google.

I could let your fallacy of "appeal to authority" slide, except you seem to
think you are arguing with me about something. I'm not sure what.

The point: Classes should minimize getters and setters, because they should
expose access to behaviors.
I guess I'm confused about what you mean by shared data. Using set and get methods is not typically considered sharing data. If I have a class called Arrow which has different properties such as color, length, position,
rotation, etc., how am I supposed to manipulate objects of that class in
order to change these properties? Am I expected not to be interested in
the current value of these objects at runtime? If I am interested in
observing these values, then how am I expected to access them without 'get' methods?


Okay, I'm going to make a great effort to agree with you here, but I need
you to know that before I start, because I'm trying to avoid one of /those/
threads...

Consider this graphic:

A -> B

The "behavior" of -> is that it points at B. However, if we move B...

A ->
B

....then -> no longer points at B. Let's call that behavior "extrinsic".

->'s intrinsic behavior is its tail is there and its head is here, etc. Set
these behaviors with setters.

Limit your application's access to those setters. A class aware of A -> B
could respond to high-level commands that move B by fixing the extrinsic
behavior of the arrow. However, that AB class should not make its awareness
of -> public. The buck stops here.

Encapsulation is hierarchical. The rule "Don't make primitive things
globally public" is more useful than the rule "don't make data members
public".

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
Jul 22 '05 #15

P: n/a
Phlip wrote:
Steven T. Hatton wrote:
Not all classes exhibit polymorphism. How do the so-called concrete classes
fit into your model?


Another aspect of design is how easily it can change. Most methods should
not be virtual, and most re-use should be delegated, not inherited.


That really depends on what you are designing. IMO, if you make one member
function virtual, you should have a good reason /not/ to make the remainder
virtual. I'll follow Stroustrup's convention of reserving the term
"method" for pure virtual member functions.
I could let your fallacy of "appeal to authority" slide, except you seem
to think you are arguing with me about something. I'm not sure what.
There is no fallacy in appeal to authority when the subject is one of widely
help opinions in a field. The opinions of authorities in the field
constitute the topic.
The point: Classes should minimize getters and setters, because they
should expose access to behaviors.
The fundamental concept of object oriented programming is the idea of data
objects combined with associated operators.
Okay, I'm going to make a great effort to agree with you here, but I need
you to know that before I start, because I'm trying to avoid one of
/those/ threads...

Consider this graphic:

A -> B

The "behavior" of -> is that it points at B. However, if we move B...

A ->
B

...then -> no longer points at B. Let's call that behavior "extrinsic".

->'s intrinsic behavior is its tail is there and its head is here, etc.
Set these behaviors with setters.

Limit your application's access to those setters. A class aware of A -> B
could respond to high-level commands that move B by fixing the extrinsic
behavior of the arrow. However, that AB class should not make its
awareness of -> public. The buck stops here.

Encapsulation is hierarchical. The rule "Don't make primitive things
globally public" is more useful than the rule "don't make data members
public".


This seems like a far weaker statement than the idea that using set and get
methods indicated a probable design flaw. That was, IIRC, the point at
which this thread forked. Stroustrup makes a similar assertion in
TC++PL(SE) regarding set and get methods. I have questioned that in this
newsgroup, and I have never been convinced of the merits of the general
guideline. Perhaps a better statement might be 'Be judicious in what you
expose through accessor methods'. That I can agree with.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

Jul 22 '05 #16

P: n/a
Someone wrote:
Accessor and mutator as I understand it are - for the most part -
design flaws.
The example in the text shows a GetBuffer member function returing a
char*
In any event, when data needs to be shared among classes this
accessor/mutator beats the alternative (public member data) so I've
never quite understood this one.
A host of get and sets - I suspect - are signs of poor design. I'd
still like to see a concrete example that shows the solution.


You are asking for a concrete solution to an unexpressed problem. Remember
we can't see what you are looking at in a book.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #17

P: n/a
Steven T. Hatton wrote:
This seems like a far weaker statement than the idea that using set and get methods indicated a probable design flaw.
Using getters and setters indicates a probable design flaw.
That was, IIRC, the point at
which this thread forked. Stroustrup makes a similar assertion in
TC++PL(SE) regarding set and get methods. I have questioned that in this
newsgroup, and I have never been convinced of the merits of the general
guideline. Perhaps a better statement might be 'Be judicious in what you
expose through accessor methods'. That I can agree with.


Encapsulation is hierarchical. The root principle of OO is encapsulation of
indirection. Without polymorphism there is no OO. (Regardless of whether a
given program happens to use virtuals.)

"Data objects with the methods that operate on them" is just "object based".

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
Jul 22 '05 #18

P: n/a
Phlip wrote:
Steven T. Hatton wrote:
This seems like a far weaker statement than the idea that using set and

get
methods indicated a probable design flaw.


Using getters and setters indicates a probable design flaw.


In your unsubstantiated opinion.
That was, IIRC, the point at
which this thread forked. Stroustrup makes a similar assertion in
TC++PL(SE) regarding set and get methods. I have questioned that in this
newsgroup, and I have never been convinced of the merits of the general
guideline. Perhaps a better statement might be 'Be judicious in what you
expose through accessor methods'. That I can agree with.


Encapsulation is hierarchical. The root principle of OO is encapsulation
of indirection. Without polymorphism there is no OO. (Regardless of
whether a given program happens to use virtuals.)

"Data objects with the methods that operate on them" is just "object
based".


My reason for saying the fundamental concept of object oriented programming
is the idea of data objects combined with associated operators, is based on
a comment in Ole-Johan Dahl's The *Birth of Object Orientation: the Simula
Languages*:

"... The example shows that the idea of data objects with associated
operators was under way already in 1965."

That seems to be the watershed in his mind as to when OOP first appeared. I
will note that he subsequently adds:

"There is universal use of the term "object orientation", OO. Although no
standard definition exists, some or all of the above ideas enter into the
OO paradigm of system development."

You are free to continue making absolute assertions such as "OO design is
about behavior", but please don't expect such statements to be taken too
seriously by experience computer professionals.

--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

Jul 22 '05 #19

P: n/a
Steven T. Hatton wrote:
Phlip wrote:

Using getters and setters indicates a probable design flaw.


In your unsubstantiated opinion.


I stopped reading here.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
Jul 22 '05 #20

P: n/a
"Phlip" <ph*******@yahoo.com> wrote in message
news:<pD****************@newssvr16.news.prodigy.co m>...
ma740988 wrote:
> 42 per the text. Dont give away your internals > Accessor and mutator as I understand it are - for the most part -
> design flaws. The example in the text shows a GetBuffer member
> function returing a char* In any event, when data needs to be
> shared among classes this accessor/mutator beats the alternative
> (public member data) so I've never quite understood this one. A
> host of get and sets - I suspect - are signs of poor design. I'd
> still like to see a concrete example that shows the solution.

OO design is about behavior. Classes should tell others what to do. If
a class takes data out of another, manipulates it, and puts it back
in, then the behavior is in the wrong class. If you indeed share data, then this "data transfer object" should be a
separate thing, without any behavior, and the classes should pass it
around.


Which begs the question: what should you do about these shared objects?

My experience suggests that there are two radically different types of
"data classes". The first are your classical value classes, which
typically, you copy (although if the value has a lot of state, e.g. a
matrix of some sort, you might prefer to avoid copying for performance
reasons). This includes all of the basic types -- a double has a state,
and there is an allowed set of operations on it, but any identity that
it has is fully represented by its value. The second are entity data
sets (or whatever you want to call them -- I've yet to find a good
name). Typically, they are collections of data which have an identity;
if they are copiable or assignable, it is to support transactions and
roll-back, and that is all. Often, I find it useful to support two
interfaces to such classes, one read-only, and a second which allows
mutation. Generally, such classes are maintained by some sort of
dedicated collection or manager. Such classes are, however, usually
pure data; true behavior and business logic are situated elsewhere (and
generally depend on more than one object of this sort).

IMHO, depending on the applications, setters and getters may be
perfectly appropriate for this second category. In other applications,
just using a struct may be even more appropriate.

In the end, I think the warning is appropriate. If you find that most
of your classes, regardless of their role in the system, are full of
getters and setters, you are probably doing something wrong. On the
other hand, if the role of the class is a data holder, then you have
encountered the obvious exception which confirms the rule. Of the many,
many different roles a class can have, there is only one (or very few)
where the exception is really justified. The fact that there are
classes in this role in a lot of applications, and that in some
particular applications, they may even represent the majority of
classes, is irrelevant. It's still just one role.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #21

P: n/a
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message news:<Wc********************@speakeasy.net>...

[ ... ]
There is no fallacy in appeal to authority when the subject is one of widely
help opinions in a field. The opinions of authorities in the field
constitute the topic.
In the case of what a phrase is generally understood to mean, I'd have
to agree. In this case, however, the people you quote don't seem to be
the most widely recognized people in the field; worse, you seem to be
(at best) warping what they're saying, to at lesat some degree, to get
what you want out of it rather than reading it for what it really
says.

Most of the better-recognized "experts" do seem to agree that "object
oriented" is only really correct when inheritance is used, not simply
when objects are used.

Just for a few examples: _Object Oriented Analysis and Design With
Applications_ (Grady Booch) defines object oriented programming as:

Object-Oriented Programming is a method of implementation in which
programs are organized as cooperative collections of objects, each
of which represent an instance of some class, and whose classes
are
all members of a hierarchy of clases united via inheritance
relationships.

He then dissects this, pointing out three salient points: 1) objects,
2) classes, 3) inheritance. He then reiterates the requirement for
inheritance, saying "Specifically, programming without inheritance is
distinctly not object oriented: we call it programming with abstract
data types."

He also quote Cardelli and Wegner's definition of an object-oriented
langauge, which (unsurprisingly) also has three elements, closely
matching those for object-oriented programming above.
The point: Classes should minimize getters and setters, because they
should expose access to behaviors.


The fundamental concept of object oriented programming is the idea of data
objects combined with associated operators.


This concept is necessary, but insufficient by almost every definition
extant.

[ ... ]
This seems like a far weaker statement than the idea that using set and get
methods indicated a probable design flaw. That was, IIRC, the point at
which this thread forked. Stroustrup makes a similar assertion in
TC++PL(SE) regarding set and get methods. I have questioned that in this
newsgroup, and I have never been convinced of the merits of the general
guideline. Perhaps a better statement might be 'Be judicious in what you
expose through accessor methods'. That I can agree with.


I'd put it a bit more strongly than that -- I'd consider an accessor
roughly on a par with a goto. Sometimes it's bad and other times it's
mearly mediocre -- but in the end, _nearly_ the only good excuse for
using either one is that what you're working on is simplky a quick
hack, and doing something better simply isn't justified.

I know, there are people who will claim that they have a piece of code
that justifies using a goto, and others who show what they claim is
justification for an accessor method. Unfortunately nearly every
example of "good" uses of accessors starts out with a poor
specification (on the order of: "this class needs to provide access to
X...and therefore it needs to include an accessor"). In nearly every
case, it also turns out to be fairly incomplete, with little or no
thought about how the rest of the system would/will really work.

OTOH there almost certainly ARE some kinds of classes that need
accessors, or at least things that try to look like them. An obvious
example would be something like std::vector or std::map, that simply
stores data and allows the user to retrieve it when needed. In this
case, 'store' and 'retrieve' data, translates almost directly to
things like look like accessors, although (especially in the case of
map) they will typically be implemented as fairly complex algorithms.

Classes like these, however, rarely provide particularly high levels
of abstraction. They're a step up from working with raw memory and
such (e.g. C arrays) but they (usually) still don't relate very
closely to solving the problem at hand. As such, while their existence
and use is usually easy to justify, you should normally strive to bury
them inside of classes that relate more closely to the real-world
problem being solved -- i.e. code that operates at a higher level of
abstraction, further away from simply storing and retrieving data in
memory.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jul 22 '05 #22

P: n/a
Jerry Coffin wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:<Wc********************@speakeasy.net>...

[ ... ]
There is no fallacy in appeal to authority when the subject is one of
widely
help opinions in a field. The opinions of authorities in the field
constitute the topic.
In the case of what a phrase is generally understood to mean, I'd have
to agree. In this case, however, the people you quote don't seem to be
the most widely recognized people in the field; worse, you seem to be
(at best) warping what they're saying, to at lesat some degree, to get
what you want out of it rather than reading it for what it really
says.


Are you suggesting Dahl is not regarded as one of the authorities in OOP?
That's the only other person I recall quoting in this thread.


I'd put it a bit more strongly than that -- I'd consider an accessor
roughly on a par with a goto. Sometimes it's bad and other times it's
mearly mediocre -- but in the end, _nearly_ the only good excuse for
using either one is that what you're working on is simplky a quick
hack, and doing something better simply isn't justified.


So accessing the contents of a std::vector<> using an index is bad design?
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

Jul 22 '05 #23

P: n/a
Frank Birbacher <bl************@gmx.net> wrote in message news:<2v*************@uni-berlin.de>...
Hi!

Stuart Gerchick wrote:
> People
> have now seen it. The kinds of people who are on comp.lang.c++


There are also European people on this newsgroup, like me. And
they don't have the book yet.

Frank


I am based in the UK myself these days, which is why I dont have the book yet

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 22 '05 #24

P: n/a
ma740988 wrote:
A host of get and sets - I suspect - are signs of poor design. I'd
still like to see a concrete example that shows the solution.


Once I worked on a project that involved object/relational mapping. It
included Data Access layer, comprised of data objects and a data mapper.
Data objects were mere state without any behavior with typed
getters/setters and were used as data primitives for a higher layer -
Object Domain Model. Data mapper was responsible for mapping data objects
to and from relational model (sql database).

To reduce the efforts while implementing the data mapper all data objects
contained generic state:

typedef std::string field_name;
typedef std::map<field_name, variant> state;

So, the data mapper knew nothing about data object classes and could only
deal with raw generic state (actually it could do a lot more things, but
I'll spare you).

Data objects were interfaces with bunches of getters/setters only that
provided strong typing to the generic state, represented like:

struct InstrumentData : DatabaseObject
{
typedef InstrumentData SuperClass;

virtual tstringp Name() = 0;
virtual tstringp FullName() = 0;
virtual tstringp IsinCode()= 0;
virtual tstringp CfiCode()= 0;
virtual uint32p DaysToSpot() = 0;
virtual UUIDp PricingCurrencyId() = 0;
virtual CurrencyDataP PricingCurrency() = 0;
};

Those types ending with small p (style matters aside) were proxy objects
like:

template<class T>
struct value_proxy
{
value_proxy(varant& v) : v_(&v) {}
operator T const&() const { return varant_cast<T&>(*v_); }
value_proxy const& operator=(T const& t) { varant_cast<T&>(*v_) =
t }
value_proxy const& operator=(value_proxy const& p)
{ varant_cast<T&>(*v_) = static_cast<T const&>(p); }
variant* v_;
};

typedef value_proxy<uint32> uint32p;

So, putting all together, implementation of those data objects were like:

struct InstrumentDataImpl : InstrumentData
{
state state_;
// ...
uint32p DaysToSpot() { return state_["days_to_spot"]; }
// ...
};

And a user worked with data objects like:

smart_ptr<InstrumentData> id;
// ...
uint32 day = id->DaysToSpot();
id->DaysToSpot() = day + 1;

So, to me it looked like a good and usefull application of getters/setters
(funny, but it also was the only one I could think of).

--
Maxim Yegorushkin

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 22 '05 #25

P: n/a
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message news:<Ff********************@speakeasy.net>...
Phlip wrote:

OO design is about behavior. Classes should tell others what to do. If a
class takes data out of another, manipulates it, and puts it back in, then
the behavior is in the wrong class.


I don't know how widely shared that opinion is. One view of OOP is
expressed in Roman Mäder's _Computer Science With Mathematica_ as follows:
"An object is, therefore, a collection of data elements together with the
functions operating on them."


That is exactly the same. The example is not OO, because the collection
of data elements is in one class and the functions operating on them are
in another. Maeder states that these should not be distributed over two
objects, instead they should be in the same object.

Regards,
Michiel Salters

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #26

P: n/a
Michiel Salters wrote:
Steven T. Hatton wrote:

> I don't know how widely shared that opinion is. One view of OOP is
> expressed in Roman Mäder's _Computer Science With Mathematica_ as follows: > "An object is, therefore, a collection of data elements together with the > functions operating on them."


That is exactly the same. The example is not OO, because the collection
of data elements is in one class and the functions operating on them are
in another. Maeder states that these should not be distributed over two
objects, instead they should be in the same object.


"How" to partition behavior into methods is an aspect of design, in general.
If a given design happened to partition the data here and their functions
there, it wouldn't be "less OO".

Put another way, I can't say my design is better than yours because it's
"more OO", or because it gloms all functions and all their data into the
same objects. Such a claim brings nothing to the debate whether my design is
any good. (A more useful claim would be my design is easier to safely
upgrade.)

OO is when a language permits partitioning along a virtual dispatch system
typesafely synchronized with an object's encapsulation interface.

Targeting the Subject line, all designs should reduce their primitive data's
exposure to getting and setting, whether they are OO or not.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #27

P: n/a
ma740988 wrote:

Here's one that I'm still confused - if you will - on what constitutes the ideal implementation approach.

42 per the text. Dont give away your internals

Accessor and mutator as I understand it are - for the most part -
design flaws.
The example in the text shows a GetBuffer member function returing a
char*
In any event, when data needs to be shared among classes this
accessor/mutator beats the alternative (public member data) so I've
never quite understood this one.
A host of get and sets - I suspect - are signs of poor design. I'd
still like to see a concrete example that shows the solution.

My 2cents for what it's worth.


OK, I bought the book, and can now see what it says. It really isn't
talking about accessor/mutator functions, per se. It's saying not to
expose internal state in such a way as to compromise the class's
ability to
maintain a consistent state(invariant). Furthermore, don't expose
internals which are subject to change without notification to the user.

Don't give unaccountable strangers your credit card number.
Don't write checks for which you cannot guarantee the availability of
funds
for a reasonable duration.
If you do write a check that can only be guaranteed for a short period,
stipulate the condition.
Don't build a massive conventional force and fail to secure your
borders
against unconventional combatants.

--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what
we
are talking about, nor whether what we are saying is true." - Bertrand
Russell
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 22 '05 #28

This discussion thread is closed

Replies have been disabled for this discussion.