> >For GUI programming, I think a "beautiful" object design is
> >exceptionally important. But once you leave the GUI space, you've
> >left the area where "beautiful" object designs add much benefit. Most
> >of us programmers are relagated to things that are less beautiful, but
> >rather functional. Functional things require good algorithms. Things
> >with bad algorithms just become messy, and non functional after a
> >period of time. (Let me note that I am not speaking of
> >"function/procedural" languages, just the task it must accomplish:
> >pretty vs. do the job)
>
> Now come on. That's a bit heavy. OO is just as useful server-side as
> client-side.
Agreed Gunther, I tried to soften that with my later comment because I
realized it was overboard/not exactly true. I mean to say OO as a
replacement for decent algorithm training makes some sense at the GUI
level (Yikes did I just open myself for flames). What I really mean
is that the only place that *I* see where OO training is more
important than algorithm training is in GUI design. I'm arguing against
the precendents as I see them in our school system. I would say that
we need more focus on algorithms starting with procedural langauges,
and then moving to design patterns with OO. Not... Oh, here is some
design patterns, what algorithms? Nah, forget about that, that's only
for programming in c, who does that anymore? (Uhm, most everyone, but
that's the position that seemed quite apparent to me at the University
level YMMV)
> I think I've benefited just as much from server side OO as client-side.
> There are also a load of design patterns which are dedicated to processing
> data over networks or distributed systems. eg see CORBA Design Patterns by
> Malveau and Mowbray. While the title of the book says CORBA, at least 3 of
> the design patterns in there are applicable to mod_perl, EJB, Servlets, and
> DCOM communications.
We really all have..., the Apache request object comes to mind in
mod_perl.
> This one isn't detailed in that book, but even Session is a "documented"
> design pattern with an OO interface and that's certainly server-side.
>
> Now, while you can accomplish making an object interface with functional
> programming, (eg a web server could be thought of as an object, with an
> HTTP get method and post method), the plain fact is that it is a lot
> simpler to maintain if your language supports your interface.
This is the sort of approach that Java takes. Personally... I find it
to be cleaner. However, I also find it unbearable. You see
personally I prefer to program the main application in c, with c++
classes that interact for important functions, GUI, Database access,
Storage, etc. You develope things that should be "objects" with
clearly well laid out algorithms for there various functions. However
for program logic I've always found object languages to be..., well,
sort of silly. So I use a c program to wrap all these things up.
Where perl comes into play is when I want something done fast. I use
the same sort of approach though. The "application" are sets of Perl
objects/modules. The program logic are just simple sets of scripts that
interact with these Modules/objects. Set the properties on the
objects and it gives answers that compute into the program logic flow.
Generally seperation between logical flow of an application is best
done in a procedural language in my experience. You define a series
of objects which can be re-used a billion times in your application
flow. So say for instance your building an accounting package. You
have all sorts of reports, each of them are represented by a "class
hierarchy", then you use a quick and dirty perl script to create the
right type of object/module, set it's properties, and display it.
This way you could include reports in any other part of your program
set. Oh well..., this is just the way I like to do things.
> >My point is simple. Object orientation is not a replacement for good
> >algorithms. It's supplemental to good algorithms, and indeed
> >sometimes crufty/beautiful Object interfaces can get in the way of good
> >algorithms. (OO interfaces sometimes make Nazi designers out of the
> >best of us..., we allow our sense of design to get in the way of our
> >sense of algorithms.)
>
> That may be true. But it doesn't obviate the usefulness of OO on the server.
Clearly you are correct. I should have been more clear.
> But by the same token, you may as well say forget procedural programming
> because it gets in the way of optimizations involving globals stuck in
> machine code registers.
That is a good point, especially with the poor architecture most of us
are working on (x86)..., now if we had more alpha's lying around... :)
>
> There are a couple things about server side programming that I would agree
> with:
>
> Algorithms tend not to change so often because they are contract. GUIs
> change ALL the time. Therefore, maintenance is not so much of a problem on
> servers as it is on GUIs which means that the maintenance benefits that OO
> affords is less.
>
> But it isn't non existent and in fact OO helps quite a bit even on the
> server side. Arguably, the more complex a server-side system becomes with
> more developers, the more the server side system needs to be clean and
> strongly interfaced... and OO helps support that quite a bit because an OO
> system contains syntactic glue that supports strong interfacing.
It helps out trememdously. I was just being a total pain...,
I was arguing more on a "what I think is wrong with our school system"
sort of thing. In terms of what I do in the field. I make modules
that become "objects" of a certain report, or wrap up some more
complex logic in it. Then the application is just simply relagated to
"flow control" between the various objects. Now this is what I do in
perl... I tend to hand more over to the procedural language when
writing stuff in c/c++... mostly because mixing the two can be really
messy sometimes. (Not when writing an app from scratch, but
supporting a legacy c app. Including c++ in there makes things
nutty.)
Thanks Gunther,
Shane.
