Making Steaks from Sacred Cows

1. Making Steaks from Sacred Cows @KevlinHenney kevlin@curbralan.com

2. © BBC

3. I see Keep Out signs as suggestions more than actual orders. Like Dry Clean Only.

4. Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming can also refer to the results of applying a design pattern or coding style blindly without understanding the reasons behind that design principle. http://en.wikipedia.org/wiki/Cargo_cult_programming

6. Une Idée

7. Rien n'est plus dangereux qu'une idée, quand on n'a qu'une idée. Émile-Auguste Chartier

8. Nothing is more dangerous than an idea, when you have only one idea. Émile-Auguste Chartier

9. Nothing is more dangerous than an IDE, when you have only one IDE.

10. I currently have an average of 15-25 imports in each source file, which is seriously making my code mixed-up and confusing. Is too many imports in your code a bad thing? Is there any way around this? http://stackoverflow.com/questions/8485689/too-many-imports-spamming-my-code

11. It's normal in Java world to have a lot of imports. Not importing whole packages is good practice. It's a good practice to import class by class instead of importing whole packages. http://stackoverflow.com/questions/8485689/too-many-imports-spamming-my-code

12. Why?

13. It is not a problem. Any IDE will manage imports and show them to you only when needed. Most IDEs support code folding where all the imports are folded down to one line. I rarely even see my imports these days as the IDE manages them and hides them as well. Any good IDE, such as Eclipse, will collapse the imports in one line, and you can expand them when needed, so they won't clutter your view. http://stackoverflow.com/questions/8485689/too-many-imports-spamming-my-code

15. It is not a problem. Any IDE will manage imports and show them to you only when needed. Most IDEs support code folding where all the imports are folded down to one line. I rarely even see my imports these days as the IDE manages them and hides them as well. Any good IDE, such as Eclipse, will collapse the imports in one line, and you can expand them when needed, so they won't clutter your view. http://stackoverflow.com/questions/8485689/too-many-imports-spamming-my-code

16. It is not a problem. Any IDE will manage imports and show them to you only when needed. Most IDEs support code folding where all the imports are folded down to one line. I rarely even see my imports these days as the IDE manages them and hides them as well. Any good IDE, such as Eclipse, will collapse the imports in one line, and you can expand them when needed, so they won't clutter your view. http://stackoverflow.com/questions/8485689/too-many-imports-spamming-my-code

17. What is the Matrix? Control. The Matrix is a computer-generated dream world built to keep us under control in order to change a human being into this. © Warner Bros.

18. I currently have an average of 15-25 imports in each source file, which is seriously making my code mixed-up and confusing. Yes? Is too many imports in your code a bad thing? Yes. Is there any way around this? Yes!

20. Avoid Long Import Lists by Using Wildcards Long lists of imports are daunting to the reader. We don't want to clutter up the tops of our modules with 80 lines of imports. Rather we want the imports to be a concise statement about which packages we collaborate with.

21. import java.util.ArrayList; import java.util.Collection; import java.util.HashMap; import java.util.HashSet; import java.util.LinkedHashMap; import java.util.LinkedHashSet; import java.util.LinkedList; import java.util.List; import java.util.Map; import java.util.NavigableMap; import java.util.NavigableSet; import java.util.Set; import java.util.SortedMap; import java.util.SortedSet; import java.util.TreeMap; import java.util.TreeSet;

22. import java.util.*;

23. import java.beans.Introspector; import java.lang.reflect.Array; import java.lang.reflect.Constructor; import java.lang.reflect.Method; import java.lang.reflect.Modifier; import java.lang.reflect.Proxy; import java.util.Arrays; import java.util.Collection; import java.util.Collections; import java.util.HashMap; import java.util.HashSet; import java.util.Iterator; import java.util.LinkedHashSet; import java.util.Map; import java.util.Set;

24. import java.beans.*; import java.lang.reflect.*; import java.util.*;

25. import java.awt.*; import java.util.*; List?

26. import java.awt.*; import java.util.*; import java.util.List;

28. Open–Closed Principle

30. The principle stated that a good module structure should be both open and closed: Closed, because clients need the module's services to proceed with their own development, and once they have settled on a version of the module should not be affected by the introduction of new services they do not need. Open, because there is no guarantee that we will include right from the start every service potentially useful to some client.  

31. [...] A good module structure should be [...] closed [...] because clients need the module's services to proceed with their own development, and once they have settled on a version of the module should not be affected by the introduction of new services they do not need.

32. Published Interface is a term I used (first in Refactoring) to refer to a class interface that's used outside the code base that it's defined in. Martin Fowler http://martinfowler.com/bliki/PublishedInterface.html

34. There is no problem changing a method name if you have access to all the code that calls that method. Even if the method is public, as long as you can reach and change all the callers, you can rename the method.

35. There is a problem only if the interface is being used by code that you cannot find and change. When this happens, I say that the interface becomes a published interface (a step beyond a public interface).

36. Published Interface is a term I used (first in Refactoring) to refer to a class interface that's used outside the code base that it's defined in. The distinction between published and public is actually more important than that between public and private. The reason is that with a non-published interface you can change it and update the calling code since it is all within a single code base. [...] But anything published so you can't reach the calling code needs more complicated treatment. Martin Fowler http://martinfowler.com/bliki/PublishedInterface.html

37. [...] A good module structure should be [...] open [...] because there is no guarantee that we will include right from the start every service potentially useful to some client.

38. extends extends

39. A myth in the object-oriented design community goes something like this: If you use object-oriented technology, you can take any class someone else wrote, and, by using it as a base class, refine it to do a similar task. Robert B Murray C++ Strategies and Tactics

41. Design and implement for inheritance or else prohibit it By now, it should be apparent that designing a class for inheritance places substantial limitations on the class.

43. Bertrand Meyer gave us guidance as long ago as 1988 when he coined the now famous open-closed principle. To paraphrase him: Software entites (classes, modules, functions, etc.) should be open for extension, but closed for modification. Robert C Martin "The Open-Closed Principle" C++ Report, January 1996

44. http://blog.8thlight.com/uncle-bob/2014/05/12/TheOpenClosedPrinciple.html

45. I've heard it said that the OCP is wrong, unworkable, impractical, and not for real programmers with real work to do. The rise of plugin architectures makes it plain that these views are utter nonsense. On the contrary, a strong plugin architecture is likely to be the most important aspect of future software systems. http://blog.8thlight.com/uncle-bob/2014/05/12/TheOpenClosedPrinciple.html

46. public abstract class Shape { ... } public class Square : Shape { ... public void DrawSquare() ... } public class Circle : Shape { ... public void DrawCircle() ... }

47. public abstract class Shape ... public class Square : Shape ... public class Circle : Shape ... static void DrawAllShapes(Shape[] list) { foreach(Shape s in list) if(s is Square) (s as Square).DrawSquare(); else if(s is Circle) (s as Circle).DrawCircle(); }

48. public abstract class Shape ... public class Square : Shape ... public class Circle : Shape ... static void DrawAllShapes(Shape[] list) { foreach(Shape s in list) if(s is Square) (s as Square).DrawSquare(); else if(s is Circle) (s as Circle).DrawCircle(); }

49. public abstract class Shape { ... public abstract void Draw(); } public class Square : Shape { ... public override void Draw() ... } public class Circle : Shape { ... public override void Draw() ... }

50. public abstract class Shape ... public class Square : Shape ... public class Circle : Shape ... static void DrawAllShapes(Shape[] list) { foreach(Shape s in list) s.Draw(); }