|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Legacy vs Oppall 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
Show quote
Hide quote
"David" <dw85745***@earthlink.net> wrote Just a couple comments from the hip....> 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)? 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
Show quote
Hide quote
"David" <dw85745***@earthlink.net> wrote in message What you are talking about is not "OOP" so much as it is just writing in VB6 news:edefJabmJHA.3876@TK2MSFTNGP02.phx.gbl... > 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 (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 naked 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. 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 Show quoteHide quote "Bob Riemersma" <nospam@nil.net> wrote in message news:uijilTdmJHA.1252@TK2MSFTNGP03.phx.gbl... > "David" <dw85745***@earthlink.net> wrote in message > news:edefJabmJHA.3876@TK2MSFTNGP02.phx.gbl... >> 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 naked 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. > > "David" <dw85745***@earthlink.net> wrote in message OPP?news:edefJabmJHA.3876@TK2MSFTNGP02.phx.gbl... > I'm trying to make a decision whether to rework a large legacy program > using all OPP. Object Poriented Programming ?
Show quote
Hide quote
"Jeff Johnson" <i.get@enough.spam> wrote in message
http://en.wikipedia.org/wiki/O.P.P._(song)news:%23Z7JreBnJHA.4520@TK2MSFTNGP03.phx.gbl... > "David" <dw85745***@earthlink.net> wrote in message > news:edefJabmJHA.3876@TK2MSFTNGP02.phx.gbl... > >> I'm trying to make a decision whether to rework a large legacy program >> using all OPP. > > OPP? > > Object > Poriented > Programming > ? Obviously the OP is going to rework the program using stolen code <g>
How to get special Appdata folder
VB6 runtime is supported on Windows 7 ListBox color Printing PictureBox Contents FYI: MS UK VB6 Usage survey/poll - update What am I doing wrong Crash during compile Add objects already on form to Groupbox Shared MS Fax Problem getting the date of a running EXE file |
|||||||||||||||||||||||