What comes first, the abstraction or the implementation?!

  • Thread starter Thread starter Mark Broadbent
  • Start date Start date
M

Mark Broadbent

this might sound like an obvious question but I have found that usually
these two evolve at the same time.
One of the biggest reasons for creating the abstraction in the first place
(in my opinion) is to create a reusable framework that can be applied to
similar projects. However I have found that if an abstraction is created
first during the development phase, when the implementation is occurring,
the functionality or intended behaviour of the abstraction is not always the
best way of doing something. This leads to changes in both the implementing
class and the abstract one.

e.g.
public abstract class LotteryPredictor
{
public abstract bool WinLottery();
}
//You then realise in your implementation that just knowing the result of
WinLottery (true or false) is better indicated via a return of an int 0
=fail zero balls correct, 1= fail one ball correct, ... 6= won all balls
correct. Therefore the abstraction would be public abstract int
WinLottery();

I know the above is not the greatest example to demonstrate what I am saying
but it gives an idea.

So onto the questions.....
If the functionality of the implementation moves away from the abstraction,
does this mean that the abstraction was poorly designed in the first place
OR is it completely valid to go back to the abstraction and fine tune it
(obviously bearing in mind that only one class currently implements it)?

As a side note, what do people find to be the best design methodology? I
know that UML seems to be pretty popular at the moment, but I am yet to be
convinced how useful it is -it just seems to overcomplicate the design.

Br,

Mark.
 
Hello,

I will keep it to your example.

I would assume that WinLottery() would return true if you won, and false if
you lost. But a method called NumberOfCorrectBalls(), would return the
number of correct balls.

You changed the meaning of the method, because it was not what you wanted
_in the current project_. But what about other projects? What if you need a
method that only returns true or false, because you do not care how many
correct balls there were, you only want to know if there was a win or lose?

What i mean is that you did not found out what you really needed, before you
started with the implementation.

Of course you can go back and re-design, but usually, this means that you
did a poor design in the first place. This usually also means that the
development time will be extended, which costs money. It is better to
completely understand what you want, and need, before you start writing the
code.
 
Thanks for your response.
I agree that the meaning was changed (and therefore the original design was
therefore probably poorly designed).
But I wonder how often this happens in the real world especially when
sometimes we are striving towards a goal that we are not entirely sure about
what it is and what it might become. This is probably a design failing on my
part but I wonder if it is actually the reality of design?
I am currently working on a pet project that it's most basic level will
effectively store data. I have a loose design on it's mechanics and the way
it will be able to work *but* cannot finalise a design because I keep
changing my mind as to it's exact workings and how to optimise them. Until I
create a prototype I don't think that I will have a strong idea as to how
this program should really (or best) work ...and what it should be able to
do.

Br,

Mark.
 
I suppose it depends on the type of project, and the experience of the
development people.

If the customer cannot decide what they need, or don't know yet, there will
be alot of changes. It is possible that the development will be very close
to the customer, and the application will be written so that it can be used
by the customer during development (and therefore, the design of the code is
not high-priority, as long as the customer gets business value).

If the development team is facing something new, they have never dealt with
before, there will also be some changes, until they have decided what is
best. It is also possible that they need to create prototypes, or "Spike
Solutions" [1].

It is not unusual that a development team uses prototyping.

So, of course it happens that you need to do something that you later throws
away. It probably depends a bit on the experience you have. But, you also
need to realize that writing code that you later must throw away, will
extend the development time. You also must realize that there is a need to
spend time on the design, and not just re-design everything during the time
you write code. Because that often results in a poorly designed application
(and the development time was probably longer as well).

I think that you should also consider if "optimizing" the code is important
for this application. Is it really necessary that it takes 0.04 seconds less
to store the data? Because that is probably the time frame we are talking
about here. Is it necessary to have a good framework, so that you can extend
the application? Will you ever extend the application?

Sometimes, it is best to just write the code, without thinking too much
about the design, because that just complicates the project, and too much
time is spent on finding the best design ever. And if it is not necessary to
have the best design, and the fastest application, why spend time on that?
Maybe the customer needs the application now, and not a few months later,
and they don't care if the application could be 0.04 seconds faster? (This
is also a bit of XP thinking, "use the simpliest solution possible, without
complicating anything").


