2. GoodOO Programming Practice in Java © Allan C. Milne v15.1.22

3. Agenda.  Good programming practice.  State and constructors.  Behaviour and methods.  The final keyword.  Enum types.

4. Review source code. This presentation will ask questions that require you to review the source code for the TiledMap3_0 class. This will be handed out in the lecture, or you can download it from the link in the practical page. Good practice is based around treating a source code file as a readable entity in its own right; –not just looking at the bits and pieces of code you might be interested in at some particular point.

5. Header commentary. Should be able to write this before you start coding. Keep up to date as your code is modified. Why is each piece of information included?

6. Layout. An IDE (e.g. Eclipse) should handle the indentation for you in an intelligent way; –why is indentation important? You are responsible for how much you put on each line and where and how many blank lines there are; –these can be useful in partitioning your code but can also be very distracting if over-used.

7. Naming convention. You are responsible for naming variables, fields, enumerations, methods, etc. Use meaningful names. Use a consistent naming convention. Consider how the names are used, not just where they are declared. What conventions have I used?

8. Comments. Comments are the internal documentation of your system. Don't overdo the comments; –so don't state the obvious; –but do explain the unusual. Explain things that are problem-oriented (rather than programming). comments can be used to automatically generate external documentation; –e.g. javadoc.

9. Read and appraise. Always read over your own source code, not just for the coding but also the comments, layout and naming. Compare the source handed out in this lecture with the TiledMap2_0 class code presented previously; –I trust you know which one is better; –but why?

10. Literal constants. What are they? It is bad practice to embed these within method body code. –Why? –What is the alternative? Think about the maintainability and robustness of your code.

11. State. An object has an internal state. –Normally Defined by fields. Always make fields private; –If a client needs access then expose a public getter and/or setter method. –Why is it bad practice to have public fields? Differentiate between fields that are –fundamental to the object being modelled; and –Part of the internal implementation.

12. Constructor methods. Constructors define how objects of the class can be created (or instantiated). Overloaded constructors allow alternative client usage. The role of a constructor is normally to initialise the state of the object; –i.e. the values of the fields. The TiledMap3_0 constructor fully defines the initial state of an object.

13. What About TiledMap3_0() ? Would initialise an “empty” object. Consider the implications of this: –Does an empty object have a meaning in the problem domain? –fields now require setter properties. –Compromises security with respect to read-only fields. Often a sign of laziness in design.

14. Get or Set? The combination of get and set for a field relates to whether it is –read-only, –write-only, or –read-write. Choose the get/set for good reasons; –Think about how it is used; –What attribute of the entity being modelled does it represent? –Does the access reflect how this attribute is exposed by the real entity?

15. Consider validation. A setter method should validate that the value being set is valid. If invalid then what should the setter do?. –Do nothing. –Set the field to some default value. –Throw an exception. What about the set(x,y,value) setter in TiledMap3_0?

16. Behaviour and methods. Public methods define the behaviour that objects of the class exhibit; –the public API. These should reflect the behaviour of the entity being modelled. Think first about WHAT the method does; –This defines the method signature. Only then think about HOW the method will do it. –This is the implementation of the method body.

17. We need to know … what a method does; –reflected in the name. what information it requires; –defined by the formal parameters. what the method returns; –its return value type. This information forms the method signature.

18. Document this. It is good practice to document this for each method via comments. Remember the reader is assumed to be able to read the Java code so document –the role of the method; –what the parameters represent; –what the return value means. –all this in the context of the problem domain, not Java code.

19. The final keyword. Use liberally in your code to –document your menaing; –allow the Java compiler to optimise. –The use of this keyword has different meanings for different Java components.

20. final classes. The class cannot be subclassed. All methods are implicitly final. Makes a secure class that you know cannot be compromised by a subclass overriding its state and behaviour. Allows for efficient representation by the compiler.

21. final methods. A final method cannot be overridden or hidden in a subclass. Use this to ensure that required implementation of behaviour is not compromised by a subclass.

22. final variables and fields. Their values cannot be changed after initialization: –in their declaration; –by an assignment statement. final fields must be initialized by all constructors. If they are of a reference type then it is the reference that is final; –the object referred to can still be changed.

23. Enum types. An enum is a user-defined type that defines a set of named constant values for that type; –variables or fields of an enum type can only contain these defined enum values. Why are enumerations useful? –Readability, –security, –maintainability.

24. Enumeration surprises. Java provides a different structure to enumerations than in other languages. Each enumeration value can also be associated with additional state; –private constructor; –private field(s); –public getter(s) for the state. The enum value is as before but there will now be additional getter(s) that can access the additional state for a specific value.

25. public enum Gender { MALE (“Mr.”), FEMALE (“Ms.”); private final String mPrefix; private Gender (String aPrefix) { mPrefix = aPrefix; } public String prefix() { return mPrefix; } } // end Gender enum type.

26. Enum in the tiled map. Representing a map as a 2D array of booleans only represents whether or not a tile is passable or impassable. Define enum Terraintype to represent tiles of grass, water, tree, etc. Represent the map by a 2D array of Terraintype values: –private final TerrainType[][] mMap;

27. Remember … An enumeration is a type; –It also defines valid values for that type. The enum type can then be used to declare the types of variables, fields, parameters, return values, etc. So make sure you differentiate between –The enum type; TerrainType –A value of this type. E.g. TerrainType.GRASS

28. You are now expected to… … include appropriate commentary in your source code; … layout your source code in a readable manner; … use a meaningful naming convention; … avoid the use of literal constants in method code; … provide appropriate constructor methods; … use enum types where appropriate.