<p>Yes, Greenfoot certainly has interfaces. I doubt that they would take them out. The people who built greenfoot are likely as appalled as I am about the College Board action on interfaces. But there is no UI element that specifically adds a new interface to a project. </p>

<p>But they may not appear in the same place that most classes do in the sidebar. Look at the bottom of the list. </p>

<p>Use the menu option to create a "New Class". Edit the resulting template to change it to a legal interface. Compile and save. This was with v 3.5. </p>

<p>You can do the same with other "class-like" things such as enumerations. The compiler hiding behind greenfoot is <em>all</em> of Java. </p>

<p>You can also go to <a href="https://greenroom.greenfoot.org" rel="nofollow noreferrer">https://greenroom.greenfoot.org</a> and ask such questions there (after joining). </p>

<p>Also, many of the labs that you find on both the greenfoot and greenroom sites will use interfaces. </p>

CC BY-SA 4.0
2019-08-26T20:40:40.947Z
Even though Greenfoot uses the BlueJ editor it has never had a "New Interface..." menu item. You must create a new class and change the class to interface, as Buffy says.  I have tested this with all versions from 3.04 thru 3.6.
Mr Bradley
CC BY-SA 4.0
2019-08-26T21:02:22.303Z
You can also create an interface (or other) with an external editor and import it from that same menu. There is actually a way to use Eclipse as an external editor for greenfoot if you don't like the built in one. Edit in eclipse and run in greenfoot. Once set up it is pretty straightforward.
Buffy
CC BY-SA 4.0
2019-08-26T19:24:15.963Z
2019-08-27T00:09:49.997Z
2019-08-27T00:09:49.997Z
Buffy
<p>One huge advantage to using Greenfoot is the visualization and interactive nature of the application. Using and demonstrating interfaces will take some work though.</p>

<p><strong>Anything</strong> that gets added to the world will be displayed and interacted with as it's <em>actual type</em> via the context menu. This can be confusing as students will be able to execute (via the context menu) all methods that are in its hierarchy: Object, Actor, ASubClass, etc. Even if the <em>declared type</em> is an interface.</p>

<p>On the other hand, when working programmatically the coder will be restricted to the methods defined by the <em>declared type</em> (<em>the interface</em>). This is very useful and worth demonstrating via code completion (ctrl+.) and compiler errors.</p>

<p>Using interfaces add clarity to the design and responsibility of classes in an application. This is a great lesson for students. </p>

<p>In a Greenfoot application most visible objects are Actors. In many applications programmers are making <strong>use</strong> of the World/Actor mechanism (by subclassing), yet these classes often have their own unique behavior and semantics that are separate and distinct from the Actor class and are only Actors to leverage the Greenfoot World/Actor architecture.</p>

<p>You will see these issues clearly if you create any scaffolded exercises or simulations of your own.</p>

<p>I use <a href="https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life" rel="nofollow noreferrer">Conway's Game Of Life</a> as a project for a few labs. The logic behind the simulation is very easy to understand and implement, and this allows the student to focus on design issues that interfaces help with. A cell can really only live or die; is represented by an Actor subclass; but should never be able to behave as one, ie move or rotate. <a href="https://drive.google.com/open?id=1Kl1TVb08HbQytifyT9jaQ1CoQuBCV8Ij" rel="nofollow noreferrer">See Demo</a>.</p>

<p><a href="https://csis.pace.edu/~bergin/KarelJava2ed/greenfoot.html" rel="nofollow noreferrer">Karel J Robot</a> is another good simulator that can used for labs (also available to educators via <a href="https://greenroom.greenfoot.org/door" rel="nofollow noreferrer">GreenRoom</a>), as can any tile-based game or application. The next demo is the introduction to interfaces lesson from the text book <em>A Gentle Introduction to Object Oriented Programming with Karel J Robot</em> where each contractor implements a Worker interface to build a part of the house. <a href="https://drive.google.com/open?id=1SerQ_OAesFIeU9YKEFZE97BDL6HXV8zn" rel="nofollow noreferrer">See Demo</a></p>

