I use extended supers precisely because it has that brittle nature to it. Expecting subclasses to not have or have the wrong implementations and overrides. Essentially a glorified error generator and pattern enforcement tool (complexity enforcement). Downside is that those supers are fixed. They do not, nor should ever change only substituted and deprecated. Substitution of supers, while a bit consuming, is a very viable way to deal with it if you have well defined boundaries. That, if you still require the error machine.
By implementing the IEmployeeExporter interface. Back up and read the UML diagram on slide 26, @49:25. The Employee class knows how to export using an IEmployeeExporter. HtmlBuilder, JsonBuilder, WidgetBuilder etc need to implement the IEmployeeExporter class. You still have to write the code to implement IEmployeeExporter when you switch from e.g. JSON to YAML, but the point is that you just have to implement those interfaces, you don't have to open up and fiddle with the Employee class. And Holub describes other benefits too: if I *do* have to change Employee class in such a way that I am forced to change IEmployeeExporter, then at least the compiler will help me see which concrete implementations (e.g. maybe WidgetBuilder and JsonBuilder etc) I need to go back and re-implement.
Allen shows issues with single inheritance in Java, and alternatives using interfaces and delegation. Java fortunately does not support multiple inheritance of Classes and I think it would be hard to use without violating most of the SOLID principles anyway.
I use extended supers precisely because it has that brittle nature to it. Expecting subclasses to not have or have the wrong implementations and overrides. Essentially a glorified error generator and pattern enforcement tool (complexity enforcement).
Downside is that those supers are fixed. They do not, nor should ever change only substituted and deprecated. Substitution of supers, while a bit consuming, is a very viable way to deal with it if you have well defined boundaries. That, if you still require the error machine.
50:15 this is a bit confusing. How do the importers/exporters know how to import/export that particular object?
By implementing the IEmployeeExporter interface.
Back up and read the UML diagram on slide 26, @49:25.
The Employee class knows how to export using an IEmployeeExporter. HtmlBuilder, JsonBuilder, WidgetBuilder etc need to implement the IEmployeeExporter class.
You still have to write the code to implement IEmployeeExporter when you switch from e.g. JSON to YAML, but the point is that you just have to implement those interfaces, you don't have to open up and fiddle with the Employee class.
And Holub describes other benefits too: if I *do* have to change Employee class in such a way that I am forced to change IEmployeeExporter, then at least the compiler will help me see which concrete implementations (e.g. maybe WidgetBuilder and JsonBuilder etc) I need to go back and re-implement.
Allen shows issues with single inheritance in Java, and alternatives using interfaces and delegation.
Java fortunately does not support multiple inheritance of Classes and I think it would be hard to use without violating most of the SOLID principles anyway.