Legacy vs Opp 
Author Message
 Legacy vs Opp

I'm trying to make a decision whether to rework a large legacy program using
all OPP.

I'm having a hard time seeing what I would gain since the code is unique to
the program and unlikely to be ported elsewhere?

I currently use global UDTs, with each module self contained (few globals,
mostly private functions).  I do use two independent classes in the program.

By moving the UDT's to a class  (the UDTs  would be a class of just
properties) and moving each module to a new class (the functions  would now
be methods).

As I see it all I would gain is more code (Let/Get properties vs direct
assignment using UDT) and the need to include the UDT class within each
other class (formerly module) in order to use the UDT class properties.

Anyone see it different (a benefit)?

Thanks
David



Wed, 17 Aug 2011 23:09:23 GMT  
 Legacy vs Opp


Quote:
> I'm trying to make a decision whether to rework a large legacy program using
> all OPP.

> I'm having a hard time seeing what I would gain since the code is unique to
> the program and unlikely to be ported elsewhere?

> I currently use global UDTs, with each module self contained (few globals,
> mostly private functions).  I do use two independent classes in the program.

> By moving the UDT's to a class  (the UDTs  would be a class of just
> properties) and moving each module to a new class (the functions  would now
> be methods).

> As I see it all I would gain is more code (Let/Get properties vs direct
> assignment using UDT) and the need to include the UDT class within each
> other class (formerly module) in order to use the UDT class properties.

> Anyone see it different (a benefit)?

Just a couple comments from the hip....

OOP, OOD, OOA, however you want to look at it, is not the end-all
best fit in every situation.  In places where you have a lot of autonimous
little objects (employees, documents, tasks, etc) it usually helps to
have them encased in their own little compartments.  But, if your
program is more oriented toward work flow, or procedural steps,
event programming works well.

I am a big fan of organizing modules by functionality.  If that means
classes, then so be it, but it is not always so.

What I did want to mention was that moving a UDT to a class adds
the ability to validate input.  All your Let property events can test for
boundries and act accordingly.  That may (or may not) relieve your
other code from such concerns.  IF your UDT has to be validated out
in your main code, then moving to a class would reduce redundant
testing.  If not, then you don't gain so much in that area.  If your UDT
is used in formatted output, where your main code is often formatting
UDT values for display, then again, providing a class function to
supply fomating standardizes the process in addition to reducing
redundancy in your main code.

But, I'm with you.  If you find there is not going to be major advantages
in code maintenance, code size, or extensibility, why switch now?

LFS



Wed, 17 Aug 2011 23:43:54 GMT  
 Legacy vs Opp

Quote:
> I'm trying to make a decision whether to rework a large legacy program
> using all OPP.

> I'm having a hard time seeing what I would gain since the code is unique
> to the program and unlikely to be ported elsewhere?

> I currently use global UDTs, with each module self contained (few globals,
> mostly private functions).  I do use two independent classes in the
> program.

> By moving the UDT's to a class  (the UDTs  would be a class of just
> properties) and moving each module to a new class (the functions  would
> now be methods).

> As I see it all I would gain is more code (Let/Get properties vs direct
> assignment using UDT) and the need to include the UDT class within each
> other class (formerly module) in order to use the UDT class properties.

> Anyone see it different (a benefit)?

> Thanks
> David

What you are talking about is not "OOP" so much as it is just writing in VB6
(instead of VB3).  The primary advantages are modularity and organization in
my view.

Modularity:

If you have to write a number of programs that operate on the same sort of
data conglomerations (i.e. like a UDT), a Class makes it easy to just drop
the .CLS module into each Project to use it.  You can also shared a compiled
DLL among them to save on duplicated code and "hide" implementation details
that other programmers don't need to know about such Classes.

Even for a single program it becomes much easier to make changes since the
logic is together in one place and right near the data.

Organization:

You can use a Class to keep the associated logic next to the data
definitions rather than scattered in inline code or static .BAS modules.
This enhances modularity as described above as well.

More Code?

If you use a UDT everything is {*filter*} to code that works with it.  You can
create Classes in the same vein.  There is no benefit to explicitly writing
Let/Set/Get procedures if you have no need to restict or modify access to
Properties.  The compiler generates the code for you.

