| Author |
Message |
windchill
Joined: Jan 07, 2005
Posts: 90
Location: london uk
G2 patch files: 1
|
 Posted: Tue Jan 10, 2006 11:35 am Post subject:
rewrite procedural code as object oriented |
  |
|
My job: convert 10,000 lines of perl code - all old style procedural code using subroutines into object-oriented java.
It's hard to know where to begin - and I'm interested in ideas.
Basically messages come in, get parsed, change various fields in the database and a response is sent back out.
Frankly it seems to be a perfect job for procedural code - but my orders are my orders!
Any advice? |
|
|
Back to top
|
|
 |
mosc
Site Admin
Joined: Jan 31, 2003
Posts: 18238
Location: Durham, NC
Audio files: 223
G2 patch files: 60
|
| Posted: Tue Jan 10, 2006 12:02 pm Post subject:
|
|
|
Sounds like very strange orders? What is the reason to convert the code in the first place? Does the order giver want certain objects defined so that they can be reused elsewhere, or does he just have a case of the Object Oriented Programming religion?
I had a project like that once. I wrote a huge application in shell language (bourne shell actually). My boss, who wasn't a programmer, had me rewrite the entire application in C because that was what he thougth real programs should be written in. It was a huge job and there was absolutely no payoff in the end. The program still did the same thing. I learned C, though so it wasn't all bad.
_________________
--Howard
my music and other stuff |
|
|
Back to top
|
|
|
windchill
Joined: Jan 07, 2005
Posts: 90
Location: london uk
G2 patch files: 1
|
| Posted: Tue Jan 10, 2006 12:17 pm Post subject:
|
|
|
There are some good justifications for undertaking this task. One is related to integration with other existing technologies and another to a future move to massively distributed processing - and here Java application servers are the norm (unless you want to use .net). One of the problems with Java is it forces an OOP paradigm onto the developer, so you have to use OO design whether you want to or not, and regardless of the nature of the task.
Sadly it's also about sales - semi tech-literate clients often have certain expectations (right or wrong) about what to look for.
I actually relish the task. But the design philosophies are radically different and it's quite disturbing to look at a list of 300 algorithm-based subroutines and wonder how they will map onto data-centric objects! |
|
|
Back to top
|
|
|
mosc
Site Admin
Joined: Jan 31, 2003
Posts: 18238
Location: Durham, NC
Audio files: 223
G2 patch files: 60
|
| Posted: Tue Jan 10, 2006 12:23 pm Post subject:
|
|
|
Interesting. Sorta similar in some ways to my project. I'm not a Java head, so I won't be much help. If you relish doing it, then you are lucky and I'm sure whatever you do will be a positive experience and the code will be great too.
I've never been too excited by Java because it always seems to have performance and compatibility problems. Maybe these have been sorted out by now. Best of luck...
_________________
--Howard
my music and other stuff |
|
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004
Posts: 24396
Location: The Netherlands, Enschede
Audio files: 296
G2 patch files: 320
|
| Posted: Tue Jan 10, 2006 1:18 pm Post subject:
|
|
|
Maybe pick up a book about software design patterns and try to find some patterns that match the task(s).
I occasionally use Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (Addison-Wesley ISBN 0-201-63361-2). Sometimes it is a good source for ideas, I'm sure there are more books (or web topics) about the subject though.
_________________
Jan
also .. could someone please turn down the thermostat a bit.
 |
|
|
Back to top
|
|
|
mi_dach
Joined: Dec 17, 2005
Posts: 133
Location: Sweden
|
| Posted: Thu Jan 19, 2006 4:24 am Post subject:
Re: rewrite procedural code as object oriented |
|
|
| windchill wrote: | My job: convert 10,000 lines of perl code - all old style procedural code using subroutines into object-oriented java.
It's hard to know where to begin - and I'm interested in ideas.
Basically messages come in, get parsed, change various fields in the database and a response is sent back out.
Frankly it seems to be a perfect job for procedural code - but my orders are my orders!
Any advice? |
If 10,000 lines of perl code is working, I'd strongly recommend not touching it. That said however, there's often things we simply need to accept. So..
The parser is an ideal candidate for OOP if it is anything more than a trivial extract-the-string exercise. Nearly all languages getting parsed fit into a tree structure. Look into BNF grammars, and general parser construction (you mmight want to look at OO SQL or XML parsers, depending on whats being parsed). I'd take a guess that your current perl parser is doing things in an OOP way, or else its a string compare affair (likely to be an untouchable mess). Either way, OOing the parser will probably keep you busy, and you can use nice fancy words like Expandable, Flexible, Reusable, Readable and Maintainable to impress your manager/boss.
You mention 'data-centric' objects. Make these into your Objects, and implement a bunch of member functions that'll access the database and keep the object updated. You can have some kind of higher level factory objects dispensing these or otherwise manipulating them, if you can represent groups of data or tasks in an object just above the database level, you can work upwards and add a few more OOPy things to manipulate these.
For the rest of the project, I dunno, you could represent multiple database queries/returns as an object, some procedures can be usefully represented as objects, but beyobnd this it sounds very much like a solution looking for a problem. Look for groups of tasks, or tasks that get called with sub-tasks (I dont mean functions, thats an implementation issue, i mean 'tasks' as in something the program is required to do). A clumsy approach is to describe in a bit more detail what the project does, in english, then extract all the nouns and use those as objects. Take a look at the verbs too. The Design Patterns book (and the patterns are available in some detail online aswell) is a good place to get ideas on implementing procedures and ways of doing stuff (the verbs) as objects.
As a last resort, invent objects, give them some kind of Do() function or an Update() of some kind and drop lots of your procedural code in there.
Hope this is of use  |
|
|
Back to top
|
|
|
BobTheDog
Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15
|
| Posted: Tue Jan 31, 2006 4:20 pm Post subject:
|
|
|
The following may be of interest to you:
http://ebb.org/bkuhn/writings/technical/perljvm-new.html
Also at a simple level you do not need to convert to an OO aproach, java does not force you to do this.
Just define a class and convert your perl procesures to methods within this one class.
Or how about the following basic classes.
Listener
Dispatcher
Parser
Class for each message
Class for each ack
Without more details it is hard to guess at what you need.
One important thing to bear in mind is that OO design is totally different to procedural design. If you come up with a load of classes that do not use inheritence you are probably going down the wrong path, think abstract DT/classes as a basis for the system, this will allow you for example to treat all messages at a high level (polymorphism).
Hope this is of some help
Andy |
|
|
Back to top
|
|
|
Yorky
Joined: Feb 14, 2005
Posts: 244
Location: Boston, UK
|
|
|
Back to top
|
|
|
|
Forum index » DIY Hardware and Software » Developers' Corner
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
