OOP terminology

  1. ‹ Older
  2. 8 weeks ago

    Bob K

    Dec 30 Pre-Release Testers, Xojo Pro Kansas City

    @Beatrix W There is even a series about Bob: https://www.amazon.com/We-Are-Legion-Bob-Bobiverse/dp/B01L082SCI

    Oooohhhh....I hadn't heard of that one. I'll have to add that to my reading list.

  3. Craig H

    Dec 30 Black Hills, SD, USA

    @Joost R // Run method to clean the table and mug
    oTable.Clean
    oMug.Empty
    oMug.Wash

    // Get new coffee and refill the mug
    dim oCoffee as new Coffee
    oCoffee.choice = cStrong
    oCoffee.make(0.5) // 0.5 liter
    oMug.Fillup(oCoffee)

    If you don't object, I thinking that a more appropriate language for this class of problem, at least in this instance, would be ...
    (wait for it...)
    Java

  4. Robert B

    Dec 30 Pre-Release Testers, Xojo Pro University of Connecticut

    @Beatrix W There is even a series about Bob: https://www.amazon.com/We-Are-Legion-Bob-Bobiverse/dp/B01L082SCI

    Having read all three books in the series, I can heartily recommend them. Bob in this case is an artificial intelligence with a soul and a great sense of humor. Science fiction at its best.

  5. Paul R

    Dec 30 Pre-Release Testers, Xojo Pro Kirkland, WA

    Dog, Human are (abstract) classes, describing the properties and functions of their respective entities.

    Fido and Bob are instances of their respective classes.

    Fido and Bob are objects (I.e. instances of some class)

  6. Scott C

    Dec 30 Pre-Release Testers, Xojo Pro twitter.com/ScottCadillac

    @Robert B Having read all three books in the series, I can heartily recommend them. Bob in this case is an artificial intelligence with a soul and a great sense of humor. Science fiction at its best.

    I read this series as well. Quite entertaining. The author obviously knows a thing or two about software development (being a developer himself), which made it more interesting for me.

    But now we're getting WAY off-topic, so here's a nice & concise break-down on-topic from @Norman P's blog Classes, Instances and Objects .

  7. 7 weeks ago

    Robert L

    Jan 3 XDC Speakers Federal Way, WA (Seattle Area)

    Classes are DNA coding. If it is human DNA, it has the information to create a new human. cat DNA can make cats.
    Objects are humans (Mankind). They are the manifestation of their class
    Instances are individuals. (Bob)

    // Grammar is a little screwy because Bob is a human not a humanDNA But humans are abstractions.
    // But we can live with that. When Perlman tried to improve the grammar with v. 2 the Xojosphere jumped down his throat
    Var Bob As New humanDNA // So now Bob is a human but we don't know anything about him

    // Now we will flesh him out (so to speak).
    Bob.age = 64
    Bob.height = 6.2 feet
    Bob.appelation = "Robert"

    // Now Bob has become an instance.

    Bob can do things. He can interact with other instances (his car, his cat, and with his friend Susan).
    Bob is a human object. We can talk about humans in general over cocktails. But in our code, we talk about Bob (or Susan). Bob does this and that. The general characteristics of Bob and Susan are captured by the range of characteristics of humans. Human don't fly for example.

    But it is entirely possible that Susan could perform some job that Bob could not. When you (the coder) want a task done you have to decide whether Bob or Susan is going to do it and you have to make sure that that individual is empowered to do it.

    You can't ask the DNA to do it. DNA can only make another human. That is all it is good for. You can't ask human to do it. Humans are just a concept. "Somebody should do something about the state of education in America" That is not how code works.

    Classes have names in our code. Instances have names in our code. Objects, no.

  8. Fantastically clear and detailed explanation Robert. Best description I’ve seen yet.

    @RobertLivingston Classes are DNA coding. If it is human DNA, it has the information to create a new human. cat DNA can make cats.
    Objects are humans (Mankind). They are the manifestation of their class
    Instances are individuals. (Bob)

    Bob can do things. He can interact with other instances (his car, his cat, and with his friend Susan).
    Bob is a human object. We can talk about humans in general over cocktails. But in our code, we talk about Bob (or Susan). Bob does this and that. The general characteristics of Bob and Susan are captured by the range of characteristics of humans. Human don't fly for example.

    But it is entirely possible that Susan could perform some job that Bob could not. When you (the coder) want a task done you have to decide whether Bob or Susan is going to do it and you have to make sure that that individual is empowered to do it.

    You can't ask the DNA to do it. DNA can only make another human. That is all it is good for. You can't ask human to do it. Humans are just a concept. "Somebody should do something about the state of education in America" That is not how code works.

    Classes have names in our code. Instances have names in our code. Objects, no.

  9. Norman P

    Jan 5 Pre-Release Testers, Xojo Pro outside listening to the crick...

    @RobertLivingston But it is entirely possible that Susan could perform some job that Bob could not.

    Just to be clear if Bob and Susan are instances of the same class, in your code, then they have identical abilities (unlike humans where EVERY human isa new CLASS type - because we're all unique)

    EVERY instance of the same class TYPE has the exact same abilities (methods) that can be relied on

  10. Robert L

    Jan 6 XDC Speakers Federal Way, WA (Seattle Area)

    But they can have properties that limit or extend (relatively) their methods. Humans might have the run method but we are not all Usain Bolt.

  11. Ulrich B

    Jan 6 Pre-Release Testers, Xojo Pro Europe (Germany, Berlin) · xo...
    Edited 7 weeks ago

    @RobertLivingston But they can have properties that limit or extend (relatively) their methods. Humans might have the run method but we are not all Usain Bolt.

    Wich still supports what Normans said. For explaining a suspected difference between instance and object, your example does not fit well because you are basically saying that you need an instance of the fitting subclass for a task.

    @RobertLivingston Classes have names in our code. Instances have names in our code. Objects, no.

    Sure they do. Any instance of a class is also an object. As I said earlier, to call something an instance (of) is just another view onto the same thing. Object is a generality. To extend Robert’s example: Any being is an object. Any being is also an instance of its species: Mammal, reptile … And of course at the same time an instance of its subspecies: dog, cat, human … And of its sub-sub-species and so on, down to its family.

    In terms of code, we mostly view objects from the instance viewpoint: We want to handle a certain class. Because, as Robert stated, not every class matches every purpose. So we ask for certain class instances, like a DateTime, a sound, a picture … But technically, each instance of each class we handle is at the same time an object. It’s just the viewpoint we change.
    Only rarely – like when we use variants –, we use the object viewpoint in code ourselves. But in most of the cases we will then still change the viewpoint and ask for the object class when we process the input.

    The object viewpoint states (in this example) solely that a being exists. Viewing an object as an instance reveals its class, because by syntax instance cannot stand alone in a sentence. It is always an instance of a class. You don’t say "you need to create an object of MainWindow". But on a more general viewpoint that instance of MainWindow is still an object. But you have to get closer to examine it and view it as an instance of its class to know more about it. In most of the cases.

    EDIT: Like you would usually only say "That is the son" if the context is known (Using FamilySmith). The way more common sentence would be "That is the son of Mr & Mrs Smith."

    EDIT: Under this viewpoint of course one has to agree with Robert again: In Xojo, an object does not have a name if viewed as an object itself. In many other languages, every object will at least have its individual handle.
    And in some others, everything is an object.

  12. Norman P

    Jan 6 Pre-Release Testers, Xojo Pro outside listening to the crick...

    @RobertLivingston But they can have properties that limit or extend (relatively) their methods. Humans might have the run method but we are not all Usain Bolt.

    Properties are data - it might result in differetn behaviour IF your code relies on the data to determine how to process that data

    But the methods and events (the actual code) are the same across all instances

  13. Andre K

    Jan 6 Pre-Release Testers

    @RobertLivingston Humans might have the run method but we are not all Usain Bolt.

    I guess we are needed for the slowmotion pictures, Bolt's picture were allways unsharp.

  14. Tim P

    Jan 6 Pre-Release Testers, Xojo Pro Rochester, NY

    Not a scientist view:
    Doesn't the whole thing fall apart where to change an organism's (instance) properties you have to change the DNA? My eyes are blue because my DNA says so. That's not how classes work, classes say my eyes can have a color.

  15. Norman P

    Jan 6 Pre-Release Testers, Xojo Pro outside listening to the crick...
    Edited 7 weeks ago

    Humans & DNA are not a great metaphor because they don't actually behave the same as classes & instances.

    Classes are more like a template for creating new items of that type. And all items of that type may have different data, but they will all have the same set of method, events, properties, etc etc. In that regard they are identical EXCEPT for the data they contain.

    In the case of something manufactured though it fits better.
    Chevy makes a wide variety of vehicles.
    Each type of vehicle is a specific CLASS - a Silverado, Colorado, etc.
    And every last one would, without customization be "identical" - flat grey with a specific engine type etc.

    Customization can be thought of as creating a "subclass" of the general type - a Silverado with a bigger engine is still a Silverado (the more general class) but with a few special tweaks &customizations.
    And every other Silverado configured exactly that same way would share those same characteristics. They would all be IDENTICAL - you might think of their color as "data" - mechanically they should be identical (in theory but car owners know this isnt true)

    And all of the customized Silverados would share some characteristics with the more general generic Silverado and some between them that are different from the original Silverado

    And each of those Silverados, as they rolled off the production line, IS one instance (mine, georges, freds, etc)

    And they are all "vehicles" (objects) along with all the vehicles made by Ford, Fiat/Chrysler, Toyota ,etc

    Humans dont work that way at all
    We mostly share some characteristics in terms of how we appear - 2 legs 2 arms upright etc.
    Except for when we dont because of genetic variation - and thats where the metaphor fails.
    Humans arent carbon copies and cloning isnt quite the right notion for how classes work.

  16. Ivan T

    Jan 7 Pre-Release Testers

    @Tim P Not a scientist view:
    Doesn't the whole thing fall apart where to change an organism's (instance) properties you have to change the DNA? My eyes are blue because my DNA says so. That's not how classes work, classes say my eyes can have a color.

    It is just a instance with read only properties.

  17. Robert L

    Jan 7 XDC Speakers Federal Way, WA (Seattle Area)

    Customization can be thought of as creating a "subclass" of the general type - a Silverado with a bigger engine is still a Silverado (the more general class) but with a few special tweaks &customizations.
    And every other Silverado configured exactly that same way would share those same characteristics. They would all be IDENTICAL - you might think of their color as "data" - mechanically they should be identical (in theory but car owners know this is'nt true)

    I would contend that customization could be thought of in two ways. You like to think of it as a subclass if a Silverado has a bigger engine.

    You have decided to emphasize that (in contrast) different colors are "mere" data. I assume that you mean colors might be a property.

    But I think that you could have a property (engine size) that would differentiate two Silverados even though they were the same class. That property, in turn, might determine the top speed and miles/per gallon. It would not be as "trivial" as color.

    It seems to me that you could approach the problem of these two types of Silverado in different ways.

    1. Making a subclass
    2. Assigning different properties to members of the same class

    I can imagine situations in the life of a programmer that one or the other approach was simpler or more comfortable. My sense is that I tend to work more with properties and Norman with subclasses.

    For those watching from afar, I might note that I am what has been called a "citizen programmer" and Norman is a "professional programmer".

  18. Robert L

    Jan 7 XDC Speakers Federal Way, WA (Seattle Area)

    Doesn't the whole thing fall apart when to change an organism's (instance) properties you have to change the DNA? My eyes are blue because my DNA says so. That's not how classes work, classes say my eyes can have a color.

    Well, when an example designed to help clarify a situation breeds confusion, it is hard to conclude that it is anything but a bad example. Mea culpa.

    But just to be argumentative, eye color might be genetically determined but there are many properties of a human (knowledge, skills, relationships) that are not.

    In some sense, any class, even one with NO assigned properties have what in the English language might be called properties. The human class might be considered to have four limbs and two eyes even though there is no property that has been created to describe this. All instances of the class are assumed to be identical in this regard.

    When a property is assigned by a programmer to a class it implies that there is a variation amongst the instances of a class in this regard. And there is no reason for the programmer to bother if that difference does not make any difference in how the program works.

    Eye color might not have any significance in how the program works so I can dismiss it. But I think that Tim and Norman are making a valid point of sorts. Until properties get assigned (if they do at all) classes are IDENTICAL and humans are not. I can argue that my program is not interested in eye color so bringing it up is just to throw dust in the air. But my analogy does fail to capture the fact instances of a class are strictly IDENTICAL if that class does not define any properties or if the two instances have the same values of whatever properties are defined. Humans are not identical.

    But, in my example, I was implying that humanDNA is identical. Like it was cloned humanDNA. Like when someone uses the example of a blueprint as defining a class we understand that it is the same blueprint. My implicit assumption was that it was the same humanDNA.

    But anyway it threw some people off track

  19. Norman P

    Jan 8 Pre-Release Testers, Xojo Pro outside listening to the crick...

    @RobertLivingston I would contend that customization could be thought of in two ways. You like to think of it as a subclass if a Silverado has a bigger engine.

    You have decided to emphasize that (in contrast) different colors are "mere" data. I assume that you mean colors might be a property.

    But I think that you could have a property (engine size) that would differentiate two Silverados even though they were the same class. That property, in turn, might determine the top speed and miles/per gallon. It would not be as "trivial" as color.

    You most definitely could make engine size just a property - depending on use case thats more likely to be the correct approach

    @RobertLivingston But my analogy does fail to capture the fact instances of a class are strictly IDENTICAL if that class does not define any properties or if the two instances have the same values of whatever properties are defined. Humans are not identical.

    The classes are "identical" in that they have the same set of properties but the values in those properties vary (humans have 2 eyes - their eye color varies)
    They have the same events and methods

    The class is a template for every instance. The values in each instance vary.

  20. 6 weeks ago

    Matthew S

    Jan 12 Pre-Release Testers, Xojo Pro
    Edited 6 weeks ago

    @RobertLivingston Well, when an example designed to help clarify a situation breeds confusion, it is hard to conclude that it is anything but a bad example. Mea culpa.

    It seems inevitable that every OOP discussion ends up poking holes in analogies. Similar to looking at the photo of a cat and complaining you can not hear it purr (!)

    What gets lost in these discussions is the utility of OOP. OOP is human utility and a design concept, intended to make a complex finite state machine appear a little less 'alien' to human programmers. Keep in mind that the machine is fundamentally sequential and source codes compile down to machine instructions that resemble first generation BASIC "spaghetti." The logical grouping of data and executable instructions that represents a software object in source, is blown away by a compiler.

    I see little point over-thinking a source code paradigm.

    But my analogy does fail to capture the fact instances of a class are strictly IDENTICAL if that class does not define any properties or if the two instances have the same values of whatever properties are defined.

    Strictly speaking, just no! Uniqueness is an attribute of the word "instance." All instances are unique, just as identical twins and similar cars are in fact unique.

    An 'instance' is a physical presence. However alike identical twins might appear, they can not occupy the exact same physical space, hence we can deduce that each twin must be a unique instance. Instances of software objects are no exception. The physical presence of a software object is the electrical representation in memory at run-time. No two instances of a software object can occupy the exact same address space, therefore every instance of a software object IS unique.

    For what it's worth, this is how I understand the terms.

    Object (software) - A 'vague' design concept - often scribbled vaguely on a white-board. Created when a developer envisages entity X needing attribute Y and behaviour Z. In OOP parlance 'Object' refers to the logical grouping of data with the executable instructions that act on it - IN SOURCE.

    Class - A 'concrete' type definition statement, useful for grouping data (properties) and executable instructions (methods) together as a logically combined entity - IN SOURCE. Also known as, "a struct on steroids." At run-time, data must be located in RAM, while executable instructions may be blown onto a physically separate PROM or located in a read only address space. After compilation a Class more closely resembles a bunch of functions and a struct containing pointers to them.

    Instance - A software object's physical presence in memory at run-time. For practical purposes we can take 'memory' to mean RAM specifically. An instance is created when RAM is allocated to hold an object's data, (a struct remember,) and destroyed when that RAM is released causing the contents to be invalidated.

    To demonstrate the difference between a type definition statement and an instance, pick up an English Dictionary. The pages of an English Dictionary are full of type definition statements. For example: "Truck - a large road vehicle that is used for transporting large amounts of goods." What you will not find in an English Dictionary is an instance of a truck - it will not fit between the pages.

    The English language allows the terms object, class, instance to be used interchangeably. A computer's memory is not so malleable. I find it helps me to maintain a clear distinction along the lines of design, implementation and (physical) behaviour at run-time. We think of objects, write classes, construct instances.

  21. Emile S

    Jan 12 Europe (France, Strasbourg)

    @Norman P Humans & DNA are not a great metaphor because they don't actually behave the same as classes & instances.

    That is true.

    Dad was blond/blue eyes; a nephew is brown and had a daughter with a brown woman, the daughter is blond with blue eyes ! So eyes color is coded in 64 Bits ;)

or Sign Up to reply!