08:30 All of your test flakiness will come from some form of uncontrolled global state. 10:20 Singleton with capital ’S’. Refers to the design pattern where the Singleton has a private constructor and has a global instance variable. Lowercase ’s’ singleton means I only have a single instance of something because I only called the new operator once. 11:44 Singleton pattern is bad because it introduces potentially infinite global variables. 13:00 If global variables are bad… how can Singletons be good? (They can't & aren't good.) 15:10 How do I assert that a method in my class calls another method on a singleton? You can’t. There’s no seams. Instead, you need to instantiate the class under test and the instantiation of its dependencies. 18:54 Deceptive API. Singletons hide the details. There’s hidden dependencies. You can have unexpected side effects. 25:00 Dependency injection orders code naturally. A class will explicitly declare its dependencies. And it enforces correct order of method calls/setup. 29:10 Review: - Global state is the root of 90% of your testing problems - Global state can’t be controlled by tests - Singleton pattern is just global state Q&A 32:00 Q: Without a Singleton I have to pass a dependency all the way down a long chain and that seems excessive. Isn’t that bad? A: That’s a myth. Let’s say you have a database and you instantiate it all the way in your main method. Wouldn’t you have to then pass it all the way down? No you don’t. You need to change the way you structure you code. You probably mix object instantiation with business logic. Instead, you should have a factory that knows how to create and wire up all the dependencies. 36:28 Q: Isn’t a ‘House’ factory inconvenient because then you have to pass thousands of things into the method? A: If House needs 1000 things then your house has a design problem because it has too many responsibilities. You need to decompose and re-structure your classes.
What he's basically saying is you should try to make everything as reentrant as possible. It always amazes me that in the end, with all these new fancy programming languages and paradigms, the fact is the only thing that matters is achieving high cohesion and low coupling, which is heavily discussed in the 70s, and us young whippersnappers are reinventing the broken wheel.
Yet there have been many books are articles pushing service locators and they are still used extensively because they're easy and don't make you seriously think about the structure of your application. The talk is warranted.
Us young whippersnappers don't approach programming as a mathematical discipline. The moment we have to start writing proofs for our software, most of us will quit.
This talk is seriously excellent. It leads me to believe that we really don't need the static keyword at all. We ought to be careful to not confuse pragmatism with laziness.
You completely need to use static classes and methods in some situations. Suppose you want to load/save a file with specific format (the language or framework does not have any lib for it) or you want to show some messageBox. You do not intend to send them as parameters to constructors for every new object!!!
What I liked about this talk is that he pointed out that classes at the bottom do not have to use DI. It was just one sentence, but was probably worthy of several minutes.
It reminds me of clean architecture or onion architecture. The class in the bottom are domain objects. They are VALUE objects. DI-able objects are on the outside in infrastructure layer and such.
36:30 The natural tendency of us humans is to resist new ideas, specially those that contradict our currently held beliefs or practices. In this case there is an implicit supposition of the questioner which is that having a class with a big number of dependencies is not an indication of bad design. I'm glad how clear Misko's explanation is about how DI does not imply having to complicate the constructor of classes.
For example the idea in the end that the framework imposes global states for file I/O, DateTime.Now and random numbers is really interesting because that's very common pain point when doing tests. The suggestion by one of the participant in the end, to use adapter objects to access those global state is a very good solution. For example it is a breath to test code depending on timing when passing a 'clock' object as a mock and manipulating time in the test, so that for example instead of waiting for a second, you can increment the clock object a second and continue running the test without waiting ;-) Same for testing math code using randomness, using a mock rng is super useful to manipulate precisely the number served to the algorithm.
It is impressive how ppl are averse to changing their mind, despite all the good examples the talker gives to them and the benefits of dependency injection seem like everyone is fighting him! I would like to see those ppl writing some unit tests, that should be something to watch. Like 20 mocks for each test. cheating all the statics variable and so on... Very nice talk!!!
I agree. The speaker is great and knows what he's talking about. Strange that people a reluctant to listen, because "hey, I don't design my own code this way".
Stateless singletons don't have these problems, but they simultaneously lack any real relevance - if there's no state, why would you care if there's one instance or fifteen instances? Especially since stateless objects tend to be rather small, with inexpensive constructors.
It's not that singletons themselves are bad but the GOF design pattern is. The only really argument that is valid is that the GOF design pattern doesn't lend itself in regards to testing, especially if tests are run in parallel.
Agreed, I often find terminology to be a big of a problem as the program itself. To clarify, to me "global state" means any variable with a state that might change at any moment due to any part of the application, the most common unavoidable example being a connection to a database, some external service or environmental variables, hence what I meant by learning to work with global state instead of just minimizing it.
About Dependency Injection: Like someone [kinda] asked, If a house have a dozen dependencies, each of these have a dozen dependencies, and so on. The we would have a psychopathic Factory for a house? (Just some numbers if it was exactly 12 dependencies: Two layers is 144, three is 1728) How would we handle that?
+Martin Dilling-Hansen I actually think this was the actual question and the talker misunderstood it. The thing is, when you don't use dependency injection all 1728 dependencies are still there somewhere in the application and you just don't see it, by using dependency injection they all suddenly become explicit and now you are stuck with instantiating 1728 objects before you can run tet code... but not really, first, realize that when you are testing you most likely will use mocking dependencies instead of the real dependencies, and the mocks won't have further dependencies, that means, in tests, you will only need to instantiate the next layer of dependencies for this application which are 12 objects, the real application will remain basically the same, but will be reorganized so that the dependencies are concentrated in the factories/injector
Very interesting and thought-provoking talk. There's still something I don't quite understand. It's basically the question the first person asked: how to handle a resource which is universally required by all (or most) of the classes in an application. Such as a logger, which any class might need to write to. The speaker changed the questioner's example to a database, which is less universal and therefore changed the question somewhat. If I want every class to have access to a Logger, does that mean that every class needs a factory class to create instances of it which explicitly references the Logger via DI? Does every instance of every class need to hold a reference to the Logger? That seems like a lot of overhead. The way I've always handled things like that is with a globally accessible static class, but that goes against the speaker's main thesis. I wonder if the speaker would allow exceptions in these cases, or if there's another solution.
There are a couple options. First, you wouldn't likely use a factory because you would only have a single logger instance created at the composition root. That instance could be passed to every class through the constructor. If you don't like your constructor getting polluted, you could use parameter injection and pass your logger in through a public method, and assign a NullLogger instance by default. Lastly, the cleanest approach would be to use a proxy class to intercept your method calls so the class itself has no knowledge of the logger at all.
@blenderpanzi Actually it's not at all about side effects. Side effects do not present a big problem to testability of code, but global state (global side effects) does.
Singletons are not evil. In fact, they solve a ton of problems, but as with all things, there is tradeoffs. I am programming games, and I have at least 20 singletons, graphics system, physics system, networking, sound, controllers, etc,etc,etc. Singletons here, in this specific case, make the code much faster, more testable and simpler to use. The key idea is to have a central location that can actually control all other singletons if needed, including, restarting them.
@@santiagofep Hi, for the specific purpose, singletons still stand. Just need to know when/how to use them. In games, there is always ONE physics system/engine, ONE graphics engine, ONE networking engine/interface, ONE sound engine/manager, ONE controller/input interface/manager, etc. (do remember that in the context of games, you have a lot of sub-components that are constantly spawned/removed and those will have dependencies that SHOULD be dependency injected from different DI containers. Loading a new map/scene/dungeon/etc is a nice top level example but theres others) Then everything else runs on top of those basic components. So, yes, in that specific context this still stands. If you are using a normal app, then, that might change as usually you might want to be able to instantiate bigger portions of your app with injected dependencies (that you control for that specific instance). Example, if your app connects to a database, then and you want to support multiple db connections where each connection is a new window, then each window spawn would spawn with a new db connection specific dependency injection container
There is a cost for replacing singletons with links. For instance, all classes that read time must have a link to the real-time clock class. For parallel unit testing to work, tests that involve the singleton need to lock it. The hard thing is to determine which those tests are. You don't know which tests call code that uses the singleton.
@blenderpanzi This is true in a purely functional language. In object-oriented languages with mutable objects, side effects do not really imply global state. Objects are created in local scopes, and if two objects are created equally, you should get the same result from obj1.f(x) as obj2.f(x), as well as obj1.f(y) and obj2.f(y) if x==y. Unless you have global state, like static variables, random generators (that are commonly based on the global variable known as the clock) and so on.
I have a question, I hope someone can help me on this. Based on the example of the House 34:00 He talked about using a factory which will wire up everything the House needs. My question is: If I'm separating my business logic from object's instantiation. Where should I instantiate this factory class and how will I tell to it the specifics of every object been wired(Doorknob color, type of door, etc) ? I know this is not Stackoverflow but I find it very interesting. Thanks in advance. This is a great video by the way
It might look like you're substituting "new" with "factory.build()" and just shifting the problem elsewhere but, in practice you'll only have around 7 to 10 factories anyway. Since that's not a lot, I think it's okay to create new instances of factories when you need the factory to build you an object.
I think the idea is very much like how a physical product is made. The door, the knob, hinges, and all other components are made in their own factories, but you the builder (programmer) are assembling these components together into a cohesive door at your build site (application). This analogy works from the bottom (metal foundry and wood mill), to the low-level components (hinge/screw/knob/door factories), to mid-level components (fully-assembled doors at the hardware store), to high-level functional units (pre-fabricated housing). The factories make/instantiate the objects, while the objects themselves only need to know how to work together (and not how to initialize their sub-components). The door only knows that it needs a knob, not that the knob needs a lock, which needs pins and levers, which need various metals, and so on.
There should only be one Factory, being the App.java class. In the App constructor is where everything is wired up, and app.start(); should set the ball rolling. Your main should really look like main { App myApp = new App(); MyApp.start(); }
@@colm9419 So what happens if you have classes that aren't singletons? If I have three objects with the same class, but different parameters, how do I make sure they get wired to the right consumers without moving a bunch of error-prone business logic into the factory, where it can't be unit tested?
Singletons have their place, they are the gentleman's global variable. A singleton with a private constructor CAN be referenced thru reflection. I found that out the hard way once with an API I sent out. Just FYI.
Question: say I'm testing a DatabaseManager, and it has a createDatabase() method and a destroyDatabase() method. To test createDatabase(), the database needs to not exist, and to test destroy, the database does need to exist. Now I run both tests (e.g. as part of a suite). The first one passes, the second one fails. I fix the code then rerun the suite. Since the test database wasn't deleted, the first test fails (or throws an exception, or returns false). What's the solution?
You're mixing business logic and object creation. The fact that a createDatabase() exists at all is a violation of DI. To test the DatabaseManager properly, you would pass in the database as a dependency through the constructor.
I know this video is very old, but maybe someone is still reading this, because I have a question about this topic. Let's say I have this class A and it has to create multiple instances of class B (which needs other objects in the constructor). So this guy said that you should use a factory to create these instances of class B, but my question is how does class A get access to the factory which will create the instances of class B? Should the factory passes in the constructor to class A? Or am I missing something?
You still have to access the global state to get the information in the first place! What you describe simply minimizes the use of global state across the application.
This is probably like the goto statement. Engineering is about trade-offs. Unless you talk about the cons of your approach you are just preaching about it. Who wouldn't want to only use pure functions? Well unless you understand disadvantages of the complexity of monads don't use it. Global state limits testability but it reduces the complexity of the code. On the other hand dependency injection increases the complexity while giving you testability. So choose whichever matters most : simplicity or testability
Wrong. Global state *increases* complexity because nothing can be tested in isolation. Global state may make things appear easier for the first 10% of an application, but it will invariably introduce severe problems once the business logic grows in complexity.
But what if I have a method that, say, gets the current time of day? Even given the exact same input, it will, of course, return different values depending on external conditions. What's wrong with that? It seems perfectly intuitive and testable to me!
The GUI of an app or web page is not kind of a global state? F.e. if a checkbox is checked or not, what text a text field has etc... How would the application deal with these elements the proper way?
1:34 actually why would you expect a to be equal to b? They are different instances of the same blueprint. And we don't know what the initializer does so it's quite a stretch to expect the same behaviour based solely on a method name.
That is also a global state you have to deal with... A more proper test would be (in my DI-n00bage oppinion): testDatabaseManagerDestroyDatabase() { String d = "foo"; Database db = new Database([...]); DatabaseManager dbm = new DatabaseManager(db); if(dbm.hasDatabase(d)) { assertTrue(dbm.deleteDatabase(d)); } assertTrue(dbm.createDatabase(d)); assertTrue(dbm.hasDatabase(d)); } And the other way around. This way you are enforcing the consistency of the unavoidable global state.
I love how he never answers the question about the widget around 32:00. So instead of using a global variable for the widget, you need a factory? What is that even supposed to mean? Will the factory construct a new widget, even though there is clearly only one on screen?
He did answer the question by giving a different example. Let me rephrase: a widget object will become a dependency. Only the bottom class that needs to print something, will accept the widget object as a parameter in the constructor. The top level class or any intermediate classes in the chain don't need to care about the widget class.
@magwo AFAIK: if x == y && f(x) != f(y) then there is a side effect. Having global state (or just object oriented programming with mutable objects) you get such a situation, because there is a hidden parameter. But maybe I did understand something wrong.
@magwo Well from a theoretical point of view there are basically two concepts: functional and logic orientated. So I guess all existing languages have to be described with one of these two (lambda calculus is used as the theoretical background for most programming languages), which explains why my professor said in a theoretical lecture that global state (or even mutable objects) are basically side effects. :)
Of course all this overlooks the fact that the Java class library needs its own singletons. You can't avoid global state completely because your program (unless it's just a test) needs to communicate with the outside world -- even if that outside world is just the user at the keyboard.
John Undefined The point is not to pretend that global state does not exist, it is to keep it out of your program wherever possible to make testing (and debugging) much easier. Even embedded C code can use dependency injection to good effect. For example, in a GPIO driver you would pass a pointer to the (memory-mapped) register as a parameter to the init() function instead of just accessing the fixed HW address in the "constructor" itself. This allows you to provide a pointer to any 8/16/32-bit memory location for testing purposes, but you'd pass the real hardware address in your application code. I also use this technique to avoid the use of dynamic memory allocation, which is not generally available in "real" embedded code. If the module needs to use a variable-size component like a queue or array of some data then it is allocated statically wherever the size is known and a reference + size is passed in to the constructor.
at least now you can easily mock out the singleton in your class under test by using powermock so I dont see any problem (maybe it was not around then). Once you have a mock singleton object you can test your code.
41:00 servlet's constructor takes no argument - instead of using singletons inside the servlet, delegate to its double and do the object graph instantiation there
Don't you think that Aspect- Oriented programming is the best solution for complex initialization mechanism with both init and finalization methods to be called.
@blenderpanzi That is not correct. They are obviously not the same thing IMO. However having a mutable global state makes any code anywhere _potentially_ side effect laden, to an unknown extent, because the state changes can propagate between singletons etc. If you do not have global state, the side effects can only happen in the set of objects that you are currently testing in isolation, so they can be expected and checked for correctness.
I need a help here. I have an application that uses ServiceLocator (which is a Singleton) to get instancies. With it, I can change my DAO implementation (JDBC, Hibernate, etc) and others stuffs. Is that (SeviceLocator) a bad thing? If yes, what should I do? Thanks, I'm starting on programming so I'm beening stupid. And, I know that I have a terrible English.
not everyone writes code that has only few small functions. Any big realistic program is a giant state machine where its impossible to test a small instantiation separately.
And that is an example of poor design. A "giant state machine" is impossible to get even nearly test covered. Or stable.. You have to be able to isolate every single component for testing, give the component a couple of fakes as dependencies if required and test this (now very limited, maybe even stateless!) machine. This is what meant by "loose coupling".
Maverickx89 Well it definitely is not a good design no doubt about that. But in practice that's how programs turns out to be when writing real world applications.
Some are, some aren't. Threre is no point discussing design patterns, if the real code is made a mess anyway. Truth is, most developers do not really put enough thought (or mostly have not enough experience) to structure code properly, never mind even write proper tests. Even worse, they never refactor - why touch a running system? With time, we end up with "legacy code", being repetitive and absolutely impossible to understand. I've seen methods of >1000 LOC and more then 10 levels of control-structure hierarchy (if, while, ..).. And now, for a few new changes, you can either start from scratch, or end up in a desaster anyway. So, is the desaster avoidable? Yes. Structure code, refer to best practices (like in this video) and never stop refactoring and imporving internal quality. The projects that do it right are recognizable on the constant pace of development, while those sho dont - slow down beyond a crawl after 1-2 years
+Ankur Varsheny I think this is a really lazy and unacceptable position to take. you can't excuse bad code with "but we always write bad code". the point is, stop doing that. be rigorous. do things right. don't take "shortcuts", because they will only slow you down. write good code.
+Ankur Varsheny I think a point that some experienced programmers I've been reading lately would make is that everybody SHOULD be writing code that only has a few small functions. The processor can only do one thing at a time, and even huge objects with dozens and dozens of functions can still only operate one of those functions at a time (even if they share information with other functions, it's trivial to maintain state outside of an encapsulating function), so it seems obvious that any large function with other functions inside it can be broken out into smaller functions. It seems equally obvious to me that if your functions are so big you can't understand how they work well enough to write a test for them, you need to break them into smaller functions. Obviously, if it's a huge program you'll need lots of solid documentation to keep track of things, but that's just as true of any function so big you can't keep all of it in your head anyway. So you get more testability and it's at least as maintainable.
At 24:10 again: He wants a functional and sideeffect free language. In haskell you CAN change the order of expressions! Why isn't he saying that he does not like OOP languages but would like to use a functional language?
Kind of lost me in the first five minutes when he rejected that guy's suggestion that the method name would make a difference in what you expected to get as a return value from the function. Not very prosocial to just reject his comment, and furthermore it was a good suggestion, i.e. yes method name does matter.
NO the method name doesn't matter it's just an example method name. Nobody should even look twice at that. Whoever commented on it had some serious autism and OCD.
well I switched off after about 3 minutes in when he said that procedural code is un-testable. A ridiculous remark that is totally untrue. the same things are tested in OOP and procedural languages and they are function calls. absolute facepalm
Procedural code is untestable unless you are using some way to mock the dependencies so that you are not testing your whole application. In C we can use tools/frameworks to link our modules to mocked dependencies instead of the real deal, but it is still impossible to mock calls to functions within the same module (compilation unit). Your code can be nice and modular within the .c file, but to test it you have no "seams", to use his analogy, so you're stuck having to test the unit under test's helper functions along with it. This leads your test code to have a lot of duplication. The obvious solution is to use more modules so that they may be mocked, and keep helper functions to the very low-level trivial stuff that isn't worth testing (no calls into other modules). But, alas, that is not how most code is designed and written unless you are following (or are aware of) TDD. In my experience the older the code the more monolithic and untestable it is (1000+ line monster functions, entire projects in one or only a few files, etc.).
I'm at 8:30 and wonder if he will name the child by its name in this talk and say: SIDEEFFECTS! He wants a sideeffect free language. He should use haskell.
The same argument being made against singletons is the same argument is made about guns. You can do really bad things with singletons. Therefore, singletons are bad. There are use cases where singletons make sense. Also, this video is 10 years old. Java now have Enums which are used to make singletons.
08:30 All of your test flakiness will come from some form of uncontrolled global state.
10:20 Singleton with capital ’S’. Refers to the design pattern where the Singleton has a private constructor and has a global instance variable. Lowercase ’s’ singleton means I only have a single instance of something because I only called the new operator once.
11:44 Singleton pattern is bad because it introduces potentially infinite global variables.
13:00 If global variables are bad… how can Singletons be good? (They can't & aren't good.)
15:10 How do I assert that a method in my class calls another method on a singleton? You can’t. There’s no seams. Instead, you need to instantiate the class under test and the instantiation of its dependencies.
18:54 Deceptive API. Singletons hide the details. There’s hidden dependencies. You can have unexpected side effects.
25:00 Dependency injection orders code naturally. A class will explicitly declare its dependencies. And it enforces correct order of method calls/setup.
29:10 Review:
- Global state is the root of 90% of your testing problems
- Global state can’t be controlled by tests
- Singleton pattern is just global state
Q&A
32:00 Q: Without a Singleton I have to pass a dependency all the way down a long chain and that seems excessive. Isn’t that bad?
A: That’s a myth. Let’s say you have a database and you instantiate it all the way in your main method. Wouldn’t you have to then pass it all the way down? No you don’t. You need to change the way you structure you code. You probably mix object instantiation with business logic. Instead, you should have a factory that knows how to create and wire up all the dependencies.
36:28 Q: Isn’t a ‘House’ factory inconvenient because then you have to pass thousands of things into the method?
A: If House needs 1000 things then your house has a design problem because it has too many responsibilities. You need to decompose and re-structure your classes.
man you are going to heaven for this
What he's basically saying is you should try to make everything as reentrant as possible. It always amazes me that in the end, with all these new fancy programming languages and paradigms, the fact is the only thing that matters is achieving high cohesion and low coupling, which is heavily discussed in the 70s, and us young whippersnappers are reinventing the broken wheel.
Yet there have been many books are articles pushing service locators and they are still used extensively because they're easy and don't make you seriously think about the structure of your application. The talk is warranted.
Us young whippersnappers don't approach programming as a mathematical discipline. The moment we have to start writing proofs for our software, most of us will quit.
This talk is seriously excellent. It leads me to believe that we really don't need the static keyword at all. We ought to be careful to not confuse pragmatism with laziness.
You completely need to use static classes and methods in some situations.
Suppose you want to load/save a file with specific format (the language or framework does not have any lib for it) or you want to show some messageBox.
You do not intend to send them as parameters to constructors for every new object!!!
@@MMMM-vc5oi I don't understand how your example implies the need for static methods or variables.
The guy at the beginning trying to catch the speaker out on a completely arbitrary and irrelevant method name is painful to watch.
I died a little inside when i heard him .
I aM So SmArT
I wish I could like this multiple times.
What I liked about this talk is that he pointed out that classes at the bottom do not have to use DI. It was just one sentence, but was probably worthy of several minutes.
It reminds me of clean architecture or onion architecture. The class in the bottom are domain objects. They are VALUE objects. DI-able objects are on the outside in infrastructure layer and such.
36:30 The natural tendency of us humans is to resist new ideas, specially those that contradict our currently held beliefs or practices. In this case there is an implicit supposition of the questioner which is that having a class with a big number of dependencies is not an indication of bad design.
I'm glad how clear Misko's explanation is about how DI does not imply having to complicate the constructor of classes.
This is an absolutely fabulous series of talk ! Thanks !
For example the idea in the end that the framework imposes global states for file I/O, DateTime.Now and random numbers is really interesting because that's very common pain point when doing tests. The suggestion by one of the participant in the end, to use adapter objects to access those global state is a very good solution. For example it is a breath to test code depending on timing when passing a 'clock' object as a mock and manipulating time in the test, so that for example instead of waiting for a second, you can increment the clock object a second and continue running the test without waiting ;-)
Same for testing math code using randomness, using a mock rng is super useful to manipulate precisely the number served to the algorithm.
Excellent video on the problem created by Singleton and global state
reserve to watch again and again
It is impressive how ppl are averse to changing their mind, despite all the good examples the talker gives to them and the benefits of dependency injection seem like everyone is fighting him! I would like to see those ppl writing some unit tests, that should be something to watch. Like 20 mocks for each test. cheating all the statics variable and so on... Very nice talk!!!
I agree. The speaker is great and knows what he's talking about. Strange that people a reluctant to listen, because "hey, I don't design my own code this way".
Stateless singletons don't have these problems, but they simultaneously lack any real relevance - if there's no state, why would you care if there's one instance or fifteen instances? Especially since stateless objects tend to be rather small, with inexpensive constructors.
It's not that singletons themselves are bad but the GOF design pattern is. The only really argument that is valid is that the GOF design pattern doesn't lend itself in regards to testing, especially if tests are run in parallel.
Agreed, I often find terminology to be a big of a problem as the program itself. To clarify, to me "global state" means any variable with a state that might change at any moment due to any part of the application, the most common unavoidable example being a connection to a database, some external service or environmental variables, hence what I meant by learning to work with global state instead of just minimizing it.
Very interesting, brilliant, and simple analysis.
About Dependency Injection: Like someone [kinda] asked, If a house have a dozen dependencies, each of these have a dozen dependencies, and so on. The we would have a psychopathic Factory for a house? (Just some numbers if it was exactly 12 dependencies: Two layers is 144, three is 1728)
How would we handle that?
+Martin Dilling-Hansen I actually think this was the actual question and the talker misunderstood it. The thing is, when you don't use dependency injection all 1728 dependencies are still there somewhere in the application and you just don't see it, by using dependency injection they all suddenly become explicit and now you are stuck with instantiating 1728 objects before you can run tet code... but not really, first, realize that when you are testing you most likely will use mocking dependencies instead of the real dependencies, and the mocks won't have further dependencies, that means, in tests, you will only need to instantiate the next layer of dependencies for this application which are 12 objects, the real application will remain basically the same, but will be reorganized so that the dependencies are concentrated in the factories/injector
Misko Hevery = 10 out of 10 as usual!
Very interesting and thought-provoking talk. There's still something I don't quite understand. It's basically the question the first person asked: how to handle a resource which is universally required by all (or most) of the classes in an application. Such as a logger, which any class might need to write to. The speaker changed the questioner's example to a database, which is less universal and therefore changed the question somewhat.
If I want every class to have access to a Logger, does that mean that every class needs a factory class to create instances of it which explicitly references the Logger via DI? Does every instance of every class need to hold a reference to the Logger? That seems like a lot of overhead.
The way I've always handled things like that is with a globally accessible static class, but that goes against the speaker's main thesis. I wonder if the speaker would allow exceptions in these cases, or if there's another solution.
There are a couple options. First, you wouldn't likely use a factory because you would only have a single logger instance created at the composition root. That instance could be passed to every class through the constructor. If you don't like your constructor getting polluted, you could use parameter injection and pass your logger in through a public method, and assign a NullLogger instance by default. Lastly, the cleanest approach would be to use a proxy class to intercept your method calls so the class itself has no knowledge of the logger at all.
What if we had a Utility class with static methods as a Logger?
Testing is not the only phase of development.
This is an awesome talk!
@blenderpanzi
Actually it's not at all about side effects. Side effects do not present a big problem to testability of code, but global state (global side effects) does.
Singletons are not evil. In fact, they solve a ton of problems, but as with all things, there is tradeoffs.
I am programming games, and I have at least 20 singletons, graphics system, physics system, networking, sound, controllers, etc,etc,etc. Singletons here, in this specific case, make the code much faster, more testable and simpler to use.
The key idea is to have a central location that can actually control all other singletons if needed, including, restarting them.
Are you still using them or did you switch to dependency injection?
@@santiagofep Hi, for the specific purpose, singletons still stand. Just need to know when/how to use them. In games, there is always ONE physics system/engine, ONE graphics engine, ONE networking engine/interface, ONE sound engine/manager, ONE controller/input interface/manager, etc. (do remember that in the context of games, you have a lot of sub-components that are constantly spawned/removed and those will have dependencies that SHOULD be dependency injected from different DI containers. Loading a new map/scene/dungeon/etc is a nice top level example but theres others)
Then everything else runs on top of those basic components. So, yes, in that specific context this still stands.
If you are using a normal app, then, that might change as usually you might want to be able to instantiate bigger portions of your app with injected dependencies (that you control for that specific instance). Example, if your app connects to a database, then and you want to support multiple db connections where each connection is a new window, then each window spawn would spawn with a new db connection specific dependency injection container
There is a cost for replacing singletons with links. For instance, all classes that read time must have a link to the real-time clock class.
For parallel unit testing to work, tests that involve the singleton need to lock it. The hard thing is to determine which those tests are. You don't know which tests call code that uses the singleton.
Dayyyyyyymmnnnnn! That's hot.
@blenderpanzi This is true in a purely functional language. In object-oriented languages with mutable objects, side effects do not really imply global state. Objects are created in local scopes, and if two objects are created equally, you should get the same result from obj1.f(x) as obj2.f(x), as well as obj1.f(y) and obj2.f(y) if x==y. Unless you have global state, like static variables, random generators (that are commonly based on the global variable known as the clock) and so on.
I have a question, I hope someone can help me on this.
Based on the example of the House 34:00
He talked about using a factory which will wire up everything the House needs.
My question is:
If I'm separating my business logic from object's instantiation. Where should I instantiate this factory class and how will I tell to it the specifics of every object been wired(Doorknob color, type of door, etc) ?
I know this is not Stackoverflow but I find it very interesting. Thanks in advance.
This is a great video by the way
I'd instantiate it in main, then pass it into everything that needs it. But that's a good question, I really have no idea.
It might look like you're substituting "new" with "factory.build()" and just shifting the problem elsewhere but, in practice you'll only have around 7 to 10 factories anyway. Since that's not a lot, I think it's okay to create new instances of factories when you need the factory to build you an object.
I think the idea is very much like how a physical product is made. The door, the knob, hinges, and all other components are made in their own factories, but you the builder (programmer) are assembling these components together into a cohesive door at your build site (application). This analogy works from the bottom (metal foundry and wood mill), to the low-level components (hinge/screw/knob/door factories), to mid-level components (fully-assembled doors at the hardware store), to high-level functional units (pre-fabricated housing).
The factories make/instantiate the objects, while the objects themselves only need to know how to work together (and not how to initialize their sub-components). The door only knows that it needs a knob, not that the knob needs a lock, which needs pins and levers, which need various metals, and so on.
There should only be one Factory, being the App.java class. In the App constructor is where everything is wired up, and app.start(); should set the ball rolling.
Your main should really look like
main {
App myApp = new App();
MyApp.start();
}
@@colm9419 So what happens if you have classes that aren't singletons? If I have three objects with the same class, but different parameters, how do I make sure they get wired to the right consumers without moving a bunch of error-prone business logic into the factory, where it can't be unit tested?
Great speaker
Very nice speaker!
very very informative...
Singletons have their place, they are the gentleman's global variable.
A singleton with a private constructor CAN be referenced thru reflection.
I found that out the hard way once with an API I sent out.
Just FYI.
Question: say I'm testing a DatabaseManager, and it has a createDatabase() method and a destroyDatabase() method. To test createDatabase(), the database needs to not exist, and to test destroy, the database does need to exist.
Now I run both tests (e.g. as part of a suite). The first one passes, the second one fails. I fix the code then rerun the suite. Since the test database wasn't deleted, the first test fails (or throws an exception, or returns false).
What's the solution?
You're mixing business logic and object creation. The fact that a createDatabase() exists at all is a violation of DI. To test the DatabaseManager properly, you would pass in the database as a dependency through the constructor.
I know this video is very old, but maybe someone is still reading this, because I have a question about this topic.
Let's say I have this class A and it has to create multiple instances of class B (which needs other objects in the constructor). So this guy said that you should use a factory to create these instances of class B, but my question is how does class A get access to the factory which will create the instances of class B? Should the factory passes in the constructor to class A? Or am I missing something?
You still have to access the global state to get the information in the first place! What you describe simply minimizes the use of global state across the application.
This is probably like the goto statement. Engineering is about trade-offs. Unless you talk about the cons of your approach you are just preaching about it.
Who wouldn't want to only use pure functions? Well unless you understand disadvantages of the complexity of monads don't use it. Global state limits testability but it reduces the complexity of the code. On the other hand dependency injection increases the complexity while giving you testability. So choose whichever matters most : simplicity or testability
Wrong. Global state *increases* complexity because nothing can be tested in isolation. Global state may make things appear easier for the first 10% of an application, but it will invariably introduce severe problems once the business logic grows in complexity.
12:51 I love this logical sarcasm lol.
But what if I have a method that, say, gets the current time of day? Even given the exact same input, it will, of course, return different values depending on external conditions. What's wrong with that? It seems perfectly intuitive and testable to me!
DI is like object capabilities. Nice.
The GUI of an app or web page is not kind of a global state?
F.e. if a checkbox is checked or not, what text a text field has etc...
How would the application deal with these elements the proper way?
It's true that the value of the check box is state but it doesn't have to be global state.
refactoring.guru/design-patterns/mediator
1:34 actually why would you expect a to be equal to b? They are different instances of the same blueprint. And we don't know what the initializer does so it's quite a stretch to expect the same behaviour based solely on a method name.
public static destroy(){
instance = null;
}
done, you can now test it
static data is ok if it an implementation detail and it doesn't change the interface
That is also a global state you have to deal with...
A more proper test would be (in my DI-n00bage oppinion):
testDatabaseManagerDestroyDatabase() {
String d = "foo";
Database db = new Database([...]);
DatabaseManager dbm = new DatabaseManager(db);
if(dbm.hasDatabase(d)) {
assertTrue(dbm.deleteDatabase(d));
}
assertTrue(dbm.createDatabase(d));
assertTrue(dbm.hasDatabase(d));
}
And the other way around.
This way you are enforcing the consistency of the unavoidable global state.
I love how he never answers the question about the widget around 32:00. So instead of using a global variable for the widget, you need a factory? What is that even supposed to mean? Will the factory construct a new widget, even though there is clearly only one on screen?
He did answer the question by giving a different example. Let me rephrase: a widget object will become a dependency. Only the bottom class that needs to print something, will accept the widget object as a parameter in the constructor. The top level class or any intermediate classes in the chain don't need to care about the widget class.
@magwo AFAIK: if x == y && f(x) != f(y) then there is a side effect. Having global state (or just object oriented programming with mutable objects) you get such a situation, because there is a hidden parameter. But maybe I did understand something wrong.
34:00 the house example for object instantiation.
Can you reupload with the Law & Order narrator reading out the text at the start?
@magwo Well from a theoretical point of view there are basically two concepts: functional and logic orientated. So I guess all existing languages have to be described with one of these two (lambda calculus is used as the theoretical background for most programming languages), which explains why my professor said in a theoretical lecture that global state (or even mutable objects) are basically side effects. :)
Of course all this overlooks the fact that the Java class library needs its own singletons. You can't avoid global state completely because your program (unless it's just a test) needs to communicate with the outside world -- even if that outside world is just the user at the keyboard.
John Undefined The point is not to pretend that global state does not exist, it is to keep it out of your program wherever possible to make testing (and debugging) much easier.
Even embedded C code can use dependency injection to good effect. For example, in a GPIO driver you would pass a pointer to the (memory-mapped) register as a parameter to the init() function instead of just accessing the fixed HW address in the "constructor" itself. This allows you to provide a pointer to any 8/16/32-bit memory location for testing purposes, but you'd pass the real hardware address in your application code.
I also use this technique to avoid the use of dynamic memory allocation, which is not generally available in "real" embedded code. If the module needs to use a variable-size component like a queue or array of some data then it is allocated statically wherever the size is known and a reference + size is passed in to the constructor.
at least now you can easily mock out the singleton in your class under test by using powermock so I dont see any problem (maybe it was not around then). Once you have a mock singleton object you can test your code.
And many years after, the consensus is you SHOULD NOT use Powermock. If you have to use Powermock, it's a sign your code is badly designed.
41:00 servlet's constructor takes no argument - instead of using singletons inside the servlet, delegate to its double and do the object graph instantiation there
Don't you think that Aspect- Oriented programming is the best solution for complex initialization mechanism with both init and finalization methods to be called.
@blenderpanzi That is not correct. They are obviously not the same thing IMO. However having a mutable global state makes any code anywhere _potentially_ side effect laden, to an unknown extent, because the state changes can propagate between singletons etc.
If you do not have global state, the side effects can only happen in the set of objects that you are currently testing in isolation, so they can be expected and checked for correctness.
Very cool video, really interesting. Are those code review cards put up for download somewhere?
I laughed seeing so few at the front rows
+Weihang Chen Why?
SECRETLY!
11:44 how it will create infinite object. As instance is static, it will create a single instance per class as per jvm implementation.
He means you can access them easily (hierarchy). It has this potential. You can put everything you want in Singleton and it is absolutely dangerous
Isn't container a singleton in this case? If it is responsible for creating the objects. It is similar to service locator.
MrGuardianX a service container should only be used in your composition root. search for 'inversion of control' to get more information ;)
I need a help here.
I have an application that uses ServiceLocator (which is a Singleton) to get instancies. With it, I can change my DAO implementation (JDBC, Hibernate, etc) and others stuffs.
Is that (SeviceLocator) a bad thing? If yes, what should I do?
Thanks, I'm starting on programming so I'm beening stupid.
And, I know that I have a terrible English.
Are you using unit testing in your application or on the ServiceLocator?
You don't need singletons, you need Utility (static) classes, classes with code only and no instance variables.
Perfect. Yes I have said before. We definitely need static classes (Utility). Also, we can test them easily.
@Synergy9k
What are you going to test it against?
not everyone writes code that has only few small functions.
Any big realistic program is a giant state machine where its impossible to test a small instantiation separately.
And that is an example of poor design. A "giant state machine" is impossible to get even nearly test covered. Or stable.. You have to be able to isolate every single component for testing, give the component a couple of fakes as dependencies if required and test this (now very limited, maybe even stateless!) machine. This is what meant by "loose coupling".
Maverickx89 Well it definitely is not a good design no doubt about that. But in practice that's how programs turns out to be when writing real world applications.
Some are, some aren't. Threre is no point discussing design patterns, if the real code is made a mess anyway. Truth is, most developers do not really put enough thought (or mostly have not enough experience) to structure code properly, never mind even write proper tests. Even worse, they never refactor - why touch a running system? With time, we end up with "legacy code", being repetitive and absolutely impossible to understand. I've seen methods of >1000 LOC and more then 10 levels of control-structure hierarchy (if, while, ..).. And now, for a few new changes, you can either start from scratch, or end up in a desaster anyway.
So, is the desaster avoidable? Yes. Structure code, refer to best practices (like in this video) and never stop refactoring and imporving internal quality. The projects that do it right are recognizable on the constant pace of development, while those sho dont - slow down beyond a crawl after 1-2 years
+Ankur Varsheny I think this is a really lazy and unacceptable position to take. you can't excuse bad code with "but we always write bad code". the point is, stop doing that. be rigorous. do things right. don't take "shortcuts", because they will only slow you down. write good code.
+Ankur Varsheny I think a point that some experienced programmers I've been reading lately would make is that everybody SHOULD be writing code that only has a few small functions. The processor can only do one thing at a time, and even huge objects with dozens and dozens of functions can still only operate one of those functions at a time (even if they share information with other functions, it's trivial to maintain state outside of an encapsulating function), so it seems obvious that any large function with other functions inside it can be broken out into smaller functions. It seems equally obvious to me that if your functions are so big you can't understand how they work well enough to write a test for them, you need to break them into smaller functions.
Obviously, if it's a huge program you'll need lots of solid documentation to keep track of things, but that's just as true of any function so big you can't keep all of it in your head anyway. So you get more testability and it's at least as maintainable.
why the hell we're we taught the singleton pattern anyway ?
At 24:10
again: He wants a functional and sideeffect free language. In haskell you CAN change the order of expressions! Why isn't he saying that he does not like OOP languages but would like to use a functional language?
Testers doing developers cry since ancient times.-
Damn, good I never saw such Singleton abusing.
@deathbyaclown
better use charge(-100) ;-)
@magwo Well, one of my professor said global state equals side effects, mathematically spoken. I just believed him.
Kind of lost me in the first five minutes when he rejected that guy's suggestion that the method name would make a difference in what you expected to get as a return value from the function. Not very prosocial to just reject his comment, and furthermore it was a good suggestion, i.e. yes method name does matter.
NO the method name doesn't matter it's just an example method name. Nobody should even look twice at that. Whoever commented on it had some serious autism and OCD.
well I switched off after about 3 minutes in when he said that procedural code is un-testable. A ridiculous remark that is totally untrue. the same things are tested in OOP and procedural languages and they are function calls. absolute facepalm
Procedural code is untestable unless you are using some way to mock the dependencies so that you are not testing your whole application. In C we can use tools/frameworks to link our modules to mocked dependencies instead of the real deal, but it is still impossible to mock calls to functions within the same module (compilation unit). Your code can be nice and modular within the .c file, but to test it you have no "seams", to use his analogy, so you're stuck having to test the unit under test's helper functions along with it. This leads your test code to have a lot of duplication.
The obvious solution is to use more modules so that they may be mocked, and keep helper functions to the very low-level trivial stuff that isn't worth testing (no calls into other modules). But, alas, that is not how most code is designed and written unless you are following (or are aware of) TDD. In my experience the older the code the more monolithic and untestable it is (1000+ line monster functions, entire projects in one or only a few files, etc.).
I'm not fond of this audience.
Global state is unavoidable when you work with any information, we should not disregard it, but instead we need to learn how to work with it.
27:14 dependency injection is our friend...
Because education is always behind on current technology.
I'm at 8:30 and wonder if he will name the child by its name in this talk and say: SIDEEFFECTS! He wants a sideeffect free language. He should use haskell.
typical haskell fanatic
@@gbroton Who? I don't use Haskell.
24:45 Someone at google has an iPhone :@
is there a tl;dr of this? i dont feel like watching the entire hour. i might anyway tho
The same argument being made against singletons is the same argument is made about guns. You can do really bad things with singletons. Therefore, singletons are bad. There are use cases where singletons make sense.
Also, this video is 10 years old. Java now have Enums which are used to make singletons.
What? Enums aren't singletons - they don't store any global state. They are just values. And they existed when this video was made.
Microservices
Have the people attending the talk never programmed correctly anything in their lives? The questions are so bad.
public static freud(){
Freud freud = new freud(cocaine);
return freud;
}