+ All Categories
Home > Documents > Micro Patterns in Java Code The Unbelievable Simplicity of real Object Oriented Programming Yossi...

Micro Patterns in Java Code The Unbelievable Simplicity of real Object Oriented Programming Yossi...

Date post: 22-Dec-2015
Category:
View: 212 times
Download: 0 times
Share this document with a friend
22
Micro Patterns in Java Code The Unbelievable Simplicity of real Object Oriented Programming Yossi Gil Technion joint work with Itay Maman Research supported in part by IBM HRL June 9 2005 , Netanya Academic College Israeli Conference on Software, Engineering and Management (ICSEM 2005)
Transcript
  • Slide 1
  • Micro Patterns in Java Code The Unbelievable Simplicity of real Object Oriented Programming Yossi Gil Technion joint work with Itay Maman Research supported in part by IBM HRL June 9 2005, Netanya Academic College Israeli Conference on Software, Engineering and Management (ICSEM 2005)
  • Slide 2
  • 2/20 A Classical Class in C++ typedef basic_string, allocator > string; template class basic_string { // 300 dense lines of C++ declarations }; You call this simple?!?!?
  • Slide 3
  • 3/20 Is Java any Better? Lets look at a classical example, drawn from: Sun Development Network Tutorial and Code Camps Essentials of the Java programming language Lesson 8: Object-Oriented Programming The lead question: How Do These Concepts* Translate into Code? *Object, Message, Class, Inheritance
  • Slide 4
  • 4/20 How Do These Concepts* Translate into Code? *Object, Message, Class, Inheritance Class ClickMe /** * ClickMe.java is used by ClickMeApp. java. ClickMe is a * component that puts a spot wherever you click. It requires * another file: Spot. java. */ import javax.swing.BorderFactory; import javax.swing.JComponent; import java.awt.*; import java.awt.event.*; public class ClickMe extends JComponent implements MouseListener { private Spot spot = null; private static final int RADIUS = 7; private Color spotColor = new Color(107, 116, 2); //olive /** Creates and initializes the ClickMe component. */ public ClickMe() { addMouseListener(this); // Hint at good sizes for this component. setPreferredSize(new Dimension(RADIUS * 30, RADIUS * 15)); setMinimumSize(new Dimension(RADIUS * 4, RADIUS * 4)); //Request a black line around this component. setBorder(BorderFactory.createLineBorder(Color.BLACK)); } // Methods required by the MouseListener interface. public void mousePressed(MouseEvent event) { if (spot == null) { spot = new Spot(); spot.setSize(RADIUS); } spot.x = event.getX(); spot.y = event.getY(); repaint(); } public void mouseClicked(MouseEvent event) {} public void mouseReleased(MouseEvent event) {} public void mouseEntered(MouseEvent event) {} public void mouseExited(MouseEvent event) {} /** * Paints the ClickMe component. This method is * invoked by the Swing component-painting system. */ public void paintComponent(Graphics g) { /** * Copy the graphics context so we can change it. * Cast it to Graphics2D so we can use antialiasing. */ Graphics2D g2d = (Graphics2D)g.create(); // Turn on antialiasing, so painting is smooth. g2d.setRenderingHint( RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON); // Paint the background. g2d.setColor(Color.WHITE); g2d.fillRect(0, 0, getWidth() - 1, getHeight() - 1); // Paint the spot. if (spot != null) { int radius = spot.getSize(); g2d.setColor(spotColor); g2d.fillOval(spot.x - radius, spot.y - radius, radius * 2, radius * 2); } }
  • Slide 5
  • 5/20 A Birds Eye View on ClickMe import javax.swing.BorderFactory; import javax.swing.JComponent; import java.awt.*; import java.awt.event.*; public class ClickMe extends JComponent implements MouseListener { private Spot spot = null; private static final int RADIUS = 7; private Color spotColor = new Color(107, 116, 2); public ClickMe() { } public void paintComponent(Graphics g) {} public void mousePressed(MouseEvent event) { }} public void mouseClicked(MouseEvent event) {} public void mouseReleased(MouseEvent event) {} public void mouseEntered(MouseEvent event) {} public void mouseExited(MouseEvent event) {} } Still, not simple enough
  • Slide 6
  • 6/20 A Really Simple Java Class? class Example { public static void main(String args[]){ System.out.println("Hi, Dad!"); } } public?!? static?!? void?!?
  • Slide 7
  • 7/20 The Complexity Hypothesis Classes are not simple, because they come in so many different varieties
  • Slide 8
  • The Enormous Design Space of a Single Java Class Which interfaces does it implement ? Which class, if any, does it extend ? Is it final, abstract or neither? Is it inner, local, anonymous or neither of these? For each member, designer must select Multiplicity: instance or static ? Visibility: private, public, protected, or default? Kind: field, method, constructor, or initializer? If it is a field Is it final or not? Is it initialized? If it is a method Sort: Is it final, abstract, or neither? If it is non-abstract Inheritance: Is it overriding, refining, or extending? Signature?
  • Slide 9
  • 9/20 Programmers rarely use the many different alternatives offered by the design space of the underlying language. Example: There are over 40 different kinds of members (without counting signature information). Thus, there are: 1600 (=40*40) different kinds of classes with 2 members. 64000 (=40*40*40) different kinds of classes with 3 members.... Only a small fraction of these are used in practice. Rationale: People do not have time for deep pondering of all details. They reuse the same simple ideas that work over and over. Variety, Creativity, Ingenuity are reserved for the difficult cases. The Patterns Conjecture 90% of the complexity is in 10% of the code Lets concentrate on the boring 90% of the code.
  • Slide 10
  • 10/20 Micro Patterns Formal condition on the type, structure, names, and attributes of a Java class and its components. 1.Purposeful: fulfill a useful programming practice. 2.Prevalence: occurs reasonably often in real code 3.Limiting: restrict the design space variety. 4.Mechanically recognizable: by an automatic checker. 5.Simple: human understandable Similar to Design Patterns, but (i) automatable, and (ii) at a lower level of abstraction.
  • Slide 11
  • 11/20 Quick Examples Immutable: a class whose state never changes Record: has the look and feel of Pascal records Sampler: offers to customer a collection of pre-made instances Sink: does not propagate calls Stateless: carries no state information Pure type: a class with no implementation details Designator: an empty interface Implementor: gives body to abstract methods, without introducing new such methods. You did! You have been using these all the time! It is just that you never bothered to name them! These are so obvious! How come I did not think about these myself?
  • Slide 12
  • 12/20 The Micro Patterns Catalog 27 different -patterns 8 categories Wide spectrum of common programming practices Data management Wrapping Restricted creation Immutability Restrictive use of inheritance Experiment spanning over 70,000 classes Coverage: The catalog covers about 75% of the data set Informative: Contribute about 5 bits of descriptive information to each class.
  • Slide 13
  • 13/20 Benefits of -Patterns Software Understanding Only a few Complex Classes: 20-25% defeat categorization Some are a result of imperfections of our cataloging Some are truly complex: Concentrate efforts on these Documentation Terse Description: The essence of long classes can be captured by a word or two. Design Vocabulary for specifying framework structure Communication between designers Facilitate better design by providing a definitive guidance regarding how do many of the classes should look like Education: Quick introduction to the tools of the trade.
  • Slide 14
  • 14/20 Example: Mould package java.lang; import java.io.Serializable; public abstract class Number implements Serializable { public byte byteValue() { return (byte)intValue(); } public short shortValue() { return (short)intValue(); } public abstract double doubleValue(); public abstract float floatValue(); public abstract int intValue(); public abstract long longValue(); } Mould: The functionality of all abstract methods is solely by a composition of the concrete methods.
  • Slide 15
  • 15/20 The Pattern Groups Degeneracy: Degenerate State and Behavior Degenerate State Degenerate Behavior Controlled Creation Data Management: Wrappers Data Managers Inheritance Inheritors Base Classes
  • Slide 16
  • 16/20 Map -Patterns in their Categories
  • Slide 17
  • 17/20 Multiplicity of patterns
  • Slide 18
  • 18/20 Six Examples in One This class combines 6 patterns: ImmutableBox Sampler / Restricted Creation Overrider Sink FunctionObject DataManager public class ParameterMode { public static final ParameterMode IN = new ParameterMode("IN"), INOUT = new ParameterMode("INOUT"), OUT = new ParameterMode("OUT"); private String mode; private ParameterMode(String m) { mode = m; } public String toString() { return mode; } {
  • Slide 19
  • 19/20 Statistical Inference Pattern prevalence is a distinguishing mark of software Different collections tend to use different patterns at different levels. The differences in prevalence are statically significant Independent implementations of the same specification tend to use the same pattern. Progressive versions of the same software product tend to patterns at the same prevalence level.
  • Slide 20
  • 20/20 Conclusions and Further Work There is no such thing as classical classes Better vocabulary for frameworks, design, understading. Teach the tools of the trade Automatic Detection Tools Automatic Corrections Tools Nano-patterns: same, but on methods Setter Getter Factory Delegator Forwarder Verifier
  • Slide 21
  • 21/20 (An excerpt from an advanced course in OOD) Our research shows that many of the classes in the real world are of a very limited scope: Pool, Stateless (10.8%) FunctionObject (6.84%) Box, ImmutableBox, CompoundBox (19.8%) Sink (13.3%) Etc. Our notion of a typical class
  • Slide 22
  • 22/20 Again, the popularity of simple implementation patterns, suggests otherwise Our notion of inter-class relationships The analysis of relationships between classes and within parts of a class is central to the design of a system: 24.3.2 Inheritance relationships 24.3.3 Containment relationships 24.3.5 Use relationships 24.3.6 Use relationships 24.3.7 Relationships within a class (The C++ programming Language)

Recommended