Basics - How is the Class-Diagram? ??????

hello, what is the right UML from my Processing-Programm?

here is my try:
Class-Diagram
if this is correct, what comes in the blank field?

PImage img= new PImage ();
void setup() {
}
void draw() {
}
void helloWorld() {
  println("hello World!");
}
void mousePressed() {
}

class classA {
  classA() {
  }
  void doSomething() {
  }
}

Answers

  • I'm assuming that you're asking what the name of the main class is.

    The name of the class is the name of the sketch (tab).

    I.e:

    Screenshot from 2014-09-21 10:25:36

    You can see that my sketch name is sketch_140921a.

    So, literally, if I do the following in my program, it will run just fine:

    Screenshot from 2014-09-21 10:31:37

    So... the sketch tab name goes in that empty field.

  • edited September 2014

    Thank you :)

    but is the rest mousePressed(),.. on the right place?
    and is this connection correct?

    Class-Diagram

  • I don't know much about UML diagrams. But you should be aware that classes inside ".pde" tab files are all nested to the sketch's unified top-class! :>

  • mmmh...
    therefore, is that right then? Class-Diagram

  • Yup, it seems so! =:)
    Although I guess Java uses a '$' char rather than a '.' to separate an enclosing class from its nested 1s! :-?

  • edited September 2014

    mmh ..perhaps this is still better?

    Diagram2:
    Class-Diagram2 or Diagram3:
    Class-Diagram3 http://processing.org/reference/javadoc/core/processing/core/PApplet.html

  • edited September 2014

    or perhaps this version: Diagram4: (is that right?) Class-Diagram4 :O

  • edited September 2014

    If you think about everything in Processing, down to the Java level, you'll go insane by the time you put all the features into something like the above.

    I suggest you just stick at most to the PApplet level, as the Java stuff is for the most part handled for you. Go no higher. (Unless, of course, you really want to.)

    And believe me. There is far more that goes into PApplet then those 3 methods. I will not motivate you to put the down.

  • edited September 2014

    Seems like Processing 3 is in the process of getting rid of Applet. Or it's already done! @-)
    Irony is that the PApplet name's gonna be kept after all, even though it's no an Applet anymore! :^o

    BtW, here's the source code for PApplet's callback functions setup(), draw() & mousePressed():

    https://github.com/processing/processing/tree/master/core/src/processing/core

    public void setup() {
    }
    
    public void draw() {
      finished = true;
    }
    
    public void mousePressed() {
    }
    

    As we can all notice, even though they're regular Java methods, they act more like abstract 1s that need to be @Override for any "sketch" inheriting them! (~~)

  • edited September 2014

    what is more correct? Diagram2, Diagram3 or Diagram5?

    @MenteCode:
    i don't understand your sentence (sry, my english is bad:/):

    I suggest you just stick at most to the PApplet level.

    can you say it with other words?

    There is far more that goes into PApplet then those 3 methods.

    i know, but i show only the methods which are in my sketch (see in code) ;)

    @GoToLoop:

    As we can all notice, even though they're regular Java methods, they act more like abstract 1s that need to be @Override for any "sketch" inheriting them!

    1. that means, that it is not abstract-connection?
    2. and the sketch has access to all class-files in processing.core?
    3. then the sketch is in the package processing.core? or in which package else?
  • attachment: Diagram5
    Class-Diagram5

  • edited September 2014
    1. that means, that it is not abstract-connection?
    2. and the sketch has access to all class-files in processing.core?
    3. then the sketch is in the package processing.core? or in which package else?


    1. In Java, abstract methods are a kinda contract between a parent class & its children.
      It means the children classes are obliged to implement those inherited methods by themselves.
      What I meant was that even though they're not abstract per se, they act as if they were so,
      b/c we should implement them in our "sketches" anyways!

    2. Well, a Processing "sketch" extends processing.core.PApplet class.
      So yes, they've got access to everything non-private that a PApplet got!

    3. Processing's IDE doesn't allow us to choose a package.
      So all "sketches" belong to a kinda "default" package!

  • edited September 2014

    I don't understand your sentence (sry, my English is bad :/ ):

    I suggest you just stick at most to the PApplet level.
    

    Can you say it with other words?

    He advises you to stop at PApplet and not go up from there for your own sanity's sake! =))

  • edited September 2014

    @2.

    Well, a Processing "sketch" extendsprocessing.corePApplet class.
    that means the connection between my sketch and the PApplet is correct?

    @3. ok, and what is this "default" package? --> is it this? https://github.com/processing/processing/tree/master/core/src/processing/core ...or only this processing.core.PApplet ?

    A) i also tryed this:

    sketch_140921a m;
    classA c;
    PFont font= createFont("Courier New Bold", 16);
    PImage img = new PImage ();
    
    void setup() {
      c= new classA();
      m = new sketch_140921a();
    
      println(
      "c(ClassA):\t\t"+c.getClass()
        +"\nimg(PImage):\t"+img.getClass()
        +"\nfont(PFont):\t"+font.getClass()
        +"\n----"
        +"\nthis.getClass:\t"+this.getClass()
        +"\nm.getClass:\t"+m.getClass()
        +"\nthis.getParent.getC:\t"+this.getParent().getClass()
        +"\nm.getParent:\t"+m.getParent()
        // +"\nm.getParent.getClas:\t"+m.getParent().getClass()
     // +"\nm.getPackage:\t\t"+m.getPackage()
        +"\nm.getPackage:\t"+m.getClass().getPackage()
      //  +"\nthis.getPackage:\t"+this.getPackage()
        +"\nthis.getPackage:\t"+this.getClass().getPackage()
    
      //  +"\nm:\t\t"+m.getParent().getPackage()
      //  +"\nm:\t\t"+m.getClass().getParent()
    
      );
    }
    
    void draw() {
    }
    void helloWorld() {
      println("hello World!");
    }
    void mousePressed() {
    }
    
    class classA {
      classA() {
      }
      void doSomething() {
      }
    }
    

    but i can not find any "default" package from my sketch.. ? somebodey an idea?
    the uncomment lines doesn't work.

    B) line 17 and 18 have different results. why?

    C) i don't understand it, yet. so: what is more correct? Diagram2, Diagram3, Diagram4 or Diagram5?

  • edited September 2014

    That means the connection between my sketch and the PApplet is correct?

    Diagram 4 seems more correct IMO!

    OK, and what is this "default" package?

    It's a nickname for when a particular class or interface doesn't affiliate to any package.
    Also, package names aren't inherited. Although a "sketch" is a PApplet, it doesn't belong to "processing.core"!
    Each class or interface can choose its own or none ("default")! O:-)

  • edited September 2014

    thanks GToLoop!
    i should it correct for my project in school ;)

    again (last (hope :D)): what is better:
    Diagram6:
    Class-Diagram6

    or Diagram7:
    Class-Diagram7
    ?

  • edited September 2014

    I'll go w/ diagram #6. Although I believe you should display the fact that PApplet's setup(), draw() & mousePressed() methods are all being overridden, that is reimplemented, @ its subclass sketch_142383a! :-?

  • edited September 2014

    thnks, ;)
    do you mean this? (see the part with the round arrow)
    Diagram8:

    Class-Diagram8

  • is that right? #-o

  • or is that right?
    Diagram9:
    Class-Diagram9

  • edited September 2014

    hello folks @-)

  • I've already said I'd prefer diagram #6!
    You should avoid mentioning methods & fields that aren't explicitly written in the sketch!

  • edited September 2014

    yes but my question was: how should i display this fact...

    you should display the fact that PApplet's setup(), draw() & mousePressed() methods are all being overridden

  • I dunno UML, hence dunno how's the right way to express polymorphism/method overriding! /:)
    Mebe just repeat the overridden methods inside the subclass w/ a minus sign or something! :-??

  • edited September 2014

    it is a public package-import? :-?
    then it is right to make a dashed arrow with << import >> (see Diagram9)
    :-?

Sign In or Register to comment.