CC BY-SA 4.0
2019-08-27T00:52:45.730Z
Thanks for all of the detail! It sounds like Greenfoot isn't really designed to show Interfaces specifically, which was what I was beginning to suspect.  How much starter code do you provide for GoL?
Ben I.
CC BY-SA 4.0
2019-08-27T01:11:45.740Z
There is actually very little required.  The most difficult aspect is managing the state transition because all cells have to change simultaneously. So I show that piece in class.  When we move the solution to a MVC pattern (the universe has a separate model to maintain the state), I provide array copying methods. A large part of the lab is working within the iterative incremental build cycle. The core algorithm is provided by the wiki site.
Mr Bradley
CC BY-SA 4.0
2019-08-27T01:16:06.987Z
As a side note: comparing the execution speed and profiles between the two implementations is my lead in to Big-O and algorithm efficiency (space and time). I use the Java profiler and the students find that pretty cool - memory usage, heap size and the speed improvement is  phenomenal.
Mr Bradley
CC BY-SA 4.0
2019-08-26T22:07:18.013Z
2019-08-26T22:20:48.943Z
2019-08-26T22:20:48.943Z
Mr Bradley
<p>My colleague and I are considering bringing Greenfoot into our AP classes this year, and while Interfaces have been removed from the AP subset, we will continue to teach them.</p>

<p>Greenfoot itself seems to either not have, or to have thoroughly hidden, interfaces.  However, we are not interested in reinventing the wheel if it's not necessary.  Are there good lab activities that heavily feature interfaces already developed for Greenfoot?</p>

<p>Alternatively, are there any strong lab ideas for Greenfoot and interfaces that we could run with?</p>

CC BY-SA 4.0
2019-09-05T21:43:10.350Z
Interfaces are just a kludge in the java language, to allow polymorphism in the absence of multiple inheritance (The developers of Java did not know how to safely implement repeated inheritance, so eliminated multiple inheritance).
ctrl-alt-delor
CC BY-SA 4.0
2019-09-05T22:05:38.477Z
@ctrl-alt-delor I can't say as I agree with you there. Interfaces are more powerful than that, and used in plenty of places where any sort of inheritance would be inappropriate, such as iterators, or compareto.
Ben I.
CC BY-SA 4.0
2019-09-07T21:23:31.763Z
To make a class an iterator (or anything else): class A is an iterator. Is an example of polymorphism. (so **exactly** as **un**-powerful as I stated). And full inheritance is totally appropriate. It is just banned in Java, and can be dangerous in C++ (but only if repeated (not just multiple) inheritance). There are languages that make even repeated inheritance safe.
ctrl-alt-delor
CC BY-SA 4.0
2019-09-08T02:29:17.510Z
@ctrl-alt-delor I suppose we'll have to agree to disagree here.  Interfaces are lightweight, versatile, and allow the compiler to do important work for you. Using inheritance to make your iterators seems like an odd idea.  My n-ary tree, my 3-dimensional jagged array, and my spanning tree should implement Iterator completely differently.  The only thing that my foreach loop needs to know is that they can iterate.  I'm not aware of any language that is statically typed, but does not support interfaces (or abstract classes, which gets you the same thing).
Ben I.
CC BY-SA 4.0
2019-09-08T02:34:14.140Z
@ctrl-alt-delor Even Python added a module for abstract classes, and it's dynamically typed, so there is nominally no need for it.
Ben I.
CC BY-SA 4.0
2019-09-08T19:57:27.713Z
Yes it seem like an odd idea, because java invented an inferior way. However I am not discussing a language that does not support interfaces (no a inferior thing). I am saying that one does not need an interface keyword (with limited functionality to implement interfaces). One should be able to use classes, to create: interfaces (you can do this in java, but can only inherit one); interfaces with pre/post/invariant conditions; interfaces with some functionality. And to have multiple inheritance e.g. A inherits B, and comparable, and ...
ctrl-alt-delor
CC BY-SA 4.0
2019-09-08T20:03:07.540Z
Comparable should be allowed to implement `<`, `>`, `<=`, `>=`, `==`, and `!=`. with out having to write a tonne of code. One should just have to write say `<` for each implementation. In addition the compiler should do important work for you (optimisation), you should not have to use special devices (`interface`) to get the compiler to optimise. A pure abstract class, should be as light as an interface would have been. Classes that are not used polymorphic should be called statically (optimisation). Inheritance chains, and call chains should be flattened where possible.
ctrl-alt-delor
CC BY-SA 4.0
2019-09-08T21:08:19.667Z
@ctrl-alt-delor Of course Java does this now.  Since Java 8(?), you can put default code in interfaces, and that code will be inherited.  As to `<`, `<=`, etc, you can easily extend an interface with another broader interface to accomplish both `Comparable` and `FullyComparable`.  I'm honestly not that sourfaced about lacking operator overloads.  They can be nice, but they're just syntactic sugar, and they can also be abused to make code less clear.  Don't get me wrong, I'd like to have them available, but it's not something I get too fussed about.
Ben I.
CC BY-SA 4.0
2019-09-13T22:15:29.083Z
the operator over loading was just an example. I will look at what you say about interfaces being allowed default code (sounds like classes).
ctrl-alt-delor
<ap-computer-science-a><interface>
Interfaces and Greenfoot
# Interfaces and Greenfoot

