Google Tech Talks November 6, 2008 ABSTRACT Clean Code Talk Series Topic: Don’t Look For Things! Speaker: Misko Hevery
Video Rating: 4 / 5
The Clean Code Talks – Don’t Look For Things!
Welcome Please feel free to write about any topic, this blog is for you.
i came across an alien alphabet see if you can read it. at symbols n codes.
Yeah, I’m not sure why he didn’t just suggesting overloading the constructor so that one takes an Engine directly and the other builds one from a factory. Then you can easily instantiate it in the test as well as avoid having to keep reinstantiating Engines when you actually want to use it for real. It increases the coupling slightly, but might be worth it depending on the application.
Loggers are cross cutting concerns, you use ambient context to use them, you can have logger per thread (Thread Local) , you can have a Logger as a singleton (Then you can use service locator.) Essentially, DI fits in here as well.
assertEquasl(:-)
6:10 I think the reason people code in that way is because they are trying to promote code re-use. They don’t want to have to instantiate EngineFactory a zillion times in their application if they know a car will always need an engine. I know it may not be good DI, but from the angle of code re-use, why is that so bad?
If House does not require a door why does House ask for a door? According to the Law : “Only ask for what you need”. If you can test House without a door because P{ainting does not need it. It suggests that the “Painting aspect of the House class” ought to be moved elsewhere where it can be tested in isolation.
good talk
cool stuff .. nice i like it =)) thanks for sharing =)) god bless
@jessta314
Exactly what I was going to say. I know a group of people that prefer to dodge NPEs and end up confused when their application behaves oddly.
I may be naive for it, but I model my code after the Java APIs, they (mostly) don’t check for nulls, and it’s good because most NPEs are caused by coding errors.
cool
if I do outsourcing project, or do a contract project, after delivery I’m done. why should I write unit test. what I care is integration testing and system testing.
This can explains why contract project has low maintainability in general.
How about loggers? Is it ok to have in my class (like most do):
private static final Logger LOGGER = LoggerFactory.getLogger(MyClass.class);
Should the logger instance be passed in to?
11:55 it should definitely be an interface.
@MattCrypto The great thing about nulls is that you instantly knows when the code under test has changed. The null pointer exception you get is a good signal.
I think it’s mostly considered OK to have globally available loggers, due to one important detail – information flows only to such an object, not from them. You will really never have code that inspects the recently entered log messages, and make decisions based on that data. What one object logs does not affect what other objects do.
If House does not need Door then maybe you should have an alternative constructor for House object that does not have any arguments? OK, I know… in real application it always needs Door. But removing precondition because we “trust ourselves” is weak… Why do we even have any bugs in code? Why do we review the code others created? There’s no place for such trust – everyone is just a human and sometimes makes mistakes and that is why we need preconditions.
That’s very interesting. But how do you deal with non-essential objects that are possibly needed throughout the code, such as a Logger. Should I pass the global logger to each constructor so that each of their methods can log some messages? Or is it OK to use a singleton in this case?
I do not agree with the part 23:54 – 25:24. I think the speaker is incorrect about wanting to test with a null parameter. Symantically speaking, if the house in the constructor states that it needs a door, a test and the rest of the code should always respect this requirement. If in some cases a house doesn’t need a door (like in ‘painthouse’), you could make the method static and pass the needed data as arguments or move the not always needed ‘door’ from the constructor to the specific method.
simply good.
I think you are inventing the point as this is not stated in the talk. The contention stil remains if you use new House(null) and this succeeds but house.getDoor().toString() fails, the code if more fragile. These are Google talks, Bloch = chief architect, and I find these recomendations a bit our of sort. Given you also have Mockito for stubs I think Mitsuko is completely wrong and his ideas seem to come from laziness in developing the tests. test and real code should be of the same standard