It's a rare day when I use a UDT anymore.  They are still useful, but mainly
for simulating a struct for API calls or using old-style random record I/O.
A Class can be much more  productive for most other uses.



Thu, 18 Aug 2011 02:47:02 GMT  
 Legacy vs Opp
Thanks for input Mr. Serflaten and Mr Riemersma.

Nice to get someones elses opinion on the subject.

Think I've decided to stay with the legacy.  Maybe some date
in distant future if I decide to go with NET or WHATEVER will do conversion
to classes at the same time.  Had thought the movement to VB5/6 classes
might bridge the gap when/if I decided to go with the latest "new" code
approach.

Other than making money for MS, not sold on NET as a replacement for VB5/6.
IMHO Net is basically another programming language like the 50+ others out
there (legacy and OPP).

Have a nice day.
David


Quote:


>> I'm trying to make a decision whether to rework a large legacy program
>> using all OPP.

>> I'm having a hard time seeing what I would gain since the code is unique
>> to the program and unlikely to be ported elsewhere?

>> I currently use global UDTs, with each module self contained (few
>> globals, mostly private functions).  I do use two independent classes in
>> the program.

>> By moving the UDT's to a class  (the UDTs  would be a class of just
>> properties) and moving each module to a new class (the functions  would
>> now be methods).

>> As I see it all I would gain is more code (Let/Get properties vs direct
>> assignment using UDT) and the need to include the UDT class within each
>> other class (formerly module) in order to use the UDT class properties.

>> Anyone see it different (a benefit)?

>> Thanks
>> David

> What you are talking about is not "OOP" so much as it is just writing in
> VB6 (instead of VB3).  The primary advantages are modularity and
> organization in my view.

> Modularity:

> If you have to write a number of programs that operate on the same sort of
> data conglomerations (i.e. like a UDT), a Class makes it easy to just drop
> the .CLS module into each Project to use it.  You can also shared a
> compiled DLL among them to save on duplicated code and "hide"
> implementation details that other programmers don't need to know about
> such Classes.

> Even for a single program it becomes much easier to make changes since the
> logic is together in one place and right near the data.

> Organization:

> You can use a Class to keep the associated logic next to the data
> definitions rather than scattered in inline code or static .BAS modules.
> This enhances modularity as described above as well.

> More Code?

> If you use a UDT everything is {*filter*} to code that works with it.  You can
> create Classes in the same vein.  There is no benefit to explicitly
> writing Let/Set/Get procedures if you have no need to restict or modify
> access to Properties.  The compiler generates the code for you.

> It's a rare day when I use a UDT anymore.  They are still useful, but
> mainly for simulating a struct for API calls or using old-style random
> record I/O. A Class can be much more  productive for most other uses.



Thu, 18 Aug 2011 06:26:28 GMT  
 Legacy vs Opp

Quote:
> I'm trying to make a decision whether to rework a large legacy program
> using all OPP.

OPP?

Object
Poriented
Programming
?



Sat, 20 Aug 2011 23:49:40 GMT  
 Legacy vs Opp


Quote:


>> I'm trying to make a decision whether to rework a large legacy program
>> using all OPP.

> OPP?

> Object
> Poriented
> Programming
> ?

http://en.wikipedia.org/wiki/O.P.P._(song)

Obviously the OP is going to rework the program using stolen code <g>



Sat, 20 Aug 2011 23:54:46 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. JOB OPP: Hebrew speaker expert Word user

2. VISUAL BASIC/ Career Position/ Excep Opp/ Va-low cost area

3. job opp.

4. VISUAL BASIC/ Career Position/ Excep Opp/ Rich Va

5. Is VB a True OPP Lang

6. Is it OPP?

7. Job Opp. SQL, VB in Virginia

8. VISUAL BASIC/ Career Position/ Excep Opp/ Rich Va

9. VB Job Opp in Marlborough, MA.

10. VB Job Opp in Marlborough, MA.

11. Newbie confused: VB6 vs VB.Net vs VBScript vs VBA

12. Access vs SQL Server vs Sybase vs Oracle

 

 
Powered by phpBB® Forum Software