(Asked by: username_0 on 2019-08-26)

My colleague and I are considering bringing Greenfoot into our AP classes this year, and while Interfaces have been removed from the AP subset, we will continue to teach them.

Greenfoot itself seems to either not have, or to have thoroughly hidden, interfaces. However, we are not interested in reinventing the wheel if it's not necessary. Are there good lab activities that heavily feature interfaces already developed for Greenfoot?

Alternatively, are there any strong lab ideas for Greenfoot and interfaces that we could run with?

**Tags:** ap-computer-science-a, interface

> **Comments:**
> **username_1**: Interfaces are just a kludge in the java language, to allow polymorphism in the absence of multiple inheritance (The developers of Java did not know how to safely implement repeated inheritance, so eliminated multiple inheritance).  
> **username_0**: @username_1 I can't say as I agree with you there. Interfaces are more powerful than that, and used in plenty of places where any sort of inheritance would be inappropriate, such as iterators, or compareto.  
> **username_1**: To make a class an iterator (or anything else): class A is an iterator. Is an example of polymorphism. (so **exactly** as **un**-powerful as I stated). And full inheritance is totally appropriate. It is just banned in Java, and can be dangerous in C++ (but only if repeated (not just multiple) inheritance). There are languages that make even repeated inheritance safe.  
> **username_0**: @username_1 I suppose we'll have to agree to disagree here.  Interfaces are lightweight, versatile, and allow the compiler to do important work for you. Using inheritance to make your iterators seems like an odd idea.  My n-ary tree, my 3-dimensional jagged array, and my spanning tree should implement Iterator completely differently.  The only thing that my foreach loop needs to know is that they can iterate.  I'm not aware of any language that is statically typed, but does not support interfaces (or abstract classes, which gets you the same thing).  
> **username_0**: @username_1 Even Python added a module for abstract classes, and it's dynamically typed, so there is nominally no need for it.  
> **username_1**: Yes it seem like an odd idea, because java invented an inferior way. However I am not discussing a language that does not support interfaces (no a inferior thing). I am saying that one does not need an interface keyword (with limited functionality to implement interfaces). One should be able to use classes, to create: interfaces (you can do this in java, but can only inherit one); interfaces with pre/post/invariant conditions; interfaces with some functionality. And to have multiple inheritance e.g. A inherits B, and comparable, and ...  
> **username_1**: Comparable should be allowed to implement `<`, `>`, `<=`, `>=`, `==`, and `!=`. with out having to write a tonne of code. One should just have to write say `<` for each implementation. In addition the compiler should do important work for you (optimisation), you should not have to use special devices (`interface`) to get the compiler to optimise. A pure abstract class, should be as light as an interface would have been. Classes that are not used polymorphic should be called statically (optimisation). Inheritance chains, and call chains should be flattened where possible.  
> **username_0**: @username_1 Of course Java does this now.  Since Java 8(?), you can put default code in interfaces, and that code will be inherited.  As to `<`, `<=`, etc, you can easily extend an interface with another broader interface to accomplish both `Comparable` and `FullyComparable`.  I'm honestly not that sourfaced about lacking operator overloads.  They can be nice, but they're just syntactic sugar, and they can also be abused to make code less clear.  Don't get me wrong, I'd like to have them available, but it's not something I get too fussed about.  
> **username_1**: the operator over loading was just an example. I will look at what you say about interfaces being allowed default code (sounds like classes).  

