Re: What comes first, the abstraction or the implementation?!
From: Kristofer Gafvert (kgafvert_at_NEWSilopia.com)
Date: 08/26/04
- Next message: Willy Denoyette [MVP]: "Re: NTLM Authentication"
- Previous message: Mystery Man: "Reading in parts of an XML DataSet"
- In reply to: Mark Broadbent: "Re: What comes first, the abstraction or the implementation?!"
- Next in thread: Mark Broadbent: "Re: What comes first, the abstraction or the implementation?!"
- Reply: Mark Broadbent: "Re: What comes first, the abstraction or the implementation?!"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 26 Aug 2004 14:48:01 +0200
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-spam-please@no-spam-please.com> wrote in message news:eHvSYT2iEHA.3008@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" <kgafvert@NEWSilopia.com> wrote in message > news:erXzp51iEHA.2688@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-spam-please@no-spam-please.com> wrote in message > > news:OrHKW90iEHA.1348@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. > > > > > > > > > > > >
- Next message: Willy Denoyette [MVP]: "Re: NTLM Authentication"
- Previous message: Mystery Man: "Reading in parts of an XML DataSet"
- In reply to: Mark Broadbent: "Re: What comes first, the abstraction or the implementation?!"
- Next in thread: Mark Broadbent: "Re: What comes first, the abstraction or the implementation?!"
- Reply: Mark Broadbent: "Re: What comes first, the abstraction or the implementation?!"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|