Need advices in choosing approach

[Leah]

I am a student and are required to build a website that provide
services (client-server).

I need advice in choosing approach or to be exact the methodology that
appropriate for such development. I am still new in design and
analysis, so any extra informations are greatly appreciated. Right
now, it is the initial phase, planning. So I need to decide which to
adapt. I had been read some of the open source projects code, and
majority seems to be adapting procedural programming, althought mostly
because they were build prior to PHP5, anyhow, is it a bright decision
to do it object-oriented way?

[The Natural Philosopher]

Leah wrote:

I am a student and are required to build a website that provide
services (client-server).

I need advice in choosing approach or to be exact the methodology that
appropriate for such development. I am still new in design and
analysis, so any extra informations are greatly appreciated. Right
now, it is the initial phase, planning. So I need to decide which to
adapt. I had been read some of the open source projects code, and
majority seems to be adapting procedural programming, althought mostly
because they were build prior to PHP5, anyhow, is it a bright decision
to do it object-oriented way?

Not necessarily.

With OOP you need to spend a lot of time analysing the problem before
coding to get the objects correctly defined.

In many cases this takes longer than writing procedural, and fixing it
slightly as issues arise.

Unless you are familiar with and like coding OOP, I would stay clear of
it. Unless again the problem falls naturally into objects..i.e. don't
force the problem to conform to one way of looking at it or another..see
which approach suits the problems - and the skill set of the programmers
you will be using.

[Jerry Stuckle]

Leah wrote:

I am a student and are required to build a website that provide
services (client-server).

I need advice in choosing approach or to be exact the methodology that
appropriate for such development. I am still new in design and
analysis, so any extra informations are greatly appreciated. Right
now, it is the initial phase, planning. So I need to decide which to
adapt. I had been read some of the open source projects code, and
majority seems to be adapting procedural programming, althought mostly
because they were build prior to PHP5, anyhow, is it a bright decision
to do it object-oriented way?

I think you're getting the cart ahead of the horse, here. You should
have your site planned first, to find out what you need. Then make a
selection of your methodology based on those needs. IOW, pick the right
tool for the job. Don't let the tool drive the job.

And contrary to other claims here, I've been doing OOAD for almost 20
years - before Booch, Rumbaugh and the rest became popular. And no, it
does not take more time to build an OO design than it takes to write
procedural code. In fact, I've found virtually every project where you
have experienced OO designers and programmers, the entire project from
design through final test takes less time and has fewer bugs than than
similar projects done procedurally.

But, of course, it takes time and energy to learn how to do OO properly
and become efficient at it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[The Natural Philosopher]

Jerry Stuckle wrote:

In fact, I've found virtually every project where you
have experienced OO designers and programmers, the entire project from
design through final test takes less time and has fewer bugs than than
similar projects done procedurally.

But, of course, it takes time and energy to learn how to do OO properly
and become efficient at it.

The two statements would appear to be mutually exclusive, Jerry.

[Leah]

On Dec 16, 7:25 pm, The Natural Philosopher <[e-mail]:

Unless you are familiar with and like coding OOP, I would stay clear of
it. Unless again the problem falls naturally into objects..i.e. don't
force the problem to conform to one way of looking at it or another..see
which approach suits the problems - and the skill set of the programmers
you will be using.

Sorry, I think I had hit the wrong reply method....previously replied
posts not appeared.

While I had some experienced with Java. But when I move and imagine
the web development, I couldn't get an idea how it should be *solved*
using OO. I don't know why, perhaps it just happened to just me, it
seems to be very abstract in such context, afterall it merely used to
generate chunk of HTML codes, unlike Java's AWT or Swing that
extensively use OO specifically inheritance to model the packages
framework, correct me if I am wrong.

Any suggestions?

[Leah]

On Dec 16, 9:27 pm, Jerry Stuckle <[e-mail]:

I think you're getting the cart ahead of the horse, here. You should
have your site planned first, to find out what you need. Then make a
selection of your methodology based on those needs. IOW, pick the right
tool for the job. Don't let the tool drive the job.

I am preparing proposal, and need to specify which methodology to use,
although OOAD is preferred since it s covered in the course module.
The problems is, as I replied The Natural Philosopher in 3rd post.

And contrary to other claims here, I've been doing OOAD for almost 20
years - before Booch, Rumbaugh and the rest became popular. And no, it
does not take more time to build an OO design than it takes to write
procedural code. In fact, I've found virtually every project where you
have experienced OO designers and programmers, the entire project from
design through final test takes less time and has fewer bugs than than
similar projects done procedurally.

On Dec 16, 7:25 pm, The Natural Philosopher <[e-mail]:

For this reason I tend to take a "mostly OO" approach. I put as much
code as possible in classes, but simple utility code that might be
needed anywhere in the package in unreleated classes may just end up
in standard functions.

While it seems to be logically fine to code using both procedural and
OO to mix around, but which methodology it is actually refering to?

[Steve]

"The Natural Philosopher" <[e-mail] in message
news:11****************@proxy00.news.clara.net...