---

## 2 answers

### Answer by username_2 on 2019-08-26. Score: 2

Yes, Greenfoot certainly has interfaces. I doubt that they would take them out. The people who built greenfoot are likely as appalled as I am about the College Board action on interfaces. But there is no UI element that specifically adds a new interface to a project.

But they may not appear in the same place that most classes do in the sidebar. Look at the bottom of the list.

Use the menu option to create a "New Class". Edit the resulting template to change it to a legal interface. Compile and save. This was with v 3.5.

You can do the same with other "class-like" things such as enumerations. The compiler hiding behind greenfoot is *all* of Java.

You can also go to <https://greenroom.greenfoot.org> and ask such questions there (after joining).

Also, many of the labs that you find on both the greenfoot and greenroom sites will use interfaces.

> **Comments:**
> **username_3**: Even though Greenfoot uses the BlueJ editor it has never had a "New Interface..." menu item. You must create a new class and change the class to interface, as username_2 says.  I have tested this with all versions from 3.04 thru 3.6.  
> **username_2**: You can also create an interface (or other) with an external editor and import it from that same menu. There is actually a way to use Eclipse as an external editor for greenfoot if you don't like the built in one. Edit in eclipse and run in greenfoot. Once set up it is pretty straightforward.  

---

### Answer by username_3 on 2019-08-26. Score: 2

One huge advantage to using Greenfoot is the visualization and interactive nature of the application. Using and demonstrating interfaces will take some work though.

**Anything** that gets added to the world will be displayed and interacted with as it's *actual type* via the context menu. This can be confusing as students will be able to execute (via the context menu) all methods that are in its hierarchy: Object, Actor, ASubClass, etc. Even if the *declared type* is an interface.

On the other hand, when working programmatically the coder will be restricted to the methods defined by the *declared type* (*the interface*). This is very useful and worth demonstrating via code completion (ctrl+.) and compiler errors.

Using interfaces add clarity to the design and responsibility of classes in an application. This is a great lesson for students.

In a Greenfoot application most visible objects are Actors. In many applications programmers are making **use** of the World/Actor mechanism (by subclassing), yet these classes often have their own unique behavior and semantics that are separate and distinct from the Actor class and are only Actors to leverage the Greenfoot World/Actor architecture.

You will see these issues clearly if you create any scaffolded exercises or simulations of your own.

I use [Conway's Game Of Life](https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life) as a project for a few labs. The logic behind the simulation is very easy to understand and implement, and this allows the student to focus on design issues that interfaces help with. A cell can really only live or die; is represented by an Actor subclass; but should never be able to behave as one, ie move or rotate. [See Demo](https://drive.google.com/open?id=1Kl1TVb08HbQytifyT9jaQ1CoQuBCV8Ij).

[Karel J Robot](https://csis.pace.edu/~bergin/KarelJava2ed/greenfoot.html) is another good simulator that can used for labs (also available to educators via [GreenRoom](https://greenroom.greenfoot.org/door)), as can any tile-based game or application. The next demo is the introduction to interfaces lesson from the text book *A Gentle Introduction to Object Oriented Programming with Karel J Robot* where each contractor implements a Worker interface to build a part of the house. [See Demo](https://drive.google.com/open?id=1SerQ_OAesFIeU9YKEFZE97BDL6HXV8zn)

> **Comments:**
> **username_0**: Thanks for all of the detail! It sounds like Greenfoot isn't really designed to show Interfaces specifically, which was what I was beginning to suspect.  How much starter code do you provide for GoL?  
> **username_3**: There is actually very little required.  The most difficult aspect is managing the state transition because all cells have to change simultaneously. So I show that piece in class.  When we move the solution to a MVC pattern (the universe has a separate model to maintain the state), I provide array copying methods. A large part of the lab is working within the iterative incremental build cycle. The core algorithm is provided by the wiki site.  
> **username_3**: As a side note: comparing the execution speed and profiles between the two implementations is my lead in to Big-O and algorithm efficiency (space and time). I use the Java profiler and the students find that pretty cool - memory usage, heap size and the speed improvement is  phenomenal.  

---

