You're right in saying that a class shouldn't expose its internals, even to subclasses. I try to stick with that; when designing an abstract class, I make a mental note of what's (more or less) in the box and what's out.
Real-life example: an HTTP "servlet" base class may expose a "current_request" method to subclasses (so they can grab form parameters and stuff), but they shouldn't redefine the template method "handle_request" unless they have a very good reason.
Talking about mixins, they aren't a strictly internal thing. For example, in Ruby you can make your own collection class, which mixes in Enumerable. Then, after you define the "each" iterator for your class, you get all other iterators (collect, inject, delete_if etc.) for free. If you also define a meaningful comparison method, you magically get the "sort". And for purposes of any application, your collections become interchangeable with native Ruby arrays (were you asking about "conversion to a mixin type"?)
Regarding entities and objects: no offense intended, but numbers and shapes are textbook examples and not really useful. You just shouldn't go OO with rectangles and squares, it's not the point of OO.
One pretty common mistake of Java is that it makes programmers define anonymous methods and classes where they actually need to define a closure, or curry a function, etc. Let's say you're designing a GUI and want to create a button with a callback. Yeah, the Java designer says, let's subclass Button or whatever. But a Ruby/Smalltalk-style closure would be more suited to the task:
gui.addButton("Push Me") do //insert code here that will execute when button is pushed end
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2004-06-02 01:06 pm (UTC)Real-life example: an HTTP "servlet" base class may expose a "current_request" method to subclasses (so they can grab form parameters and stuff), but they shouldn't redefine the template method "handle_request" unless they have a very good reason.
Talking about mixins, they aren't a strictly internal thing. For example, in Ruby you can make your own collection class, which mixes in Enumerable. Then, after you define the "each" iterator for your class, you get all other iterators (collect, inject, delete_if etc.) for free. If you also define a meaningful comparison method, you magically get the "sort". And for purposes of any application, your collections become interchangeable with native Ruby arrays (were you asking about "conversion to a mixin type"?)
Regarding entities and objects: no offense intended, but numbers and shapes are textbook examples and not really useful. You just shouldn't go OO with rectangles and squares, it's not the point of OO.
One pretty common mistake of Java is that it makes programmers define anonymous methods and classes where they actually need to define a closure, or curry a function, etc. Let's say you're designing a GUI and want to create a button with a callback. Yeah, the Java designer says, let's subclass Button or whatever. But a Ruby/Smalltalk-style closure would be more suited to the task:
gui.addButton("Push Me") do
//insert code here that will execute when button is pushed
end