You are right
OOP programming
Moderator: Rathinagiri
-
Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: OOP programming
Hi All,
This discussion reminds me the old times, when MiniGUI library started and I used to "apologize" because it was semi-OOP and not traditional OOP
IMHO, the easiest way to code average business apps, is using just some OOP concepts, but not all of them.
If you look at popular languages like JavaScript or PHP, there is a lot of code available, that does a minimal use of OOP.
Some OOP concepts, like polymorphism or inheritance can be very useful, but, for doing what? Simple to moderately complex applications?
One of the goals of MiniGUI/HMG is to make things simple. That means, public GUI elements (globally available) defined in a simple way. You can define a window and its controls in an elegant and beautiful way and they are available everywhere in your program.
Many years ago, at some point (tired of OOP "thing") I've created an OOP wrapper for HMG, but, finally discarded the idea, because IMHO, it was simply an unnecessary layer, adding some "fat" and "slowness" to the library.
Now, many years after the 90's OOP "fever" there is some consensus around the idea, that some traditional OOP concepts make things harder than easier.
https://medium.com/@cscalfani/goodbye-o ... 9cda4c0e53
This discussion reminds me the old times, when MiniGUI library started and I used to "apologize" because it was semi-OOP and not traditional OOP
IMHO, the easiest way to code average business apps, is using just some OOP concepts, but not all of them.
If you look at popular languages like JavaScript or PHP, there is a lot of code available, that does a minimal use of OOP.
Some OOP concepts, like polymorphism or inheritance can be very useful, but, for doing what? Simple to moderately complex applications?
One of the goals of MiniGUI/HMG is to make things simple. That means, public GUI elements (globally available) defined in a simple way. You can define a window and its controls in an elegant and beautiful way and they are available everywhere in your program.
Many years ago, at some point (tired of OOP "thing") I've created an OOP wrapper for HMG, but, finally discarded the idea, because IMHO, it was simply an unnecessary layer, adding some "fat" and "slowness" to the library.
Now, many years after the 90's OOP "fever" there is some consensus around the idea, that some traditional OOP concepts make things harder than easier.
https://medium.com/@cscalfani/goodbye-o ... 9cda4c0e53
Regards/Saludos,
Roberto
(Veritas Filia Temporis)
Roberto
(Veritas Filia Temporis)
-
EduardoLuis
- Posts: 682
- Joined: Tue Jun 04, 2013 6:33 pm
- Location: Argentina
Re: OOP programming
Hi Roberto:
Everything you've mention is absolutly correct.-
You've said: "Some OOP concepts, like polymorphism or inheritance can be very useful, but, for doing what?".- Is preciselly that what - IMHO - every programmer must think before planning an app.-
Developing an app i focus on a hard analisis of these parameters:
1.- What do any user needs (screen views, reports, data analisis, etc) In these parameter i use old school program procedures, drawing on paper what later will be screens with it's controls and data, and also the reports, -etc. etc. etc.
These means an interview with end user to know his preferences, and who / whom will operate de system.- IMHO an app must be easy to use for unexpert users, and the most familiar with other commercial app.- By this reason i skin my app similar to Office (because of its extension of use for everybody); this way any user will find in the same place some controls (menu) like load, save, print, etc. etc.- These means that end user will feel familiar with my app.-
2.- Choose the most efficient procedure for each one, selecting de aproppiate controls and functions, writing reutilizable code that for my as a programmer, lets me use on different app (something like a library of procedures) so in the future i'll invest less time for newer app.- For these implementation i perform a "main.exe" and multiples one's to avoid all system crash, and of course to perform an upgrade of only the needed portion of the the system, not recompilling all the system.- About the controls selected, i found that other colleagues extend the use of bigger grids to exhibit data, like a spreadsheet ; IMHO thats a mistake and use lot of memory; grid - IMHO - must be the shortest (only relevant data), and if end user needs more, that info must be on other controls like TEXTBOX (numeric or text) and EDITBOX.- But as i said, these is a choose, but finally the stability of the system justifies this method.-
3.- Finally and for me the most important, test the app on multiple machines with small or bigger memory, and under different SO (no everybody like the last version of SO, for ex. Win 10, and till today i found lots of users that have XP SP3).- I found that app that runs on smallest hardware without issues, flys on the highest one.- As we can develope under 32 o 64, i choose 32, its the most extended.-
No mather wich method we implement (OOP or classic), what really mathers is the stability and speed of the app.-
HMG is a fantastic develope system, that let us develope any app we imagine.- Just we must invest time, and go on.-
With regards.
Eduardo
Everything you've mention is absolutly correct.-
You've said: "Some OOP concepts, like polymorphism or inheritance can be very useful, but, for doing what?".- Is preciselly that what - IMHO - every programmer must think before planning an app.-
Developing an app i focus on a hard analisis of these parameters:
1.- What do any user needs (screen views, reports, data analisis, etc) In these parameter i use old school program procedures, drawing on paper what later will be screens with it's controls and data, and also the reports, -etc. etc. etc.
These means an interview with end user to know his preferences, and who / whom will operate de system.- IMHO an app must be easy to use for unexpert users, and the most familiar with other commercial app.- By this reason i skin my app similar to Office (because of its extension of use for everybody); this way any user will find in the same place some controls (menu) like load, save, print, etc. etc.- These means that end user will feel familiar with my app.-
2.- Choose the most efficient procedure for each one, selecting de aproppiate controls and functions, writing reutilizable code that for my as a programmer, lets me use on different app (something like a library of procedures) so in the future i'll invest less time for newer app.- For these implementation i perform a "main.exe" and multiples one's to avoid all system crash, and of course to perform an upgrade of only the needed portion of the the system, not recompilling all the system.- About the controls selected, i found that other colleagues extend the use of bigger grids to exhibit data, like a spreadsheet ; IMHO thats a mistake and use lot of memory; grid - IMHO - must be the shortest (only relevant data), and if end user needs more, that info must be on other controls like TEXTBOX (numeric or text) and EDITBOX.- But as i said, these is a choose, but finally the stability of the system justifies this method.-
3.- Finally and for me the most important, test the app on multiple machines with small or bigger memory, and under different SO (no everybody like the last version of SO, for ex. Win 10, and till today i found lots of users that have XP SP3).- I found that app that runs on smallest hardware without issues, flys on the highest one.- As we can develope under 32 o 64, i choose 32, its the most extended.-
No mather wich method we implement (OOP or classic), what really mathers is the stability and speed of the app.-
HMG is a fantastic develope system, that let us develope any app we imagine.- Just we must invest time, and go on.-
With regards.
Eduardo