Jerry Stuckle wrote:

> In fact, I've found virtually every project where you have experienced
OO designers and programmers, the entire project from design through
final test takes less time and has fewer bugs than than similar projects
done procedurally.

But, of course, it takes time and energy to learn how to do OO properly
and become efficient at it.

The two statements would appear to be mutually exclusive, Jerry.

it's a jerry-ism. you have to get into jerry's mind for him to make
sense...and that's a lot of work without much benefit. the rest of us just
see such a statement as having mutual exclusive conclusions where one of
them ("fewer bugs") is non sequitur to the claims they support ("does not
take more time to build an OO design"). like i said, just treat it as a
jerry-ism and leave it at that. otherwise, he'll just call *you* stupid and
troll you until the cows come home. it's something to do with insecurity i
think.

[The Natural Philosopher]

Steve wrote:

"The Natural Philosopher" <[e-mail] in message
news:11****************@proxy00.news.clara.net...

>Jerry Stuckle wrote:

>> In fact, I've found virtually every project where you have experienced
OO designers and programmers, the entire project from design through
final test takes less time and has fewer bugs than than similar projects
done procedurally.

But, of course, it takes time and energy to learn how to do OO properly
and become efficient at it.

The two statements would appear to be mutually exclusive, Jerry.

it's a jerry-ism. you have to get into jerry's mind for him to make
sense...and that's a lot of work without much benefit. the rest of us just
see such a statement as having mutual exclusive conclusions where one of
them ("fewer bugs") is non sequitur to the claims they support ("does not
take more time to build an OO design"). like i said, just treat it as a
jerry-ism and leave it at that. otherwise, he'll just call *you* stupid and
troll you until the cows come home.

Two can play at that game ;-)

it's something to do with insecurity i
think.

Something like that I expect.

>

[Steve]

"The Natural Philosopher" <[e-mail] in message
news:11****************@demeter.uk.clara.net...

Steve wrote:

>"The Natural Philosopher" <[e-mail] in message
news:11****************@proxy00.news.clara.net. ..

>>Jerry Stuckle wrote:
In fact, I've found virtually every project where you have experienced
OO designers and programmers, the entire project from design through
final test takes less time and has fewer bugs than than similar
projects done procedurally.

But, of course, it takes time and energy to learn how to do OO properly
and become efficient at it.

The two statements would appear to be mutually exclusive, Jerry.

it's a jerry-ism. you have to get into jerry's mind for him to make
sense...and that's a lot of work without much benefit. the rest of us
just see such a statement as having mutual exclusive conclusions where
one of them ("fewer bugs") is non sequitur to the claims they support
("does not take more time to build an OO design"). like i said, just
treat it as a jerry-ism and leave it at that. otherwise, he'll just call
*you* stupid and troll you until the cows come home.

Two can play at that game ;-)

he, he, he.

>it's something to do with insecurity i think.

Something like that I expect.

[Jerry Stuckle]

Leah wrote:

On Dec 16, 7:25 pm, The Natural Philosopher <[e-mail]:

>Unless you are familiar with and like coding OOP, I would stay clear of
it. Unless again the problem falls naturally into objects..i.e. don't
force the problem to conform to one way of looking at it or another..see
which approach suits the problems - and the skill set of the programmers
you will be using.

Sorry, I think I had hit the wrong reply method....previously replied
posts not appeared.

While I had some experienced with Java. But when I move and imagine
the web development, I couldn't get an idea how it should be *solved*
using OO. I don't know why, perhaps it just happened to just me, it
seems to be very abstract in such context, afterall it merely used to
generate chunk of HTML codes, unlike Java's AWT or Swing that
extensively use OO specifically inheritance to model the packages
framework, correct me if I am wrong.

Any suggestions?

I use OO all over the place. Anywhere from database implementation
displaying information.

For instance - one type of non-database related classes I use is for
forms. It generates the form (sans some formatting) and handles the
input posted back. Common routines look for required vs. non-required
fields, and parse data based on specified criteria.

It all works quite well, and removes a lot of the validation code
normally necessary.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

The Natural Philosopher wrote:

Jerry Stuckle wrote:

> In fact, I've found virtually every project where you have
experienced OO designers and programmers, the entire project from
design through final test takes less time and has fewer bugs than than
similar projects done procedurally.

But, of course, it takes time and energy to learn how to do OO
properly and become efficient at it.

The two statements would appear to be mutually exclusive, Jerry.

Not at all. Someone inexperienced in either will be slow in either.

And if you're experienced in procedural programming, you will generally
find programming in that can be faster for you. But when you take the
time to gain experience in OO programming, that's even faster.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Leah wrote:

On Dec 16, 9:27 pm, Jerry Stuckle <[e-mail]:

>I think you're getting the cart ahead of the horse, here. You should
have your site planned first, to find out what you need. Then make a
selection of your methodology based on those needs. IOW, pick the right
tool for the job. Don't let the tool drive the job.

