classes

[john townsley]

do people prefer to design classes for the particular job or for a rangle of
tasks they might encounter now and in the future.
i am doing some simple win32 apps and picking classes is simple, but
understanding others peoples logic isnt (that doesnt mean they are wrong).

i prefer designing classes for the currect job and making tangible 'things'
classes , not overdoing it with loads of classes or inheritance..

it seems easier to make classes and use previous work if possible. the idea
of making re-usable code to be used all the time is impractical
Also using polymorphism,inheritance etc on old code to make it usabke for
now is an overhead of simplictity to read. Again simply designing classes
from scratch with previous work as a help seems easier to do.

are there any rules of thumb for this

 

[Victor Bazarov]

do people prefer to design classes for the particular job or for a rangle
of tasks they might encounter now and in the future.
Yes.

i am doing some simple win32 apps and picking classes is simple, but
understanding others peoples logic isnt (that doesnt mean they are wrong).

Understanding others is never simple.

i prefer designing classes for the currect job and making tangible
'things' classes , not overdoing it with loads of classes or inheritance..
OK.

it seems easier to make classes and use previous work if possible. the
idea of making re-usable code to be used all the time is impractical

Well, that's not what the Standard Library designers thought...

Also using polymorphism,inheritance etc on old code to make it usabke for
now is an overhead of simplictity to read. Again simply designing classes
from scratch with previous work as a help seems easier to do.

'Seems' is probably the key word here.

are there any rules of thumb for this

The rule of thumb is simple: do what's easier. Of course, some understand
that rule as "do what's easier NOW", and some as "do what's easier IN THE
LONG RUN". I guess it depends on your expectation of the lifetime of your
own work. I've written a few "one-timers" myself. They did their work as
needed when they were created, and were never designed for re-use. It is
quite possible that among those I've written some more than once to do the
same essential task. If the amount of such share is below one quarter of
all "one-timers", it's probably OK. If every time you when you sit down to
write a one-timer you suddenly, half-way through implementation, realise
that "you can swear you've done it before and probably more than once",
then you ought to keep those and document them well.

It's one thing to reinvent the wheel that was invented by others. It's
totally different thing to reinvent your own wheel [all the time].

Another sentiment: when we were little, we were taught: repetition is the
mother of learning. The question is, are you still consider yourself
learning or is it really time to grow?

Re-use is the cornerstone of good design. When you don't intend something
to be re-used, you usually do not apply enough thought to its design. It
becomes a vicious circle, a catch-22: you can't re-use your old work since
it wasn't designed for it, so you start writing everything anew, and it too
comes out non-re-usable because you don't have time nor the intent to do it
right.

V

 

[john townsley]

do people prefer to design classes for the particular job or for a rangle
of tasks they might encounter now and in the future.
Yes.

i am doing some simple win32 apps and picking classes is simple, but
understanding others peoples logic isnt (that doesnt mean they are
wrong).

Understanding others is never simple.

i prefer designing classes for the currect job and making tangible
'things' classes , not overdoing it with loads of classes or
inheritance..
OK.

it seems easier to make classes and use previous work if possible. the
idea of making re-usable code to be used all the time is impractical

Well, that's not what the Standard Library designers thought...

Also using polymorphism,inheritance etc on old code to make it usabke for
now is an overhead of simplictity to read. Again simply designing classes
from scratch with previous work as a help seems easier to do.

'Seems' is probably the key word here.

are there any rules of thumb for this

The rule of thumb is simple: do what's easier. Of course, some understand
that rule as "do what's easier NOW", and some as "do what's easier IN THE
LONG RUN". I guess it depends on your expectation of the lifetime of your
own work. I've written a few "one-timers" myself. They did their work as
needed when they were created, and were never designed for re-use. It is
quite possible that among those I've written some more than once to do the
same essential task. If the amount of such share is below one quarter of
all "one-timers", it's probably OK. If every time you when you sit down
to
write a one-timer you suddenly, half-way through implementation, realise
that "you can swear you've done it before and probably more than once",
then you ought to keep those and document them well.

It's one thing to reinvent the wheel that was invented by others. It's
totally different thing to reinvent your own wheel [all the time].

Another sentiment: when we were little, we were taught: repetition is the
mother of learning. The question is, are you still consider yourself
learning or is it really time to grow?

Re-use is the cornerstone of good design. When you don't intend something
to be re-used, you usually do not apply enough thought to its design. It
becomes a vicious circle, a catch-22: you can't re-use your old work since
it wasn't designed for it, so you start writing everything anew, and it
too
comes out non-re-usable because you don't have time nor the intent to do
it
right.

V

i agree with what you say and it was a good response

you have to know if your code is going to be re-used and have some idea
what for first. some classes are devloped by adding 100's of extra things
that might be used. you can only worry about the future so much.
of course if you have some idea then include extra functionality and put
extra work in the design.

