I am looking for a nice reading for students about using delegates instead of inheritance.
-
@inthehands I forget how jarring the square brackets are for people LoL
-
@griotspeak
Yeah, they’d have a hope if it’s Swift, but if it’s Obj-C they’re done -
Jenniferplusplusreplied to Paul Cantrell last edited by
@inthehands This sounds like dependency injection? Is that what you're looking for?
-
Paul Cantrellreplied to Jenniferplusplus last edited by
@jenniferplusplus
Not exactly, but related. Underlying mechanism is the same: depend on interface, someone else provides impl.DI is closely associated with testability, and is often used to replace an A→B dependency that could have been an explicit constructor call from A but instead you hide the impl of B (thus the “injection,” libs to allow swapping impls via configuration, etc).
1/2
-
Paul Cantrellreplied to Paul Cantrell last edited by [email protected]
@jenniferplusplus The delegate pattern is for A→B patterns where B is tightly coupled to the •client• of A, e.g. A is a table view UI element and B provides the data to show in the table. Think callbacks, but expanded to have multiple entry points and possibly be stateful.
(All hastily explained, hope not totally confusing)
2/2
-
Jenniferplusplusreplied to Paul Cantrell last edited by
@inthehands I guess I still don't see what the difference is. If you have some class, like:
class TableView : UIElement
{
new (ITableDataDelegate td)
public void RenderElement()
}Does that provide the behavior you're looking for?
-
Paul Cantrellreplied to Jenniferplusplus last edited by
@jenniferplusplus
For sure! The difference is just intent / vibes. With DI, there’s a whole thing of having some kind of framework that lets you dynamically resolve the implementing class, maybe based on config or whether you’re in test mode or whatever. That whole role of the “injector” does not exist (and doesn’t make sense) for the delegate pattern.(Problem here may be that DI is an idea that’s drifted a lot, and means many things to many people.)
-
@jenniferplusplus
Another way to highlight the diff: the alternative to DI is usually an explicit constructor call; the alternative to a delegate is usually an abstract class with a subclass. -
@inthehands are you specifically staying away from the gang of four Design Patterns book?
-
@steveloranz
It’s definitely under consideration! Just getting the lay of the land, looking for favorites I might have missed. -
@inthehands yeah, I think in terms of generic description of the pattern, they do the best job with NeXT/Apple providing arguably the best examples of implementation, even if you just look at how their apis are organized. I'm a big fan of the ‘somethingIsAboutToHappen' and ‘somethingJustHappened' way they use delegation. I tried to recreate this as best I could in Python 2 years ago in a project called ImageFactory.
-
@steveloranz
Yeah, that aspect of NeXTStep’s legacy is a really solid one, too oft overlooked. -
@inthehands chapter one of Head First Design Patterns is about this. They build out an example using inheritance to share behaviour, then go to using composition instead, arguing why composition is usually better
IMO, it's the most approachable and best programming design book out there
-
@aidanharding
Oh, that sounds like exactly what I’m after and I don’t know the book! Will investigate.