Lab 5. Other things. Changes in the schedule. Will add time slots for design presentations on Tuesday, Feb 28. Disciplin.

Size: px

Start display at page:

Download "Lab 5. Other things. Changes in the schedule. Will add time slots for design presentations on Tuesday, Feb 28. Disciplin."

Bartholomew Black
6 years ago
Views:

this and super Examples Mutable and Immutable Objects D0010E Lecture 12 The Engineering of Computer Programming Side-effects Method Categories Finite State Machines Lab 5 The last lab assignment

1 this and super Examples Mutable and Immutable Objects D0010E Lecture 12 The Engineering of Computer Programming Side-effects Method Categories Finite State Machines Lab 5 The last lab assignment includes a first step where you design your solution. UML diagram + explanations (on paper) For each class: What does it represent? What is its responsibility? This is mandatory. You are not allowed to start with the programming until you have presented your design for a teacher and had it approved. 2 Other things Changes in the schedule. Rearrangements within the modul, so no big deal. Will add time slots for design presentations on Tuesday, Feb 28. Disciplin. The Engineering of Programming Through the years, practical programmers have identified many principles that influence the life of a programmer: Three important ones are: locality, side-effects, and method classification. 3 4

a) Create high locality Code has locality if it relies on and effects local data and methods. Place data together with methods that access the data.

2 a) Create high locality Code has locality if it relies on and effects local data and methods. Place data together with methods that access the data. Advantage: Parts of a program that has high locality can be understood with only little understanding of the entire program. Encapsulation of data in classes (using private) is an example of how high locality can often be achieved. A private attribute can, for instance, only be accessed in the class containing the attribute. Global variables have low locality. This is why variables should not be public. Strive to write code that has high "locality". b) Avoid hidden side-effects Avoid methods that cause side-effects in the dark. Such a side-effect is a change of a variable that can not be inferred from the call to the method. Easy to forget about the side-effects, which might result in programming errors. If you have to use side-effects: Give methods clear and meaningful names that signal to a programmer that side-effects will occur. Document properly. 5 6 c) Method categories c) Method categories Classify methods into two categories only: Functions that always return the same result given the same arguments. Like mathematical functions. Procedures that have no return type (declared void) and only cause change in this and objects referred to by arguments. Avoid creating mixed methods. An example: If we know that f is a function, f(x) == f(x) is always true and Math.pow(f(x),2) is always equal to f(x)*f(x). Otherwise, such statements need not be true. 7 8

Mutable vs. immutable objects A dynamic object is mutable if its state can be changed after creation. Efficient, but could be hard to understand. Otherwise it is immutable.

