3 ms·
Yes. Yes. Patterns are an educational tool. Read the book(s) then put them away. Adhering to patterns because they are SUPERIOR leads to code bloat and unwiel
by russell 18y ago
Yes. Yes. Patterns are an educational tool. Read the book(s) then put them away. Adhering to patterns because they are SUPERIOR leads to code bloat and unwieldy design. The article has a case where EJBs were used when a simple servlet would have sufficed. My rant-topic-of-the-day is using beans where a hash would do.
From a comment by Russ Olsen, "People who write this stuff just seem to miss that the size of the infrastructure needs to be in proportion to the size of the actual work being done. If the infrastructure is four times the size of the code that actually does something, then you can rewrite the real code 4 times for the price of the infrastructure."
- triplefox 18y agoIndeed. Patterns are what you use when there is no cleaner option for the situation. Recently I've been writing some code which is surprisingly amenable to a cut+paste approach: A tool which automatically generates level layouts for a game. At first I endeavored towards a data-driven approach to customizing each type of level I wanted to make, but soon I decided, "There are only six types of levels. Each one has different requirements and they get maintained in isolation. There is no point in trying to reconcile all of them at once." And so I went ahead with a strategy of reuse for the most common elements - low-level generation strategies - and made big switch statements for the remainder. It works, I get the job done, and there's almost never anything surprising. The only time something did surprise me was when I accidentally pasted the same code twice in different places and threw the results askew in a non-obvious way. That flags some need to slim down bloated methods, but even as-is, it still feels pretty slim at ~2500 lines.