Re: Programmer knowledge

From: Malcolm (malcolm_at_55bank.freeserve.co.uk)
Date: 03/28/04 

Date: Sun, 28 Mar 2004 14:29:36 +0100

"Gerry Quinn" <gerryq@indigo.ie> wrote in message
>
> Certainly it *ought* to be - but there's no guarantee that it is!
> Some objects on your array might have a salary() function that
> returns a string. Even if it returns a numeric type, there's no
> certainty that it means the same thing. It might be the payment date
> expressed as an integer.
>
All the objects have to be of the same Employee() type, since templates
don't provide true binding by name.
>
> What we want, therefore, is a way of making sure that our array
> contains objects that have a common meaning for salary() etc. In
> other words, they should be derived from a base class, which we
> might call Money (or whatever, that's a bad name but we used it up
> to now).
>
A "Money" class would hold an amount that represents a financial value.
Probably it would just be a manged integer, but we could derive other
classes from it, such as "credit", which could be money tagged with an
owner.
Deriving Employee from a money base class, however, on the grounds that
Employees have a salary attached, is a really bad idea. An Employee "has a"
salary, but does have an "is a" realtionship with money.
This of course is the huge problem with OO design - it is very difficult to
do, and very easy to get into a mess with.
>
> But we know (see above) that getting away from it is a bad thing! > We
gain nothing and lose protection, as well as encapsulation. We
> only want to use Payroll() with classes where it is meaningful and
> we know what it means. Using generic programming in this
> example would be a disastrously bad approach.
>
The problem is that C++ doesn't allow us to do what we really want to do,
which is to run a payroll on any sequence of Employees. In pseudo-C++, what
we want is

void payroll(Employee::iterator first, Employee::iterator last)

Use of templates allows us to use any type of iterator, which is sensible
because there is no reason why payroll() should insist on data being in an
array or any other kind of structure. It also, as a side-effect, allows us
to pay anything with a name(), NI_number() and salary(). This is very much a
two-edged sword, because it is very hard to document the function so that
people can take advantage of this without looking at the source.
>
> You're the C programmer, not me - I never use that language. The
> carpenter understands that most of the special chisels are for
> particular jobs, and do not have any use in day-to-day carpentry.
>
A lot of C++ regard exceptions as a "special chisel", but in fact you need
them for a constructor to fail. You also need to catch STL exceptions to
handle memory failure gracefully.
Templates I would say are also not a "special chisel" but things to be used
extensively to leverage the power of STL, in particular to work on any kind
of collection. However I conced that the C++ langauge isn't ideal.
It's also quite common to see C++ programs which make no or very little use
of inheritance. These programs would be better written in C - you are not
writing OO programs until objects have relations with each other, which in
C++ usually means inheritance.
Operator functions are something that many programmers dislike, but in fact
these go well with templates. It is a lot easier to document "must have +
and - operators defined" than try to specify member functions.
However a real example of a "special chisel" would be multiple inheritance.
This could be made to work as a traits (a streetlamp is a light, is a static
object, is an electricity consumer etc) but the C++ method is really too
unwieldy to make this manageable.

Relevant Pages

  • Re: (also for /) on Failure rates....
    ... find on Amazon.com as a used book for very little money. ... proof of the triump of theivery over business. ... Debunking Economics: The Naked Emperor of the Social Sciences ... employee you are on the losing end of the deal. ...
    (sci.research.careers)
  • Re: genY has no interest in hi-tech careers
    ... Sometimes the History Channel. ... find on Amazon.com as a used book for very little money. ... Debunking Economics: The Naked Emperor of the Social Sciences ... employee you are on the losing end of the deal. ...
    (sci.research.careers)
  • Finally, the "snotbook" list.....
    ... proof of the triump of theivery over business. ... businesses would rather spend the same amount of money to fight unions than just give the money to employees and the fighting ... Debunking Economics: The Naked Emperor of the Social Sciences ... employee you are on the losing end of the deal. ...
    (sci.research.careers)
  • Re: Syntax for user-defined infix operators
    ... notation is record.field. ... Yes, but for a record field is a name, for an array index is an expression. ... In the above, because they are constants, parentheses are optional so ... operation defined on the employee type. ...
    (comp.lang.misc)
  • Re: Pointer to an array
    ... I have an structure called employee that will put all of the employee ... Or are you trying to store 10 10-character strings to a single array? ... I then store the pointer of this structure off into another structure ... first valid eid from the original structure) and that goes on and does ...
    (comp.lang.c)
Loading