the best thing you said compared to other on the topic is that you said 'do
what's easier' .

 

[Chris Croughton]

The rule of thumb is simple: do what's easier. Of course, some understand
that rule as "do what's easier NOW", and some as "do what's easier IN THE
LONG RUN". I guess it depends on your expectation of the lifetime of your
own work. I've written a few "one-timers" myself. They did their work as
needed when they were created, and were never designed for re-use. It is
quite possible that among those I've written some more than once to do the
same essential task. If the amount of such share is below one quarter of
all "one-timers", it's probably OK. If every time you when you sit down to
write a one-timer you suddenly, half-way through implementation, realise
that "you can swear you've done it before and probably more than once",
then you ought to keep those and document them well.

There are some things I've written a number of times, each time it gets
better (it's impossible to think of all possible uses at design time,
there's a point where "rewrite from scratch" is more effective than
trying to modify the original). There are some I've had to rewrite for
different languages, as well.

On the other hand there's some code I wrote 20 years ago which I'm still
using effectively unchanged (at that time C didn't even have function
prototypes or void, so they have grown proper modern interfaces since
then, but otherwise they are effectively unchanged).

It's one thing to reinvent the wheel that was invented by others. It's
totally different thing to reinvent your own wheel [all the time].

Yup. "Write once, use often" is a general principle I go by.

Another sentiment: when we were little, we were taught: repetition is the
mother of learning. The question is, are you still consider yourself
learning or is it really time to grow?

Heh. I hope I'm still learning, since Newton and Einstein were proud of
the fact that there was still so much else to know (with a finite
lifespan it is impossible to learn everything). But relearning the same
thing all the time is (a) boring and (b) a waste of time which could be
spent learning something new...

Re-use is the cornerstone of good design. When you don't intend something
to be re-used, you usually do not apply enough thought to its design. It
becomes a vicious circle, a catch-22: you can't re-use your old work since
it wasn't designed for it, so you start writing everything anew, and it too
comes out non-re-usable because you don't have time nor the intent to do it
right.

Or worse, you try to fit the old thing into the new functionality and
end up with something which is totally unmaintainable and clunky. At
which point it's a good idea to treat the original as a prototype and
say "Now that I know more about what it should have done and what I
really wanted I can write a proper specification".

Chris C

 

[Jesper Madsen]

do people prefer to design classes for the particular job or for a rangle
of tasks they might encounter now and in the future.
Yes.

i am doing some simple win32 apps and picking classes is simple, but
understanding others peoples logic isnt (that doesnt mean they are
wrong).

Understanding others is never simple.

i prefer designing classes for the currect job and making tangible
'things' classes , not overdoing it with loads of classes or
inheritance..
OK.

it seems easier to make classes and use previous work if possible. the
idea of making re-usable code to be used all the time is impractical

Well, that's not what the Standard Library designers thought...

Also using polymorphism,inheritance etc on old code to make it usabke for
now is an overhead of simplictity to read. Again simply designing classes
from scratch with previous work as a help seems easier to do.

'Seems' is probably the key word here.

are there any rules of thumb for this

The rule of thumb is simple: do what's easier. Of course, some understand
that rule as "do what's easier NOW", and some as "do what's easier IN THE
LONG RUN". I guess it depends on your expectation of the lifetime of your
own work. I've written a few "one-timers" myself. They did their work as
needed when they were created, and were never designed for re-use. It is
quite possible that among those I've written some more than once to do the
same essential task. If the amount of such share is below one quarter of
all "one-timers", it's probably OK. If every time you when you sit down
to
write a one-timer you suddenly, half-way through implementation, realise
that "you can swear you've done it before and probably more than once",
then you ought to keep those and document them well.

It's one thing to reinvent the wheel that was invented by others. It's
totally different thing to reinvent your own wheel [all the time].

Another sentiment: when we were little, we were taught: repetition is the
mother of learning. The question is, are you still consider yourself
learning or is it really time to grow?

Re-use is the cornerstone of good design. When you don't intend something
to be re-used, you usually do not apply enough thought to its design. It
becomes a vicious circle, a catch-22: you can't re-use your old work since
it wasn't designed for it, so you start writing everything anew, and it
too
comes out non-re-usable because you don't have time nor the intent to do
it
right.

V

i agree with what you say and it was a good response

you have to know if your code is going to be re-used and have some idea
what for first. some classes are devloped by adding 100's of extra things
that might be used. you can only worry about the future so much.
of course if you have some idea then include extra functionality and put
extra work in the design.

the best thing you said compared to other on the topic is that you said 'do
what's easier' .

I find reusing classes much simpler, when I am focused at not writing one
class, at solving a problem. And solving that problem by making a set of
classes, where each class has one responsibility. I might end up making them
part of a big class, or a couple of big classes(subsystem) at the end, but
all small factored out classes are usually reuseable..

Jesper