Bill is a liability.
Bill is a liability.
Nice video about it here : https://youtu.be/cZLed1krEEQ
Tldw: US DOS version actually has 2 separate impossible jumps on a level that aren’t present on the European DOS or NES versions.
I’m somewhat confused by your statements, so perhaps I don’t understand.
Function/objects that allow changing their behavior by passing different objects into them, based on some interface, is called dependency injection. Some subset of behavior is determined by this passed behavior. E.g. To keep a logger class from having to understand how to write logs, you could create a WriteTo interface and various implementations like WriteToDatabase, WriteToFile, WriteToStdout, WriteToNull.
When you create this example logger, you’ll need to make a choice of what object to pass when you write the code. e.g. new Logger(new WriteToDatabase(config))
But maybe you don’t want to make that decision yet – you want to let a config file decide which writer(s) to create. The pattern to pick between dependencies at runtime is called a factory. In this case, you might make a WriterFactory to pick the right writer, or perhaps a LoggerFactory to hide the creation of both Writer and Factory objects.
So, a factory is only really a facade to hide the runtime switching of how an object is created.
Also, the term dependency injection often gets confused with what you see in various Java / C# / and various frameworks in other languages – those usually use what’s called a “DI Container” or “IoC Container”. These manage and facilitate how dependency injection happens within the project, often with various annotations (e.g.@Autowired
). These containers are powerful, but sometimes complicated.
However, you can absolutely still do DI without DI containers, and I think advocating for not using DI generally (and related patterns like factories) is rather misguided.
The opposite actually happened to me. PHP was my first non-intern position. That company eventually started working with Java, so I made that transition when they did.
Null is terrible.
A lot of languages have it available as a valid return value for most things, implicitly. This also means you have to do extra checking or something like this will blow up with an exception:
// java example // can throw exception String address = person.getAddress().toUpperCase(); // safe String address = ""; if (person.getAddress() != null) { person.getAddress().toUpperCase(); }
There are a ton of solutions out there. Many languages have added null-coalescing and null-conditional operators – which are a shorthand for things like the above solutions. Some languages have removed the implicit nulls (like Kotlin), requiring them to be explicitly marked in their type. Some languages have a wrapper around nullable values, an Option type. Some languages remove null entirely from the language (I believe Rust falls into this, using an option type in place of).
Not having null isn’t particularly common yet, and isn’t something languages can just change due to breaking backwards compatibility. However, languages have been adding features over time to make nulls less painful, and most have some subset of the above as options to help.
I do think Option types are fantastic solutions, making you deal with the issue that a none/empty type can exist in a particular place. Java has had them for basically 10 years now (since Java 8).
// optional example Class Person { private String address; //prefer this if a null could ever be returned public Optional<String> getAddress() { return Optional.ofNullable(address); } // not this public String getAddress() { return address; }
When consuming, it makes you have to handle the null case, which you can do a variety of ways.
// set a default String address = person.getAddress().orElse("default value"); // explicitly throw an exception instead of an implicit NullPointerException as before String address = person.getAddress().orElseThrow(SomeException::new); // use in a closure only if it exists person.getAddress().ifPresent(addr -> logger.debug("Address {}", addr)); // first example, map to modify, and returning default if no value String address = person.getAddress().map(String::toUpperCase).orElse("");