Wikipedia explains Law of demeter or principle of least knowledge in such a nice manner
- Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
- Each unit should only talk to its friends; don’t talk to strangers.
- Only talk to your immediate friends.
Here are some excepts from Rails Antipattern book that I have reading lately. Even though the examples are specific to rails, the fundamental principles applies to pretty much any MVC framework. In this post, I list out various Model Antipatterns & their potential solutions. I would be writing about other anti-patterns in next posts …
Antipattern # 1 : Voyeuristic Models
Solution: Follow the Law of Demeter
Solution: Push All find() Calls into Finders on the Model
Solution: Keep Finders on Their Own Model
AntiPattern # 2 : Fat Models
Solution: Delegate Responsibility to New Classes
Solution: Make Use of Modules
Solution: Reduce the Size of Large Transaction Blocks
AntiPattern # 3 : Spaghetti SQL
Solution: Use Your Active Record Associations and Finders Effectively
Solution: Learn and Love the Scope Method
Solution: Use a Full-Text Search Engine
Curiosity killed the cat & complexity killed the project !!
The importance of simplicity in application development is paramount. Complexity is the number-one killer of projects today, and it comes into an application in many ways, including through excitement over new features, overly clever developers, and unfamiliarity with the Ruby on Rails framework.
Came across today again this beautiful quote (said in the title) by Larry Wall in the Camel Book: Camel book was one of the most lucid programming book that I thoroughly enjoyed at that time.
We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.
The three virtues are explained as follows:
- The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See alsoimpatience and hubris.
- The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See alsolaziness and hubris.
- Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience.