Announcement

Collapse
No announcement yet.

Oop 101?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael Mattias
    replied
    And in an utterly shameless display of promotion for my own line of work.....

    This is why bringing in outside consultants from time to time is a really good idea. It exposes your people - not just the programmers, but the managers as well - to new ideas and new thinking.

    The other source for new ideas? I personally like dealing with 'rookies' fresh out of programming school.

    Since they don't know "we always do it this way" they simply "do it a different way."

    Since they don't know "what can't be done" they just do it anyway.

    And since they have not yet mastered the fine art of butt-covering when asked a pointed question, they simply tell you the truth.

    Leave a comment:


  • Michael Mattias
    replied
    And I forgot this:
    I can hear people complaining that they don't want a dozen+ DLL files. Ok, I can appreciate that
    As a manager, I can't. If you - an allegedly professional Windows' programmer - can't deal dynamic link libraries, you have already exceeded your theoretical "Peter Principle Peak Performance" and I'll be by to see you at your new job next week where I *will* have fries with that, thank you very much for asking.

    As programmer, well, that's not my call, is it? So maybe I should just go back to my cubicle and do my job to the best of my ability.

    Leave a comment:


  • Michael Mattias
    replied
    Not to keep picking on this, but nobody has yet to answer my primary question about OOP. Take your "large project". What if each programmer were give the same requirements. Could they not have just as easily compiled their section into a DLL and said "here, these are the parameters you pass to this specific function to get your return value." And, as for the example of creating a pool of database connections, could not the same program been done with procedural code as well? What does OOP have to do with the design of the solution here?
    Of course you can do the job procedurally.

    Joe, I've been involved with this issue for about 25 years as a developer, consultant and manager.

    In most cases of development conflicts ("Joe's code is stepping on Sally's code which is stepping on Jummy's code....") the simple answer is, management failure.

    The sad part is there is no good reason for these failures, other than managers cannot plan the work correctly because they do not understand how applications software works.

    And even it they don't understand it well enough to do this planning themself, how hard can it be to go to your 'lead' programming people to ask for a little help? All the manager really has to do is ask the question: "Will doing it this way result in Joe's code stepping on Sally's code?"

    Now I *have* seen cases where a new development tool (e.g a 'shiny new OOP-style compiler') is used by managers as the "excuse" for enforcing discipline, but for crying out loud, shouldn't the manager have been enforcing some kind of discipline all along?

    Shortsightedness and failure to invest in thinking about projects like this before commiting the resources is why we end up with $30 million taxpayer bucks totally written off on three separate State of Wisconsin software projects in the past five years.

    I'm not one to automatically blame management, but in this case there simply is no other explanation. Poor management is poor management is poor management.

    MCM

    Leave a comment:


  • José Roca
    replied
    It was just an example to show that there are other ways. COM classes don't support overloading. To simulate it, the compiler will have to create additional methods under the hood, IsPrime2, IsPrime3, etc., and determine which one to call.

    Leave a comment:


  • Michael Mattias
    replied
    >that will accept any numeric variable.

    Not BYVAL it wont... the number of bytes on the stack is different. However, the PB compiler will do a silent conversion if called with a different datatype parameter so it will "work."

    For functions requiring an integer parameter (eg "isPrime") conversion to EXT is not a problem, but for a 'general purpose' function accepting floats you might be introducing rounding errors.

    I use CUR a lot because there are no rounding issues, at least in the number range in which I work, which is integer or maybe two decimal quantities and price/extension in dollars.

    Leave a comment:


  • José Roca
    replied
    Or you can use

    Code:
    Function isPrime(BYVAL x as ext) as long
    that will accept any numeric variable. But I guess that it is too easy.

    Leave a comment:


  • Michael Mattias
    replied
    With Java style overloading, you'd just write them as:
    Code:
    Function isPrime(x as long) as long
    ...
    Function isPrime(x as quad) as long
    ...
    The right one would be selected at run time based on the "signature" of the parameter list
    Could't you accomplish this with one function which takes a VARIANT parameter, querying the actual type of data with the VARIANTVT() function and coding accordingly?

    MCM

    Leave a comment:


  • Jim Karabatsos
    replied
    An old post of mine that might shed some light for you

    Hi Mark

    Many years ago, I wrote a post that you might find useful, where I basically added some courseware that I had developed. The syntax is actually VB, but the concepts and benefits should still be clear and applicable to the new PB with Objects.

    See if that answers your question.

    Here is the link:

    /support/pbforums/showpost.php?p=138792&postcount=4

    -- Jim

    www.jimako.com/blog

    Leave a comment:


  • Joseph Cote
    replied
    I can't speak for how PB is doing this yet, but in Java and C++, overloading mainly refers to adding a fucntionality to an existing operation or method.

    For a concrete example, suppose you have need to write an isPrime() fuction that takes a long and returns a long. No problem.

    But then the project gets bigger and you need to know if a quad is a prime or not. At this point, without overloading, a new function called isPrimeQ() or such need to be written to take a quad input and return a long.

    With Java style overloading, you'd just write them as:
    Function isPrime(x as long) as long
    ...

    Function isPrime(x as quad) as long
    ...

    The right one would be selected at run time based on the "signature" of the parameter list. If it pleased you, you could write one that took a String as a parameter; in your function you'd have to convert it to numeric, but that's why there are different functions for different data types.

    Operators can also be overloaded, but this is more of a C++ thing, and honestly, outside my direct experience.

    Leave a comment:


  • Fred Harris
    replied
    Many members here have mentioned the idea of including code in a type, and, I might say - in a favorable way.

    Think back for just a second to the mid eighties or so when GWBASIC and such variants were in vogue. At that time we didn't even have TYPEs! Sure, you could create as many integers, singles, doubles as you wanted (within severe memory constraints, to be sure), but we all know how limited and poorly organized those programs were - the key point in the aformentioned being poorly organized.

    When TYPE variables were created in our favorite environment of the time be it TurboBasic, QuickBasic or whatever we were better able to organize our code, and our programs improved due to the amalgamation of related variables into a single TYPE.

    Now we have been given a new and improved version of the TYPE with greatly extended capabilities. And I have not heard one person yet state that the TYPE has been ruined by the inclusion of the ability to include functions within a TYPE. Everybody seems to be OK with that. Its just a continuation of the better organization principal as was the case when the TYPE was initially created. Data, and now the functions that specifically work with that data, are naturally and organically within the same enhanced TYPE, instead of scattered about various source code files.

    So, if the term OOP carries with it negative connotations for you, then don't use the term. Just use the new enhanced TYPE which we are now calling a 'Class' to better organize your programs. If over the years you came to appreciate the inclusion of the TYPE in BASIC, then by the same logic you should love the class!

    Leave a comment:


  • Barry Marks
    replied
    Originally posted by John Strasser View Post
    At it's most basic think of a class as a TYPE.
    I like the idea of extending struct to include code, calling it class of course. I did use that a little in C when I was using a C++ compiler. It was still procedural.

    I've done the same thing using different syntax, way before the days of C++, in C and even in ASM. I suspect most programmers have. I had libraries of modules I used all the time, mostly code, but a lot of them had their own data. OOP provides a way to formalize that but it isn't new.

    From what I've seen, and I don't know enough about OOP to be real confident of this, it seems that the only really new thing is the multiple inheritance or overloading, that lets the programmer using the objects ignore the type of data being fed to the objects. Maybe this is because most of my programming hasn't been in large projects but I don't really feel any need for that. I've sometimes mixed up my types as I code but not usually. It wasn't a big enough problem that it needed a big solution.

    Barry

    Leave a comment:


  • John Strasser
    replied
    Originally posted by Cliff Nichols View Post
    Thats the way I think of OOP as....1 Template.....Many Copies

    Maybe a bad analogy, but its the most simple explanation of OOP as I can see it.
    As far as OOP goes that's a great analogy. At it's most basic think of a class as a TYPE.

    Now allow the TYPE to include functions. And these functions work on the data present in that type.

    So far, not really any different from any non-OOP program, except that the TYPEs can't include functions (though you can have a code pointer which is similar).

    Where things can become easier to read is when you start overriding various functions such as stdin, stdout, +, ++, etc.

    As an example if I need complex math (because I'm working with circuits) I can override the "+" operator. Now (in pseudocode-ish style):
    Code:
    TYPE ImaginaryNum
       DIM realpart AS LONG
       DIM imgpart AS LONG
    END TYPE
    
    FUNCTION AddImagNums( x AS ImaginaryNum, y AS ImaginaryNum) AS ImaginaryNum
       DIM Ret_var AS ImaginaryNum
       Ret_var.realpart = x.realpart + y.realpart
       Ret_var.imgpart = x.imgpart y.imgpart
       RETURN Ret_var
    END FUNCTION
    
    FUNCTION PBMAIN () AS LONG
    
       DIM avar AS ImaginaryNum
       DIM bvar AS ImaginaryNum
       DIM cvar AS ImaginaryNum
    
       avar.realpart = 10
       bvar.realpart = 20
    
       avar.imgpart = 5
       bvar.imgpart = 50
    
       cvar = AddImagNums(avar, bvar)
    
    END FUNCTION
    With classes most of the program remains the same. Replace the word "TYPE" and have the function now be part of the class so the resulting program (skipping the declarations) is:

    Code:
    FUNCTION PBMAIN () AS LONG
    
       DIM avar AS ImaginaryNum
       DIM bvar AS ImaginaryNum
       DIM cvar AS ImaginaryNum
    
       avar.realpart = 10
       bvar.realpart = 20
    
       avar.imgpart = 5
       bvar.imgpart = 50
    
       cvar = avar + bvar
    
    END FUNCTION
    By overriding the "+" operator we still call the same function, we just use a more "natural" language.

    From a program design point of view, the real shift is that you use a "data centric" viewpoint rather than process centric. What data do I have to track and what do I have to do with it. THEN how does the process work.

    So if I was designing a process control system or simulation I might write a "base" class for a pump. And it would have functions designed for everything that a pump can do. Then I would create other classes which inherit the base class for the different types of pumps that would be available. And in those classes I might have to rewrite the functions I already have (different equations for different pumps say). BUT, because they're in a child class the function name would be the same.

    Now you may say why can't I just create different types, etc? You can. Where this becomes useful is that i can write a function that takes a variable of type "pump" as an argument and it will work with ANY variable that inherits from the "pump" class. No matter how far removed.

    So if the base class has 10 variables and a "child" class has 20 variables I can still pass the 2nd variable to a function that will accept the first and work with it just fine.

    Overriding class functions is kinda like changing the CSS style sheets on a web page. With the same HTML you can make the page look completelty different.

    Did this help? Or did I just confuse you more?

    John

    Leave a comment:


  • Cliff Nichols
    replied
    Not to keep picking on this, but nobody has yet to answer my primary question about OOP. Take your "large project". What if each programmer were give the same requirements. Could they not have just as easily compiled their section into a DLL and said "here, these are the parameters you pass to this specific function to get your return value." And, as for the example of creating a pool of database connections, could not the same program been done with procedural code as well? What does OOP have to do with the design of the solution here?

    I can hear people complaining that they don't want a dozen+ DLL files. Ok, I can appreciate that, but the source code for the DLL would be identical if it were in an ".inc" file as well as the ".dll" format, so the final project could have still been compiled as a single application (if that were a requirement\benefit), no?

    I'm really having a hard time seeing the difference between saying "this is the name of the CLASS, and these are the parameters you pass it" as opposed to "This is the name of the FUNCTION and these are the parameters you pass it".

    Am I the only one who doesn't see a big difference here?
    All valid points, Because with few exceptions, I have always found "What thall shalt write in OOP, thall Shalt be able to write procedural"

    Case in point, my statement about the Serial Port.....Sure I could either include different copies of the same DLL (Each just renamed as Serial Port 1, Serial Port 2, etc....and calling functions in each separate DLL, to keep things apart in the parent program. OR I could do the same with several INC files with the functions named slightly different), OR What I hope to prove once my copy of PB9 comes in, I can build a class object, and cut the code down to 1 template, and many copies sort of thinking

    Thats the way I think of OOP as....1 Template.....Many Copies

    Maybe a bad analogy, but its the most simple explanation of OOP as I can see it.

    Leave a comment:


  • Joe Byrne
    replied
    It's not strictly necessary, but it's just one different way to do it.
    Very well stated, and I believe is the crux of the matter. OOP, especially OOP in PB offers another way to skin the proverbial cat. I don't think anyone can make a case that its better, or worse, than procedural code, just different.

    I don't have an inherent problem with OOP, but there are some (not many in this forum) who tout it as the 'only real way to program. I highly disagree with that outlook. I can see where its necessary when you have to communicate with 3rd party applications and tools as well.

    But my bottom line is that I hope all the other great features of PB9 are not lost by all the talk of OOP.

    Leave a comment:


  • Nick Luick
    replied
    You can build a pre-fab house far faster and for less money than you can build a house
    from scratch. Which house do you want to live in?
    I would rather live in the one more energy efficient. If I were to buy it, I would prefer one with quality construction and better materials. Prefab can mean many things. Much of a home can be built in a factory with better quality control and assembled in the field. The materials used in the factory can have the same or better quality than a stick built house.

    I don't know if many have visited construction sites lately, but in tract homes the quality is not that great, and if they can hide it gets install whether broken or flawed materials.

    Leave a comment:


  • Joseph Cote
    replied
    Originally posted by Joe Byrne View Post
    I can hear people complaining that they don't want a dozen+ DLL files. Ok, I can appreciate that, but the source code for the DLL would be identical if it were in an ".inc" file as well as the ".dll" format, so the final project could have still been compiled as a single application (if that were a requirement\benefit), no?

    I'm really having a hard time seeing the difference between saying "this is the name of the CLASS, and these are the parameters you pass it" as opposed to "This is the name of the FUNCTION and these are the parameters you pass it".

    Am I the only one who doesn't see a big difference here?
    All valid points.

    If I may be given a lot of leeway here, and speak is Java-ish terms... A Class is something like a blueprint to build a new object. We could have a class called DB2Connection. It will have attribute descriptions (variables) and methods (functions). But generally (no quibbling now) it's not ready to go. An object of the type needs to be created which will have its own address in memory, and its own copy of the variables. The code for the methods resides in the classs description, so it isn't unnecessarily recopied. When you have created a new DB2Connection object, and have had it attach to the mainframe and identify itself, is a unique entity. Suppose we had written: cnx1 = new DB2Connection Then the variable cnx1 points to OUR connection object and no one else can see it or use it unless we share that address; no one could sneak in and say "delete * from *" under your login.

    This would be different than a function that was shared by all threads and did not contain individual data. This could be roughly replicated by defining a UDT and passing it in and out of funtions byref to simulate individual instance data.

    It's not strictly necessary, but it's just one different way to do it.

    Leave a comment:


  • Richard Angell
    replied
    A lot of the OOP positions here obscure what many will see as the added benefits of the improvements in COM so we can now use direct interface methods with existing application ... not to mention those we grow ourselves. In doing some comparisons converting some C++ code to work with a graphics engine, the PB resulting .exe executes faster than the compiled C++ by around 8% on a very,very slow shared memory Radeon GPU in a laptop.

    So while primary benefit of the COM expansion plus extensions appears specifically directed to those who would be OOP developer candidates, a significant portion applies equally to those of us who will need to interface to COM compatible EXE/DLL/OCX apps and libs ... but do not want to roll our own.

    What Fred,James and others have done is to begin adding some flavor and color to possible COM/OOP uses for the newer version of PB. In other words making code pictures worth many more words ... so those who learn from examples can perceive what benefits there may be for our own use. What is apparent is that this is a blockbuster release which will take some users much more time than others to perceive.

    Thanks for that.

    Leave a comment:


  • Barry Marks
    replied
    Originally posted by Fred Harris View Post
    The programmer must establish the association between the machine model (in the “solution space,” which is the place where you’re modeling that problem, such as a computer) and the model of the problem that is actually being solved (in the “problem space,” which is the place where the problem exists).
    It seems to me that this statement makes a case for procedural languages as well as it makes a case for OOP. Procedural programmers get to create a custom abastraction layer that's appropriate for that particular job.

    You can build a pre-fab house far faster and for less money than you can build a house from scratch. Which house do you want to live in?

    Barry

    Leave a comment:


  • Fred Harris
    replied
    OOP And Program Architecture

    Hi Jim!

    In terms of your comment regarding no callbacks in classes...

    I've been working with this for some time and the big gotcha is no callbacks within a class. It's not a PB thing, C++ has some real ugly code to handle it and mine is a little better but .....

    I will probably post the code just so the non-believers can scorn and belittle me
    I really wasn't thinking in terms of callbacks in classes, as the last thing I'm interested in is something like Microsoft's MFC (Microsoft Foundation Classes). What I was thinking of is much more modest, and is simply to wrap some of the common control creation code so as to avoid Api calls such as Get/SetWindowText(), CreateWindowEx(%Ex_CLIENT_EDGE, "edit","".....
    etc. My main problem with MFC is its fundamental design philosophy is to completely hide the Windows Api architecture due to its being evil. I like the Api and the Sdk design of coding with WinMain(), the Window Procedure, etc. All I'd like to accomplish is the simplification of some of the more routine stuff into some classes so as to avoid having to constantly be scouring Api reference material for SendMessage() parameter & equate info, for example. I think its doable, but just havn't gotten to looking at it yet.

    Fred

    Leave a comment:


  • Joe Byrne
    replied
    Joseph,

    Not to keep picking on this, but nobody has yet to answer my primary question about OOP. Take your "large project". What if each programmer were give the same requirements. Could they not have just as easily compiled their section into a DLL and said "here, these are the parameters you pass to this specific function to get your return value." And, as for the example of creating a pool of database connections, could not the same program been done with procedural code as well? What does OOP have to do with the design of the solution here?

    I can hear people complaining that they don't want a dozen+ DLL files. Ok, I can appreciate that, but the source code for the DLL would be identical if it were in an ".inc" file as well as the ".dll" format, so the final project could have still been compiled as a single application (if that were a requirement\benefit), no?

    I'm really having a hard time seeing the difference between saying "this is the name of the CLASS, and these are the parameters you pass it" as opposed to "This is the name of the FUNCTION and these are the parameters you pass it".

    Am I the only one who doesn't see a big difference here?

    Leave a comment:

Working...
X