Criminal Overengineering
coderoom.wordpress.com
Criminal Overengineering
1–10 of 67 posts
Re: Criminal Overengineering
#2I completely disagree with the example given in this blog. I don't have time to give a full explaination but I believe the google clean code talks gives a far better arguement than I ever could.
On the general principle I agree that overengineering is to be avoided, but I actually think the example shows a clear disregard for Object Orientated principles.
Re: Criminal Overengineering
#3I completely disagree with the example given in this blog. I don't have time to give a full explaination but I believe the google clean code talks gives a far better arguement than I ever could. On the general principle I agree that overengineering is to be avoided, but I actually think the example shows a clear disregard for Object Orientated principles. http://www.youtube.com/watch?v=4F72VULWFvc
One of my lecturers wrote the following at the top of our course notes:
Contrary to popular opinion using OOP does NOT mean "thou shalt make every last thing an object"
Re: Criminal Overengineering
#4I completely disagree with the example given in this blog. I don't have time to give a full explaination but I believe the google clean code talks gives a far better arguement than I ever could. On the general principle I agree that overengineering is to be avoided, but I actually think the example shows a clear disregard for Object Orientated principles. http://www.youtube.com/watch?v=4F72VULWFvc
So what's wrong with using a switch statement if all you have are 3 operations?
Even if more operations had to be added I'd probably let it grow to the point where the method the switch is in was getting a bit unwieldy then look at refactoring it using a pattern if I really thought it would be worth it.
Re: Criminal Overengineering
#5I completely disagree with the example given in this blog. I don't have time to give a full explaination but I believe the google clean code talks gives a far better arguement than I ever could. On the general principle I agree that overengineering is to be avoided, but I actually think the example shows a clear disregard for Object Orientated principles. http://www.youtube.com/watch?v=4F72VULWFvc
One of my lecturers wrote the following at the top of our course notes: Contrary to popular opinion using OOP does NOT mean "thou shalt make every last thing an object"
In some sense that's what the second O says, isn't it?
It's not called Object Programming, but Object-Oriented Programming.
Re: Criminal Overengineering
#6I completely disagree with the example given in this blog. I don't have time to give a full explaination but I believe the google clean code talks gives a far better arguement than I ever could. On the general principle I agree that overengineering is to be avoided, but I actually think the example shows a clear disregard for Object Orientated principles. http://www.youtube.com/watch?v=4F72VULWFvc
One of my lecturers wrote the following at the top of our course notes: Contrary to popular opinion using OOP does NOT mean "thou shalt make every last thing an object"
Tell that to Java developers :)
Re: Criminal Overengineering
#7I don't think I've ever read a rant about code smells which couldn't be trivially fixed with basic functional programming principles.
Re: Criminal Overengineering
#8I think this one line sums up my views about a lot of trendy software development practices:
> If you're about to take a hundred lines to write what you could in ten, stop and ask yourself this: what the fuck?
TDD advocacy is my pet hate for this today. I read an article the other day that managed to turn Hello, world into about half a dozen source files and dozens of lines of code, all pulled together with a makefile several times longer than the whole effort should have been, and seemed to be claiming some sort of profound revelation from doing this!
The quote is also a succint analysis of why C++ and Java are becoming less useful every year, relative to the field of programming languages as a whole.
And of course, as in the example in the article, it's good for bashing people who think tools like design patterns must be used everywhere, regardless of whether they actually help to keep a design clean and maintainable.
Re: Criminal Overengineering
#9Part of the problem is that a language like Java:
1. Is verbose by its very nature 2. Has language characteristics that push the developer in the direction of using design patterns at every opportunity.
So what might be a 1000 line program in Ruby is a 3000 line program in Java (translated as directly as possible), but then the deficiencies of the language turns simple idioms in a powerful language into complex design patterns in Java. See: closures, lack of duck typing/deficient type system, etc.
Re: Criminal Overengineering
#10I completely disagree with the example given in this blog. I don't have time to give a full explaination but I believe the google clean code talks gives a far better arguement than I ever could. On the general principle I agree that overengineering is to be avoided, but I actually think the example shows a clear disregard for Object Orientated principles. http://www.youtube.com/watch?v=4F72VULWFvc
So what's wrong with using a switch statement if all you have are 3 operations? Even if more operations had to be added I'd probably let it grow to the point where the method the switch is in was getting a bit unwieldy then look at refactoring it using a pattern if I really thought it would be worth it.
Depends whether it's in a library where extensibility is a feature.