I am preparing proposal, and need to specify which methodology to use,
although OOAD is preferred since it s covered in the course module.
The problems is, as I replied The Natural Philosopher in 3rd post.

Well, if this is for a course, then you need to be specifying what the
course expects. In the real world, you determine the requirements for
the project, and let those determine the methodology, language, etc. to
be used. Of course, this also assumes you have personnel equally
qualified in all methodologies and languages. But since that is almost
never the case, things like those have to be taken into consideration, also.

>And contrary to other claims here, I've been doing OOAD for almost 20
years - before Booch, Rumbaugh and the rest became popular. And no, it
does not take more time to build an OO design than it takes to write
procedural code. In fact, I've found virtually every project where you
have experienced OO designers and programmers, the entire project from
design through final test takes less time and has fewer bugs than than
similar projects done procedurally.

On Dec 16, 7:25 pm, The Natural Philosopher <[e-mail]:

>For this reason I tend to take a "mostly OO" approach. I put as much
code as possible in classes, but simple utility code that might be
needed anywhere in the package in unreleated classes may just end up
in standard functions.

While it seems to be logically fine to code using both procedural and
OO to mix around, but which methodology it is actually refering to?

I prefer an OO approach. I can do things more quickly in OO than most
procedural programmers. And the larger a project grows, the more I find
I reuse OO code. OTOH, I see comparatively little reuse of procedural
code (unless you count copy/paste).
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Leah]

On Dec 17, 10:34 am, Jerry Stuckle <[e-mail]:

>

On Dec 16, 7:25 pm, The Natural Philosopher <[e-mail]:

For this reason I tend to take a "mostly OO" approach. I put as much
code as possible in classes, but simple utility code that might be
needed anywhere in the package in unreleated classes may just end up
in standard functions.

While it seems to be logically fine to code using both procedural and
OO to mix around, but which methodology it is actually refering to?

I prefer an OO approach. I can do things more quickly in OO than most
procedural programmers. And the larger a project grows, the more I find
I reuse OO code. OTOH, I see comparatively little reuse of procedural
code (unless you count copy/paste).

Thanks for the great input.

Basically, to sum up, I supposed that PHP is a hybrid language, just
like C++, you can code in procedural and revert back to OO whenever
you like, of course not considering the code maintenance or reuse.
Will that be a serious problem in PHP just like 'do C++
procedurally' ?

Sorry if this question sound stupid.

[Jerry Stuckle]

Leah wrote:

On Dec 17, 10:34 am, Jerry Stuckle <[e-mail]:

>>On Dec 16, 7:25 pm, The Natural Philosopher <[e-mail]:
For this reason I tend to take a "mostly OO" approach. I put as much
code as possible in classes, but simple utility code that might be
needed anywhere in the package in unreleated classes may just end up
in standard functions.
While it seems to be logically fine to code using both procedural and
OO to mix around, but which methodology it is actually refering to?

I prefer an OO approach. I can do things more quickly in OO than most
procedural programmers. And the larger a project grows, the more I find
I reuse OO code. OTOH, I see comparatively little reuse of procedural
code (unless you count copy/paste).

Thanks for the great input.

Basically, to sum up, I supposed that PHP is a hybrid language, just
like C++, you can code in procedural and revert back to OO whenever
you like, of course not considering the code maintenance or reuse.
Will that be a serious problem in PHP just like 'do C++
procedurally' ?

Sorry if this question sound stupid.

No, not at all stupid.

Yes, PHP is a hybrid language - it started out as a procedural language,
but is acquiring more and more OO features with each release.

And yes, you can mix the two, and you need to to a certain extent. For
instance, you need some code which is in no function or class just to
execute on your page. So while you can have a purely procedural system,
you can't have a purely OO one.

I strive to have as much OO code as is applicable, but I don't try to
force everything into an OO mold.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[The Natural Philosopher]

Leah wrote:

On Dec 17, 10:34 am, Jerry Stuckle <[e-mail]:

>>On Dec 16, 7:25 pm, The Natural Philosopher <[e-mail]:
For this reason I tend to take a "mostly OO" approach. I put as much
code as possible in classes, but simple utility code that might be
needed anywhere in the package in unreleated classes may just end up
in standard functions.
While it seems to be logically fine to code using both procedural and
OO to mix around, but which methodology it is actually refering to?

I prefer an OO approach. I can do things more quickly in OO than most
procedural programmers. And the larger a project grows, the more I find
I reuse OO code. OTOH, I see comparatively little reuse of procedural
code (unless you count copy/paste).

Thanks for the great input.

Basically, to sum up, I supposed that PHP is a hybrid language, just
like C++, you can code in procedural and revert back to OO whenever
you like, of course not considering the code maintenance or reuse.
Will that be a serious problem in PHP just like 'do C++
procedurally' ?

Sorry if this question sound stupid.

Not at all.

I use it entirely procedurally. Simply because that's the way I learnt
programming and I don't have the time in smaller projects to do the
necessary design work for OOP.

OOP comes into its own with large projects where project specification
is split off from the actual coding.

To just put together a few websites its not really that necessary.