electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Articles  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links  |  Store
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » DIY Hardware and Software » Developers' Corner
rewrite procedural code as object oriented
Post new topic   Reply to topic Moderators: DrJustice
Page 1 of 1 [8 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
windchill



Joined: Jan 07, 2005
Posts: 88
Location: london uk
G2 patch files: 1

PostPosted: Tue Jan 10, 2006 11:35 am    Post subject: rewrite procedural code as object oriented Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
mosc
Site Admin


Joined: Jan 31, 2003
Posts: 17618
Location: Allentown, PA
Audio files: 125
G2 patch files: 60

PostPosted: Tue Jan 10, 2006 12:02 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail Visit poster's website AIM Address
windchill



Joined: Jan 07, 2005
Posts: 88
Location: london uk
G2 patch files: 1

PostPosted: Tue Jan 10, 2006 12:17 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
mosc
Site Admin


Joined: Jan 31, 2003
Posts: 17618
Location: Allentown, PA
Audio files: 125
G2 patch files: 60

PostPosted: Tue Jan 10, 2006 12:23 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail Visit poster's website AIM Address
Blue Hell
Site Admin


Joined: Apr 03, 2004
Posts: 20620
Location: The Netherlands, Enschede
Audio files: 148
G2 patch files: 318

PostPosted: Tue Jan 10, 2006 1:18 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
Back to top
View user's profile Send private message Visit poster's website
mi_dach



Joined: Dec 17, 2005
Posts: 133
Location: Sweden

PostPosted: Thu Jan 19, 2006 4:24 am    Post subject: Re: rewrite procedural code as object oriented Reply with quote  Mark this post and the followings unread

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 Smile
Back to top
View user's profile Send private message Visit poster's website
BobTheDog



Joined: Feb 28, 2005
Posts: 3861
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Tue Jan 31, 2006 4:20 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
Yorky



Joined: Feb 14, 2005
Posts: 244
Location: Boston, UK

PostPosted: Tue Sep 26, 2006 1:28 pm    Post subject: Reply with quote  Mark this post and the followings unread

"A good Cobol programmer can write Cobol in any language" (TM) Rolling Eyes
_________________
Lots of new albums at Ambientlive
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Moderators: DrJustice
Page 1 of 1 [8 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » Developers' Corner
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
e-m mkii

Please support our site. If you click through and buy from
our affiliate partners, we earn a small commission.


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use