In Don Norman’s seminal work “The Design of Everyday Things”, the author coined the phrases and explains the difference between “Knowledge in the World” and “Knowledge In Your Head”; an example of this is a multi-switch light panel that can either incorporate “Knowledge in the World” by being a model/map of the room, with the switches in the corresponding location, or “Knowledge In Your Head” (which is how they are almost always designed/implemented) when you have to memorize which switch toggles which light.
You could think of “Knowledge in the World” as something you can deduce by using observation and logic, and “Knowledge in your Head” as something that has to be memorized.
In the world of DI, and “Auto-Registration,” which relies on the “Convention Over Configuration” pattern, would using this process be a case of the programmer using “Knowledge in the World” (the functionality is expected, as the framework provides it) or is it “Knowledge In Your Head” (the programmer has to be aware of and learn the convention).
I am taking the wishy-washy/middle-of-the-road view that Convention Over Configuration is a midway world twixt the two.
Am I wrong?
1
Convention Over Configuration is pretty much by definition “Knowledge in the World” – the convention is always meant to be so “obvious” that you don’t have to learn much: things like having URLs automatically mapped to controller classes and DB tables to model classes. The same for auto-registration DI – you have objects automatically instantiated and injected into others based on naming conventions. It “just works”.
Of course, the problem is that in practice it’s not always (and almost never in sufficiently large systems) that simple. You have special requirements and edge cases not covered by the conventions, and it stops working. The problem then is that all this “magic” you’re supposed to depend on is opaque to you and relies on mechanisms that are quite complex by themselves. And you have to invest a lot of time to learn how it works so you can make it work the way you need and fix it when it breaks. And then it has become “Knowledge in your head”.
But in a well-designed and correctly-used system, this should be rare enough that it’s still worthwhile.
4
Although Convention over Configuration is supposed to be ‘Knowledge in the World’ it invariably isnt.
public class MyController(IMyService service)...
public class DefaultService : IMyService...
public class ASpecialService: IMyService...
Which service is used?
How do you acquire that knowledge?
“Knowledge in the world”: mostly by experience and conventions. In your switch example, you know already what a plan is and how to map it to the actual room.
“Knowledge in your head”: mostly by experimentation – in the switch example, you try them.
From that perspective, convention over configuration is definitely “knowledge in the world”.
(Note that while most house switches end up ‘knowledge in your head’, they still respect some ‘knowledge in the world’ conventions such as being – generally – in the same room as the lights and – if your electrician is any good – roughly ordered like the lights in a multi switch configuration)