[1] XP terminology, http://www.extremeprogramming.org/rules/spike.html
PS: XP should only be used in small (or very small) projects.
 
Thanks for your time Kristofer. I'll check out the url.

Cheers!

Kristofer Gafvert said:
I suppose it depends on the type of project, and the experience of the
development people.

If the customer cannot decide what they need, or don't know yet, there will
be alot of changes. It is possible that the development will be very close
to the customer, and the application will be written so that it can be used
by the customer during development (and therefore, the design of the code is
not high-priority, as long as the customer gets business value).

If the development team is facing something new, they have never dealt with
before, there will also be some changes, until they have decided what is
best. It is also possible that they need to create prototypes, or "Spike
Solutions" [1].

It is not unusual that a development team uses prototyping.

So, of course it happens that you need to do something that you later throws
away. It probably depends a bit on the experience you have. But, you also
need to realize that writing code that you later must throw away, will
extend the development time. You also must realize that there is a need to
spend time on the design, and not just re-design everything during the time
you write code. Because that often results in a poorly designed application
(and the development time was probably longer as well).

I think that you should also consider if "optimizing" the code is important
for this application. Is it really necessary that it takes 0.04 seconds less
to store the data? Because that is probably the time frame we are talking
about here. Is it necessary to have a good framework, so that you can extend
the application? Will you ever extend the application?

Sometimes, it is best to just write the code, without thinking too much
about the design, because that just complicates the project, and too much
time is spent on finding the best design ever. And if it is not necessary to
have the best design, and the fastest application, why spend time on that?
Maybe the customer needs the application now, and not a few months later,
and they don't care if the application could be 0.04 seconds faster? (This
is also a bit of XP thinking, "use the simpliest solution possible, without
complicating anything").


[1] XP terminology, http://www.extremeprogramming.org/rules/spike.html
PS: XP should only be used in small (or very small) projects.

--
Regards,
Kristofer Gafvert
http://www.ilopia.com


Mark Broadbent said:
Thanks for your response.
I agree that the meaning was changed (and therefore the original design was
therefore probably poorly designed).
But I wonder how often this happens in the real world especially when
sometimes we are striving towards a goal that we are not entirely sure about
what it is and what it might become. This is probably a design failing
Click to expand...
on
my
part but I wonder if it is actually the reality of design?
I am currently working on a pet project that it's most basic level will
effectively store data. I have a loose design on it's mechanics and the way
it will be able to work *but* cannot finalise a design because I keep
changing my mind as to it's exact workings and how to optimise them.
Click to expand...
Until
I
create a prototype I don't think that I will have a strong idea as to how
this program should really (or best) work ...and what it should be able to
do.

Br,

Mark.

false
if need before
you writing
the
Click to expand...
applied
to result
of
Click to expand...
int
0
Click to expand...
tune
it
Click to expand...
methodology?
I to
Click to expand...
Click to expand...
 
instead, why not just create "code" and if it needs changing, change it. The
fact that you haven't got an interface doesn't prevent it from being generic.
//You then realise in your implementation that just knowing the result of
WinLottery (true or false) is better indicated via a return of an int 0
=fail zero balls correct, 1= fail one ball correct, ... 6= won all balls
correct. Therefore the abstraction would be public abstract int
WinLottery();

I know the above is not the greatest example to demonstrate what I am saying
but it gives an idea.

So onto the questions.....
If the functionality of the implementation moves away from the abstraction,
does this mean that the abstraction was poorly designed in the first place
OR is it completely valid to go back to the abstraction and fine tune it
(obviously bearing in mind that only one class currently implements it)?

As a side note, what do people find to be the best design methodology?
Click to expand...

Brain power and imagination.
I
know that UML seems to be pretty popular at the moment, but I am yet to be
Click to expand...

UML is a flowery, good-for-nothing technology for posh toffs in poncey wine
bars.


convinced how useful it is -it just seems to overcomplicate the design.
Click to expand...

It's just doing extra work for no gain - you could go and dig a great whole
in a field and fill it in again - and yes, it would be work - but it wouldn't
get you very far.
 
I get the impression you are a no nonsense kinda gal :)

Must admit that I sort of agree with your sentiments - hard bit is trying to
convince the posh toff employers or those that seize buzz word technologies
and push them on others without really seeing whether they are a good fit
for the situation in hand.

Thx for your comments.

Br,

Mark.
 
Back
Top