|
Are you talking about actual "software engineering methods" ie, a way of getting from an idea to some software (Like waterfall or iterative). The whole show from conception, through requriements, design, prototyping, testing, the lot...
or
Do you mean use OO design and programming techniques / ideaologies? Which only really apply to design and development?
"Methods" like waterfall etc are sort of independent of whether you use a procedural or OO programming language. So you can use the waterfall / iterative / whatever method with OO or procedural. Some of the more recent methods evolved after OO, so are slightly more Data orientated, but a good method will give you the freedom to implement your final solution using whichever languages and techniques you see fit.
I.E. Your requirements and specifications should outline the problem, without stepping on the toes of the design. For example by using OO terminology to describe a problem (classes objects inheritance), when you might actually need a small fast procedural solution (or vice versa, taling about functions / actions when you might need an OO solution).
It's a classic university essay topic so the net should be full of good arguments on the subject.
PS Mods - Should this thread be moved out of General discussion to the software development forums?
They told me I was gullible ... and I believed them.
|