Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Classes! Classes! What is Classes!
- Thread starter Goofus828
- Start date
Olaf Doschke
Programmer
In regard to Foxpro or in general?
Bye, Olaf.
Bye, Olaf.
Mike Lewis
Programmer
Goofus,
Instead of focusing on "classes", try searching for "object orientation" or "object-oriented programming". That should give you a more focused result.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
Instead of focusing on "classes", try searching for "object orientation" or "object-oriented programming". That should give you a more focused result.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
use classes" is that really the question? or is it more What are and why should I want to use them?
Classes are very different it is somewhat like saying how do it use/communicate with a person.
So I think we are all waiting for a more clear question.
Lion Crest Software Services
Anthony L. Testi
President
Classes are very different it is somewhat like saying how do it use/communicate with a person.
So I think we are all waiting for a more clear question.
Lion Crest Software Services
Anthony L. Testi
President
By doing a Google Search for: "Foxpro OOP" book I got a lot of 'hits'.
One 'hit' of note that I found among the other was a free tutorial:
Introduction To FoxPro Object Oriented Programming
NOTE - I have not looked at this myself, but it looks interesting.
Also there are reference books.
One is the older 'stand-by' book:
The Revolutionary Guide To Visual Foxpro OOP
It can also be found among the 'hits' and is available from a number of sources.
Or with an even better Amazon Review record is the book:
Advanced Object Oriented Programming with Visual FoxPro 6.0
It too can be found among the same Google 'hit' list.
And yet another book that I found on Amazon:
Object Orientation in Visual FoxPro
Good Luck,
JRB-Bldr
One 'hit' of note that I found among the other was a free tutorial:
Introduction To FoxPro Object Oriented Programming
NOTE - I have not looked at this myself, but it looks interesting.
Also there are reference books.
One is the older 'stand-by' book:
The Revolutionary Guide To Visual Foxpro OOP
It can also be found among the 'hits' and is available from a number of sources.
Or with an even better Amazon Review record is the book:
Advanced Object Oriented Programming with Visual FoxPro 6.0
It too can be found among the same Google 'hit' list.
And yet another book that I found on Amazon:
Object Orientation in Visual FoxPro
Good Luck,
JRB-Bldr
- Thread starter
- #6
Thank you all for your responses.
I've bee OO programming for years but I never really got around to using classes to aid in my development of code. Yes it was a vague question. Sorry for that.
Jrb - I will look into the hits that you found and I will do the same type of search.
Thanks.
I've bee OO programming for years but I never really got around to using classes to aid in my development of code. Yes it was a vague question. Sorry for that.
Jrb - I will look into the hits that you found and I will do the same type of search.
Thanks.
Olaf Doschke
Programmer
Makes me wonder. Classes are the main concept of OO programming, what's left over of OO programming, if you avoid classes? Do you perhaps actually mean you're avoiding class hierarchies and inheritance, by coding directly into base classes/objects?
Bye, Olaf.
Bye, Olaf.
alvechurchdata
Programmer
I'm afraid I'm with Goofus here, I use very few classes in everyday work. I've got my own library of standard controls and I wrote some data-handling classes but I guess that I've just got a procedural mind.
Geoff Franklin
Geoff Franklin
Olaf Doschke
Programmer
Geoff,
that's perhaps a bit of a bad habit, but if you get along with this way of working it's nothing to worry about. You also can do horrible oop class design leading nowhere and very structure procedural programming.
Nevertheless you don't say, you've done OO programming, as you didn't.
Bye, Olaf.
that's perhaps a bit of a bad habit, but if you get along with this way of working it's nothing to worry about. You also can do horrible oop class design leading nowhere and very structure procedural programming.
Nevertheless you don't say, you've done OO programming, as you didn't.
Bye, Olaf.
Koen Piller
Programmer
Hi,
May I advertise the Hentzenwerke publisher here? I could strongly advise you to read '1001 Things' and '1002 Things' both originaly written for VFP7 but still very much uptodate also for VFP9.
Regards,
Jockey2
May I advertise the Hentzenwerke publisher here? I could strongly advise you to read '1001 Things' and '1002 Things' both originaly written for VFP7 but still very much uptodate also for VFP9.
Regards,
Jockey2
alvechurchdata
Programmer
>> Nevertheless you don't say, you've done OO programming, as you didn't.
But I do do OO programming. I first met the technology when I wrote expert systems in the early 90's and I'm maintaining OO Fox systems today.
It's just that I usually find that the procedural solution comes easier to me and I'm glad that VFP allows me to use both techniques. When I'm using Java part of me admires the elegance of the structure and part of me says that I could have done the whole job much more quickly as a short procedure in Fox.
Geoff Franklin
But I do do OO programming. I first met the technology when I wrote expert systems in the early 90's and I'm maintaining OO Fox systems today.
It's just that I usually find that the procedural solution comes easier to me and I'm glad that VFP allows me to use both techniques. When I'm using Java part of me admires the elegance of the structure and part of me says that I could have done the whole job much more quickly as a short procedure in Fox.
Geoff Franklin
It's not about writing it the first time. It's about maintenance and testability. You'll only write the code once, but you'll maintain it for years. OOP makes the code easier to maintain because things become fine grained. Making a change in one part of the code makes it much less likely there will be side effects. Having things small grained also makes them easier to do automated unit testing.
Craig Berntson
MCSD, Visual C# MVP,
Craig Berntson
MCSD, Visual C# MVP,
Mike Lewis
Programmer
It's also about making it easier to develop multiple applications - in other words, reusability.
When you develop a class, you need to take a little extra care to make it generic. You can then reuse it in any future projects that need it.
This really does pay off very quickly.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
When you develop a class, you need to take a little extra care to make it generic. You can then reuse it in any future projects that need it.
This really does pay off very quickly.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
alvechurchdata
Programmer
I know all the arguments for OOP but I'm just not convinced that taking all the functions from my old proc file and making into methods of the goApp object is going to help me much.
I've also got a login form that I've used for many years now. It's a form and I copy it from one project to the next - "cut-n-paste inheritance". It would be very easy to "Save As Class" but I can't see the benefit. If I were part of a bigger team and needed to manage a consistent behaviour across all login forms in the company then it would make sense to have a login class but every job is different so I've not bothered.
Geoff Franklin
I've also got a login form that I've used for many years now. It's a form and I copy it from one project to the next - "cut-n-paste inheritance". It would be very easy to "Save As Class" but I can't see the benefit. If I were part of a bigger team and needed to manage a consistent behaviour across all login forms in the company then it would make sense to have a login class but every job is different so I've not bothered.
Geoff Franklin
Olaf Doschke
Programmer
It's certainly true that just for the matter of all the procs and functions being globally available it does not make sense and does not turn them into OOP by adding them all to a goApp object.
The advantage of classes is inheritance, and for very basic functions like LastDayOfMonth there is no need to put that into a class.
I also don't tend to have a seperate framework project or repository all other projects use and all other projects inherit a change from, that would cause a maintaince hell. Each project will start with a certain version of a framework and if that is updated within the lifetime of that application is a matter of individual needs.
The login form is a bad example, if that's only meant for one company. A reason to put htat into a form class instead of staying with an scx rather would be uniformly using form classes at runtime and not mix DO FORM with form class instanciation.
The benefit of a form class hierarchy should be obvious in supporting similar forms via classes. You begin with basic classes doing basic functionality and you add special features at the end of the class hierarchy. You could also put a login into such an hierarchy somewhere at the end of a class branch.
Bye, Olaf.
The advantage of classes is inheritance, and for very basic functions like LastDayOfMonth there is no need to put that into a class.
I also don't tend to have a seperate framework project or repository all other projects use and all other projects inherit a change from, that would cause a maintaince hell. Each project will start with a certain version of a framework and if that is updated within the lifetime of that application is a matter of individual needs.
The login form is a bad example, if that's only meant for one company. A reason to put htat into a form class instead of staying with an scx rather would be uniformly using form classes at runtime and not mix DO FORM with form class instanciation.
The benefit of a form class hierarchy should be obvious in supporting similar forms via classes. You begin with basic classes doing basic functionality and you add special features at the end of the class hierarchy. You could also put a login into such an hierarchy somewhere at the end of a class branch.
Bye, Olaf.
Mike Lewis
Programmer
I'm not suggesting you do that. Although something like 90% of my generic code is in classes, I also still have a good old Proc file, and I have no intention of objectifying it. Nor do I have a goApp object.
Where I use classes is for thing like access control (any control can ask the class whether the user has permission to access it), saving the state of the desktop, dealing with user preferences, managing connections to back end databases, retrieving information from the Internet, etc. etc.
As far as the login screen is concerned, this is part of my generic user manager class. The class is responsible for identifying and validating the user, and related tasks, one of which is to provide a user interface for the login process.
Like many of the developers here, I work on multiple applications for several clients. There's a huge benefit in being able to take any of the above classes and reuse it across other projects.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
Geoff:
Let's take your login form as an example. Using the OOP concept of Separation of Concerns, the form should have minimal or no functionality in it. So that, when the user clicks the LogIn button, all the login code exists in a separate class, not the form. This make it easy to test the functionality without actually running the form.
Does this help with understanding?
Craig Berntson
MCSD, Visual C# MVP,
Let's take your login form as an example. Using the OOP concept of Separation of Concerns, the form should have minimal or no functionality in it. So that, when the user clicks the LogIn button, all the login code exists in a separate class, not the form. This make it easy to test the functionality without actually running the form.
Does this help with understanding?
Craig Berntson
MCSD, Visual C# MVP,
alvechurchdata
Programmer
Sorry Craig, I agree that as a general principle it's good to keep the UI separate from the business logic but I also feel that it's not always necessary. I'm not going to call the login routines from anything other than the login form and the login form is not going to do anything but call the login routines. I don't feel that it's worth adding another level of abstraction for a form which I use once in each new project - say twice a year. The only abstraction I've got is that the encryption routine lives in a procedure file because I know that it'll be useful elsewhere in the project.
Data entry is different though because I know I'll be entering data in many, many places on every project I ever write. It was worth putting the effort into a generic data handling class that knows how to validate and save and handle conflicts and revert because it has been used over and over again. That class had to be generic and had to stand alone so that it could be used by data entry forms and by import routines and by anything else that needed to save data. Complexity is only worthwhile when it pays back on its investment.
Geoff Franklin
Data entry is different though because I know I'll be entering data in many, many places on every project I ever write. It was worth putting the effort into a generic data handling class that knows how to validate and save and handle conflicts and revert because it has been used over and over again. That class had to be generic and had to stand alone so that it could be used by data entry forms and by import routines and by anything else that needed to save data. Complexity is only worthwhile when it pays back on its investment.
Geoff Franklin
I'm not going to call the login routines from anything other than the login form and the login form is not going to do anything but call the login routines"
When testing a form or code, does the form/code need the login information, e.g. show only these fields for user with this level of control? Is so in order to test the form does one have to login in via the login form? Seems like extra unneeded work when in the program-test-fix cycle. I would much rather have a login class that I can interface to from my test code which then calls the form/code that I am working with. e.g. I do not have to stop and type a user name/password over and over and over again as I work on new code.
Lion Crest Software Services
Anthony L. Testi
President
When testing a form or code, does the form/code need the login information, e.g. show only these fields for user with this level of control? Is so in order to test the form does one have to login in via the login form? Seems like extra unneeded work when in the program-test-fix cycle. I would much rather have a login class that I can interface to from my test code which then calls the form/code that I am working with. e.g. I do not have to stop and type a user name/password over and over and over again as I work on new code.
Lion Crest Software Services
Anthony L. Testi
President
Geoff,
That violates one of the concepts OOP, Separation of Concerns ( But, is it OOP? Yes. Does it have procedural code in the class? Probably. Mixing procedural code with OOP is still a very big problem in software. It's common to see a single method that does lots of stuff. Hard to test. Hard to maintain. But, it works.
Craig Berntson
MCSD, Visual C# MVP,
That violates one of the concepts OOP, Separation of Concerns ( But, is it OOP? Yes. Does it have procedural code in the class? Probably. Mixing procedural code with OOP is still a very big problem in software. It's common to see a single method that does lots of stuff. Hard to test. Hard to maintain. But, it works.
Craig Berntson
MCSD, Visual C# MVP,
- Status
Similar threads
- Locked
- Question