Return to Answer

Just tell them you are trying to explain an important aspect of things, and you have to simplify a bit.

I'm preparing a lecture about iterators in Java, so I use that example. I tell student that iterable objects must have an iterator method in order to implement the Iterable generic interface

interface Iterable<T> {
    Iterator<T> iterator();
    ...
}

and iterators have next and hasNext

interface Iterator<T> {
   boolean hasNext();
   T       next();
   ...
}

That's all I want to explain. I dont oversimplify, but I don't want to say a word about forEach and remove and blood-thirsty spliterators from jurassic park at this point. If some students read the documentation and ask questions, I point them to the ellipsis.

But I make clear there are other things, not to be discussed now.

About interfaces, what about telling they were mostly intended to list methods to be implemented by concrete classes? It doesn't exclude the presence of other things in the interface.

At some point, but much later, it can be interesting to explain why default methods were introduced in Java, whereas it seems a contradiction with their initial intent.

To put it simply, lots of existing code uses the same standard interfaces as, for example, the collections. New features were added to collections interface, like forEach. But it was not reasonable to ask customers provide implementations of forEach for all their existing classes. So language designers went by that tradeoff.

Just tell them you are trying to explain an important aspect of things, and you have to simplify a bit.

I'm preparing a lecture about iterators in Java, so I use that example. I tell student that iterable objects must have an iterator method in order to implement the Iterable generic interface

interface Iterable<T> {
    Iterator<T> iterator();
    ...
}

and iterators have next and hasNext

interface Iterator<T> {
   boolean hasNext();
   T       next();
   ...
}

That's all I want to explain. I don't oversimplify, but I don't want to say a word about forEach and remove and blood-thirsty spliterators from Jurassic Park at this point. If some students read the documentation and ask questions, I point them to the ellipsis.

But I make clear there are other things, not to be discussed now.

About interfaces, what about telling they were mostly intended to list methods to be implemented by concrete classes? It doesn't exclude the presence of other things in the interface.

At some point, but much later, it can be interesting to explain why default methods were introduced in Java, whereas it seems a contradiction with their initial intent.

To put it simply, lots of existing code uses the same standard interfaces as, for example, the collections. New features were added to collections interface, like forEach. But it was not reasonable to ask customers provide implementations of forEach for all their existing classes. So language designers went by that tradeoff.

Just tell them you are trying to explain an important aspect of things, and you have to simplify a bit.

I'm preparing a lecture about iterators in Java, so I use that example. I tell student that iterable objects must have an iterator method in order to implement the Iterable generic interface

interface Iterable<T> {
    Iterator<T> iterator();
    ...
}

and iterators have next and hasNext

interface Iterator<T> {
   boolean hasNext();
   T       next();
   ...
}

That's all I want to explain. I dont oversimplify, but I dont telle a word about forEach and remove and blood-thirsty spliterators from jurassic park at this point. If some read the documentation and ask questions, I point them to the ellipsis.

But I make clear there are other things, not to be discussed now.

About interfaces, what about telling they were mostly intended to list methods to be implemented by concrete classes? It doesn't exclude the presence of other things in the interface.

At some point, but much later, it can be interesting to explain why default methods were introduced in Java, whereas it seems a contradiction with their initial intent.

To put it simply, lots of existing code uses the same standard interfaces as, for example, the collections. New features were added to collections interface, like forEach. But it was not reasonable to ask customers provide implementations of forEach for all their existing classes. So language designers went by that tradeoff.

Just tell them you are trying to explain an important aspect of things, and you have to simplify a bit.

I'm preparing a lecture about iterators in Java, so I use that example. I tell student that iterable objects must have an iterator method in order to implement the Iterable generic interface

interface Iterable<T> {
    Iterator<T> iterator();
    ...
}

and iterators have next and hasNext

interface Iterator<T> {
   boolean hasNext();
   T       next();
   ...
}

That's all I want to explain. I dont oversimplify, but I don't want to say a word about forEach and remove and blood-thirsty spliterators from jurassic park at this point. If some students read the documentation and ask questions, I point them to the ellipsis.

But I make clear there are other things, not to be discussed now.

About interfaces, what about telling they were mostly intended to list methods to be implemented by concrete classes? It doesn't exclude the presence of other things in the interface.

At some point, but much later, it can be interesting to explain why default methods were introduced in Java, whereas it seems a contradiction with their initial intent.

To put it simply, lots of existing code uses the same standard interfaces as, for example, the collections. New features were added to collections interface, like forEach. But it was not reasonable to ask customers provide implementations of forEach for all their existing classes. So language designers went by that tradeoff.

Just tell them you are trying to explain an important aspect of things, and you have to simplify a bit.

I'm preparing a lecture about iterators in Java. I tell student that iterable objects must have an iterator method in order to implement the Iterable generic interface

interface Iterable<T> {
    Iterator<T> iterator();
    ...
}

and iterators have next and hasNext

interface Iterator<T> {
   boolean hasNext();
   T       next();
   ...
}

That's all I want to explain. So not a word about forEach and remove and blood-thirsty spliterators from jurassic park at this point.

But I don't hide there are other things.

Just tell them you are trying to explain an important aspect of things, and you have to simplify a bit.

I'm preparing a lecture about iterators in Java, so I use that example. I tell student that iterable objects must have an iterator method in order to implement the Iterable generic interface

interface Iterable<T> {
    Iterator<T> iterator();
    ...
}

and iterators have next and hasNext

interface Iterator<T> {
   boolean hasNext();
   T       next();
   ...
}

That's all I want to explain. I dont oversimplify, but I dont telle a word about forEach and remove and blood-thirsty spliterators from jurassic park at this point. If some read the documentation and ask questions, I point them to the ellipsis.

But I make clear there are other things, not to be discussed now.

About interfaces, what about telling they were mostly intended to list methods to be implemented by concrete classes? It doesn't exclude the presence of other things in the interface.

At some point, but much later, it can be interesting to explain why default methods were introduced in Java, whereas it seems a contradiction with their initial intent.

To put it simply, lots of existing code uses the same standard interfaces as, for example, the collections. New features were added to collections interface, like forEach. But it was not reasonable to ask customers provide implementations of forEach for all their existing classes. So language designers went by that tradeoff.