3 Mutable vs. immutable objects A dynamic object is mutable if its state can be changed after creation. Efficient, but could be hard to understand. Otherwise it is immutable. Once created, immutable objects never change. Most classes can be written so that their dynamic objects are either mutable or immutable. Mutable vs. immutable objects Advantage with immutable objects: Programmers do not need to keep track of (in their heads) how immutable objects change when the program is run. Immutable objects are also called values. Programming with immutable objects is easier because they can not change() Code is immediately understandable by just looking at it (locally). Make a clear difference between mutable and immutable objects Immutable objects Example: String Once created, a string can not be changed. However, it is always possible to create a new string from copies of other strings. The old strings are uneffected by this. No need for the programmer to keep track of how the strings change. Also, all string-methods return the same result given the same arguments. int length() char charat(int index) String replace(char oldchar, char newchar) The class Pair<A,B> shown earlier is also immutable: 11 Pair<A,B> class Pair<A, B> { private A first; private B second; public Pair(A first, B second) { this.first = first; this.second = second; public A fst() { return first; public B snd() { return second; public Pair<B, A> mirror() { return new Pair<B, A>(snd(), fst()); public String tostring() { return "(" + fst() + "," + snd() + ")"; 12

4 Problems with mutable objects During the programming, programmers have to keep track of [in their heads] how the mutable objects will change once the program is run. The language syntax does not support this. Well, comments can be written as reminders. Loosing track of the changes easily leads to mistakes and bugs. There are programming languages where mutation is not possible; in those, the problem above does not exist() Haskell Method categories Selector - Returns one part out of a multi-part state. getelement in Vector Predicate - Decides something about an object. isempty in lab 3 Generator - A method that generates a kind of object. Note: A constructor is not a method (you can t call a constructor). Transformer - Changes one object into another. Mutator - Changes the state of an object. (Combinations are possible.) Finite State Machines FSM:s are fundamental A (deterministic) finite state machine (FSM) is a model of behavior composed of a finite number of states, transitions between those states, and actions. A state stores information about the past, i.e. it reflects the input changes from the system start to the present moment. A transition indicates a state change and is described by a condition that would need to be fulfilled to enable the transition. An action is a description of an activity that is to be performed at a given moment. Also known as a finite state automaton. FSM:s are widely used in modeling application behavior, design of hardware digital systems, software engineering, compiler construction, network protocols, and the study of computation and languages. They come in two flavors: Transducers Acceptors 15 16

5 Basic parts and functionality A FSM consists of five parts: A set of states. A start state. A transition function :: (Input,State) -> State. An action function that associates an action with each transition. A set of end states. Each given moment, the machine is in one of the states. At first it is in its start state. The machine then repeatedly reads an input symbol, changes state depending on the transition function, and performs an action as defined by the action function. It stops ( halts ) when an end state is reached. 1. Transducer FSM A FSM that performs actions as it changes state. Action = Both produce output and perform some task. The actions can depend on both the transitions and the states. These are good at describing realtime systems that never should stop. Two different kinds of transducers: The Moore model, and the Mealy model Moore model Moore model Actions depend on state only. Example: An elevator door. 2 commands: "command_open" and "command_close. 2 user inputs: sensor_opened and sensor_closed. 4 states: 1. The entry action (E:) in state "Opening" starts a motor opening the door. When the door is open, a sensor detects this. 2. The entry action in state "Closing" starts a motor in the other direction closing the door. This is also detected by a sensor when the door is shut closed. 3. States "Opened" and 4. "Closed" don't perform any actions. They just signal to the outside world (e.g. to other state machines) the situation: "door is open" or "door is closed". E: stands for an action or output that happens when the state is entered. Input is either a pressed button or a sensor detecting something

Mealy tends to give smaller FSM:s but is harder to implement. Moore is easier to handle (but larger). They are often combined in practice. Fig. 4.31 Fig. 4.32 Water Dispenser 21 22 2.

6 Mealy Model Actions depend directly on transitions, that is both state and input. There are two input actions (I:): "start motor to close the door if command_close arrives" and "start motor in the other direction to open the door if command_open arrives". Mealy tends to give smaller FSM:s but is harder to implement. Moore is easier to handle (but larger). They are often combined in practice. Fig Fig Water Dispenser Acceptor FSM Figures An acceptor (or recognizer) is a FSM in which each state is labeled either accept or not accept. Also: yes or no. The machine outputs the label at the state reached when all input symbols have been processed. Used to recognize words in a language. Compilers, for example. Example: CypherLock Riley: Last paragraph on p. 167 to p Fig Fig Fig Simple example: Determines whether a binary number has an odd or even number of 0's, where S 1 is an accepting state

7 import javax.swing.*; import java.awt.event.*; public class FsmEmulator implements ActionListener { private CipherButton[] buttons; import javax.swing.jbutton; public class CipherButton extends JButton { private char symbol; public CipherButton(int x, int y, int s, char c) { super(); if (c < 'A' c > 'E') { throw new IllegalArgumentException(); else { setbounds(x, y, s, s); settext(c+""); private int nokeysentered = 0; private int okafter1 = 1, okafter2 = 2, okafter3 = 3; private int failafter1 = 4, failafter2 = 5, failafter3 = 6; private int[][] NextState = { {failafter1, okafter1, failafter1, failafter1, failafter1, {okafter2, failafter2, failafter2, failafter2, failafter2, {okafter3, failafter3, failafter3, failafter3, failafter3, {nokeysentered, nokeysentered, nokeysentered, nokeysentered, nokeysentered, {failafter2, failafter2, failafter2, failafter2, failafter2, {failafter3, failafter3, failafter3, failafter3, failafter3, {nokeysentered, nokeysentered, nokeysentered, nokeysentered, nokeysentered; private StateAction nullaction = new NullAction(); private StateAction soundalarm = new SoundAlarmAction(); private StateAction opendoor = new OpenDoorAction(); private StateAction[][] actiontable = { {nullaction, nullaction, nullaction, nullaction, nullaction, {nullaction, nullaction, nullaction, nullaction, nullaction, {nullaction, nullaction, nullaction, nullaction, nullaction, {soundalarm, soundalarm, soundalarm, opendoor, soundalarm, {nullaction, nullaction, nullaction, nullaction, nullaction, {nullaction, nullaction, nullaction, nullaction, nullaction, {soundalarm, soundalarm, soundalarm, soundalarm, soundalarm; private int currentstate; public FsmEmulator() { JFrame window = new JFrame(); window.setbounds(10, 10, 270, 90); window.getcontentpane().setlayout(null); buttons = new CipherButton[5]; for (int j=0; j = 5; j++) { buttons[j] = new CipherButton(10+j*50, 10, 50, (char)(j+'a')); buttons[j].addactionlistener(this); window.getcontentpane().add(buttons[j]); currentstate = nokeysentered; window.show(); public void actionperformed(actionevent e) { int buttonint = intvalueofbutton(e.getsource()); actiontable[currentstate][buttonint].performaction(); currentstate = NextState[currentState][buttonInt]; VendingMachine Another example implemented using switches. Instead of having matrices that define transitions and actions, here we have code that does this. private int intvalueofbutton(object btn) { return ((CipherButton)btn).getText().charAt(0) - 'A'; 27 28

8 Internal and external methods Using access modifiers, it is possible to limit the scope of declarations. private, public, protected, and package scope (no explicit modifier). We can control access this way. But when the right to access also means a right to shadow, we have to be extra careful as programmers. A final class can not be extended. Examples in Eclipse with SubClass and SubClass Internal and external methods If you like to prevent subclasses from changing the behavior of methods in super classes, separate the API from internal methods that do the work. Make each public method in the API call its corresponding internal (private) method. This is all it does. All the functionality lies in the internal method. Never make internal methods depend on external ones (methods in the API). Only use internal methods in a class. Note that this is a conscious design decision. It could be unsuitable to do it, but most often it is not. Also, note that final on a method prohibits shadowing. 31

Procedural Abstraction

Procedural Abstraction Comp-303 : Programming Techniques Lecture 5 Alexandre Denault Computer Science McGill University Winter 2004 February 16, 2004 Lecture 5 Comp 303 : Programming Techniques Page 1