What comes first, the abstraction or the implementation?!

[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.

[Kristofer Gafvert]

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.

--
Regards,
Kristofer Gafvert
http://www.ilopia.com
"Mark Broadbent" <no************@no-spam-please.com> wrote in message
news:Or**************@tk2msftngp13.phx.gbl...

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.

[Mark Broadbent]

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.

"Kristofer Gafvert" <kg******@NEWSilopia.com> wrote in message
news:er**************@TK2MSFTNGP15.phx.gbl...

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.

--
Regards,
Kristofer Gafvert
http://www.ilopia.com
"Mark Broadbent" <no************@no-spam-please.com> wrote in message
news:Or**************@tk2msftngp13.phx.gbl...

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.

[Kristofer Gafvert]

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" <no************@no-spam-please.com> wrote in message
news:eH**************@TK2MSFTNGP10.phx.gbl...

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.

"Kristofer Gafvert" <kg******@NEWSilopia.com> wrote in message
news:er**************@TK2MSFTNGP15.phx.gbl...

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.

--
Regards,
Kristofer Gafvert
http://www.ilopia.com
"Mark Broadbent" <no************@no-spam-please.com> wrote in message
news:Or**************@tk2msftngp13.phx.gbl...

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.

[Mark Broadbent]

Thanks for your time Kristofer. I'll check out the url.

Cheers!

"Kristofer Gafvert" <kg******@NEWSilopia.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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" <no************@no-spam-please.com> wrote in message
news:eH**************@TK2MSFTNGP10.phx.gbl...

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.

"Kristofer Gafvert" <kg******@NEWSilopia.com> wrote in message
news:er**************@TK2MSFTNGP15.phx.gbl...

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.

--
Regards,
Kristofer Gafvert
http://www.ilopia.com
"Mark Broadbent" <no************@no-spam-please.com> wrote in message
news:Or**************@tk2msftngp13.phx.gbl...
> 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.
>
>

[Patty O'Dors]

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?
Brain power and imagination.
I
know that UML seems to be pretty popular at the moment, but I am yet to be
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.
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.

Br,

Mark.

[Mark Broadbent]

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.

"Patty O'Dors" <Pa********@discussions.microsoft.com> wrote in message
news:84**********************************@microsof t.com...

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?
Brain power and imagination.

I
know that UML seems to be pretty popular at the moment, but I am yet to

be
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.
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.

Br,

Mark.