サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
衆院選
misko.hevery.com
by Miško Hevery So you discovered dependency injection and GUICE and you are happily refactoring and writing new tests for you code until you come across this circular reference. class A { final B b; A(B b){ this.b = b; } } class B { final A a; B(){ this.a = new A(this); } } +---------+ +---------+ | A |<-----| B | | | | | | |----->| | +---------+ +---------+ Hm, dependency injection says that you
As you can tell I am a big fan of DI, but I kept hearing that DI is not needed with dynamic languages, so after using JS for many months I am happy to say that DI is important there as well. In other words dependency managment and controll matters. But it is different. Say you have a class for greeting with DI. class Greeter { String greeting; Greeter(String greeting) { this.greeting = greeting; }
Like most other developers, when I first came across the Flex data-binding, I thought of it as an interesting feature, but haven’t realized the true implications of it until much later. Data-binding in Flex has revolutionized the way I think about building UIs. To understand why data-binding is so revolutionary, let’s look at standard Model-View-Controller setup for building UIs. Let’s start off w
When I develop code I write test first and always run my tests. But it can get rather tedious to run the tests manually every so often. Here is a common scenario. Your tests are green and you start doing whole bunch of refactorings which you think are trivial and safe. When you are done you run the tests and it is broken. The problem is that you did ten little things and you don’t know which of th
by Miško Hevery Google Tech Talks November 6, 2008 ABSTRACT Clean Code Talk Series Topic: Don’t Look For Things! Speaker: Miško Hevery Video Slides I really love your blog which is a door to a new and exciting world for me. I still have blure points about the performance (app) and productivity (men) impacts. Which kind of project should be developped like this? Is it a conceptual or practical solu
By John Januszczak The Active Record pattern has gained a lot of attention lately, particularly because of it’s use in the wildly popular Ruby On Rails (“RoR’) framework. Other frameworks which employ the Active Record pattern include the Castle Project, which aims to simplify the creation of enterprise and web applications for .NET developers. If you are new to the Active Record design pattern, i
Work in the constructor such as: creating/initializing collaborators, communicating with other services, and logic to set up its own state removes seams needed for testing, forcing subclasses/mocks to inherit unwanted behavior. Too much work in the constructor prevents instantiation or altering collaborators in the test. new keyword in a constructor or at field declaration Static method calls in
by Miško Hevery Recently many of you, after reading Guide to Testability, wrote to telling me there is nothing wrong with static methods. After all what can be easier to test than Math.abs()! And Math.abs() is static method! If abs() was on instance method, one would have to instantiate the object first, and that may prove to be a problem. (See how to think about the new operator, and class does r
by Miško Hevery So you join a new project, which has an extensive mature code base. Your new lead asks you to implement a new feature, and, as a good developer, you start by writing a test. But since you are new to the project, you do a lot of exploratory “What happens if I execute this method” tests. You start by writing this: testCreditCardCharge() { CreditCard c = new CreditCard( "1234 5678 901
How to Think About the “new” Operator with Respect to Unit Testing By Miško Hevery Unit Testing as the name implies asks you to test a Class (Unit) in isolation. If your code mixes Object Construction with Logic you will never be able to achieve isolation. In order to unit-test you need to separate object graph construction from the application logic into two different classes The end goal is to h
To keep our code at Google in the best possible shape we provided our software engineers with these constant reminders. Now, we are happy to share them with the world. Many thanks to these folks for inspiration and hours of hard work getting this guide done: Jonathan Wolter Russ Ruffer Miško Hevery Also thanks to Blaine R Southam who has turned it into a pdf book. Flaw #1: Constructor does Real Wo
このページを最初にブックマークしてみませんか?
『Miško Hevery』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く