COS 260 DAY 14 Tony Gauvin.

Slides:



Advertisements
Similar presentations
Lilian Blot Announcements Teaching Evaluation Form week 9 practical session Formative Assessment week 10 during usual practical sessions group 1 Friday.
Advertisements

Comp1004: Building Better Classes II Software Design Partly based on BlueJ Book – Chapter 7.
Copyright by Scott GrissomCh 7 Designing Classes Slide 1 Well Designed Classes (Ch 7) Applications are a collection of interacting classes Our Goal It.
Lesson-06 Designing classes
Designing classes How to write classes in a way that they are easily understandable, maintainable and reusable 4.0.
Objects First With Java A Practical Introduction Using BlueJ Designing object-oriented programs How to write code in a way that is easily understandable,
Module: Definition ● A logical collection of related program entities ● Not necessarily a physical concept, e.g., file, function, class, package ● Often.
Objects First with Java A Practical Introduction using BlueJ
Designing Classes How to write classes in a way that they are easily understandable, maintainable and reusable.
Well-behaved objects Improving your coding skills 1.0.
Design: Coupling and Cohesion How to write classes in a way that they are easily understandable, maintainable and reusable.
Make Sure You Know All This!. Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling 2 Objects and Classes.
CO320 Introduction to Object- Oriented Programming Michael Kölling 3.0.
5.0 Objects First with Java A Practical Introduction using BlueJ David J. Barnes Michael Kölling.
Chapter 7 Designing Classes. Class Design When we are developing a piece of software, we want to design the software We don’t want to just sit down and.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Liang, Introduction to Java Programming, Sixth Edition, (c) 2007 Pearson Education, Inc. All rights reserved Chapter 12 Object-Oriented.
Designing classes How to write classes in a way that they are easily understandable, maintainable and reusable 5.0.
Designing classes How to write classes in a way that they are easily understandable, maintainable and reusable 3.0.
Chapter 7 Object-Oriented Design Concepts
Designing Classes 2 How to write classes in a way that they are easily understandable, maintainable and reusable.
Designing classes How to write classes in a way that they are easily understandable, maintainable and reusable 5.0.
JAVA: An Introduction to Problem Solving & Programming, 7 th Ed. By Walter Savitch ISBN © 2015 Pearson Education, Inc., Upper Saddle River,
Designing Classes. Software changes Software is not like a novel that is written once and then remains unchanged. Software is extended, corrected, maintained,
Final Review. From ArrayLists to Arrays The ArrayList : used to organize a list of objects –It is a class in the Java API –the ArrayList class uses an.
1 COS 260 DAY 14 Tony Gauvin. 2 Agenda Questions? 6 th Mini quiz graded  Oct 29 –Chapter 6 Assignment 4 will be posted later Today –First two problems.
JAVA: An Introduction to Problem Solving & Programming, 7 th Ed. By Walter Savitch ISBN © 2015 Pearson Education, Inc., Upper Saddle River,
Objects First With Java A Practical Introduction Using BlueJ Designing classes How to write classes in a way that they are easily understandable, maintainable.
1 COS 260 DAY 12 Tony Gauvin. 2 Agenda Questions? 5 th Mini quiz –Chapter 5 40 min Assignment 3 Due Assignment 4 will be posted later (next week) –If.
1 COS 260 DAY 22 Tony Gauvin. 2 Agenda Questions? 9 th Mini Quiz corrected –Good results Assignment 5 Not corrected yet Assignment 6 Posted (one more)
1 COS 260 DAY 18 Tony Gauvin. 2 Agenda Questions? 7 th Mini quiz Graded –Good results 8 th Mini Quiz –Chap 8  Next class Assignment 4 Due Assignment.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
CSCE 240 – Intro to Software Engineering Lecture 3.
6.0 Objects First with Java A Practical Introduction using BlueJ David J. Barnes Michael Kölling.
Designing classes How to write classes in a way that they are easily understandable, maintainable and reusable 6.0.
Review. Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Objects and Classes Objects and Classes –State.
for-each PROS CONS easy to use access to ALL items one-by-one
Objektorienterad programmering d2, förel. 8
DESIGNING CLASSES THE GAME OF LIFE
CSC 222: Object-Oriented Programming Spring 2017
Objects First with Java A Practical Introduction using BlueJ
CSC 221: Computer Programming I Spring 2010
CSC 221: Computer Programming I Fall 2005
Data Abstraction: The Walls
COS 260 DAY 17 Tony Gauvin.
COS 260 DAY 23 Tony Gauvin.
COS 260 DAY 19 Tony Gauvin.
Objects First with Java
Understanding class definitions
Objects First with Java A Practical Introduction using BlueJ
COS 260 DAY 9 Tony Gauvin.
COS 260 DAY 13 Tony Gauvin.
Objects First with Java
COS 260 DAY 19 Tony Gauvin.
COS 260 DAY 11 Tony Gauvin.
COS 260 DAY 11 Tony Gauvin.
COS 260 DAY 16 Tony Gauvin.
COS 260 DAY 10 Tony Gauvin.
COS 260 DAY 2 Tony Gauvin.
COS 260 DAY 18 Tony Gauvin.
COS 260 DAY 8 Tony Gauvin.
COS 260 DAY 15 Tony Gauvin.
COS 260 DAY 16 Tony Gauvin.
Objects First with Java A Practical Introduction using BlueJ
COS 260 DAY 11 Tony Gauvin.
COS 260 DAY 23 Tony Gauvin.
Objektorienterad programmering d2, förel. 8
COS 260 DAY 4 Tony Gauvin.
COS 260 DAY 23 Tony Gauvin.
Objects First with Java A Practical Introduction using BlueJ
Presentation transcript:

COS 260 DAY 14 Tony Gauvin

Agenda Questions? Assignment 3 Due Assignment 4 posted Due 0ct 31 Midterm grade (advisory only) posted based on Assignment 1 & 2 and highest 4 out of 5 quizzes Mini-quiz Six will be on Tuesday, Oct 24 Designing classes

Capstone Project Capstone Project Description Fall 2017.pdf October 2 Proposal Due E-mailed to Tony in Blackboard October 27 Progress Report E-mailed to Tony in Blackboard November 16 Progress Report E-mailed to Tony in Blackboard November 30 Progress Report E-mailed to Tony in Blackboard December 12@8AM All Deliverables & Presentation Due Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling

Objects First with Java Designing classes How to write classes in a way that they are easily understandable, maintainable and reusable 6.0 © David J. Barnes and Michael Kölling

Main concepts to be covered Responsibility-driven design Coupling Cohesion Refactoring © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Software changes Software is not like a novel that is written once and then remains unchanged. Software is extended, corrected, maintained, ported, adapted, … The work is done by different people over time (often decades). © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Change or die There are only two options for software: Either it is continuously maintained or it dies. Software that cannot be maintained will be thrown away. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

World of Zuul Explore zuul-bad © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

The Zuul Classes Game: The starting point and main control loop. Room: A room in the game. Parser: Reads user input. Command: A user command. CommandWords: Recognized user commands. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Code and design quality If we are to be critical of code quality, we need evaluation criteria. Two important concepts for assessing the quality of code are: Coupling Cohesion © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Coupling Coupling refers to links between separate units of a program. If two classes depend closely on many details of each other, we say they are tightly coupled. We aim for loose coupling. A class diagram provides hints at where coupling exists. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Cohesion Cohesion refers to the number and diversity of tasks that a single unit is responsible for. If each unit is responsible for one single logical task, we say it has high cohesion. We aim for high cohesion. ‘Unit’ applies to classes, methods and modules (packages). © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Write a new game UMFK Blake OMS Cyr Crocker Lodge Powell Nowell Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling

A worked example to test quality Add two new directions to the 'World of Zuul': “up” “down” What do you need to change to do this? How easy are the changes to apply thoroughly? © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Up/down Extension Use of a HashMap for each room to store exits (directions and adjacent rooms ) Key is a direction Value is a (another) room exits.get(north) would return room that is north of the current room We then can add as many exist as want by add to the “exits” HashMap Would require changes to many classes (tight coupling) Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling

Loose coupling We aim for loose coupling. Loose coupling makes it possible to: understand one class without reading others; change one class with little or no effect on other classes. Thus: loose coupling increases maintainability. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Tight coupling We try to avoid tight coupling. Changes to one class bring a cascade of changes to other classes. Classes are harder to understand in isolation. Flow of control between objects of different classes is complex. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

OOP Coupling Coupling is the amount of interdependence between programming modules Loose Coupling means little interdependence Tight Coupling means lots of interdependence Source: http://gamedevelopment.tutsplus.com/tutorials/quick-tip-the-oop-principle-of-coupling--gamedev-1935 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling

Reducing coupling Encapsulation supports loose coupling. private elements cannot be referenced from outside the class. Reduces the impact of internal changes. Responsibility-driven design supports loose coupling. Driven by data location. Enhanced by encapsulation. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Responsibility-driven design Question: where should we add a new method (which class)? Each class should be responsible for manipulating its own data. The class that owns the data should be responsible for processing it. RDD leads to low coupling. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Localizing change One aim of reducing coupling and responsibility-driven design is to localize change. When a change is needed, as few classes as possible should be affected. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Implicit coupling Linkage not necessarily expressed via data and method interactions. Can arise from assumptions about the way a class is implementing. Satisfactory resolution might require a small increase in explicit coupling. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Cohesion (reprise) Cohesion refers to the number and diversity of tasks that a single unit is responsible for. If each unit is responsible for one single logical task, we say it has high cohesion. We aim for high cohesion. ‘Unit’ applies to classes, methods and modules (packages). © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

High cohesion We aim for high cohesion. High cohesion makes it easier to: understand what a class or method does; use descriptive names for variables, methods and classes; reuse classes and methods. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Loose cohesion We aim to avoid loosely cohesive classes and methods: Methods performing multiple tasks. Classes modeling multiple entities. Classes having no clear identity. Modules/Packages of unrelated classes. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Cohesion applied at different levels Class level: Classes should represent one single, well defined entity. Method level: A method should be responsible for one and only one well defined task. Module/Package level: Groups of related classes. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Cohesion as explained by Jack Palance Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling

Code duplication Code duplication is an indicator of bad design, makes maintenance harder, can lead to introduction of errors during maintenance. Very frustrating to Trouble Shoot to maintain code that has duplications. You can’t just fix one part you have find all the duplications Fix Code duplications in Game (page 289 291) Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling

A worked example to test quality Add two new directions to the 'World of Zuul': “up” “down” What do you need to change to do this? How easy are the changes to apply thoroughly? © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Up/down Extension Use of a HashMap for each room to store exits (directions and adjacent rooms ) Key is a direction Value is a (another) room exits.get(north) would return room that is north of the current room We then can add as many exist as want by add to the “exits” HashMap Would require changes to many classes (tight coupling) Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling

Process to add up and down Change Room Class Make fields private Add accessor (page 295) Change Game class Use accessor in goRoom method Change printLocatioInfo Add hashMap to Room (page 296) Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling

Thinking ahead When designing a class, we try to think about changes likely to be made in the future. We aim to make those changes easy. Requires a little more effort now to greatly reduce effort later. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Refactoring When classes are maintained code is usually added. Classes and methods tend to become longer. Every now and then, classes and methods should be refactored to maintain cohesion and low coupling. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Refactoring and testing When refactoring code, separate the refactoring from making other changes. First do the refactoring only, without changing the functionality. Test before and after refactoring to ensure that nothing was broken. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Design questions Common questions: How long should a class be? How long should a method be? These can now be answered in terms of cohesion and coupling. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Design guidelines A method is too long if it does more then one logical task. A class is too complex if it represents more than one logical entity. Note: these are guidelines - they still leave much open to the designer. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Enumerated Types A language feature. Uses enum instead of class to introduce a type name. Their simplest use is to define a set of significant names. Alternative to static int constants. When the constants’ values would be arbitrary. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

A basic enumerated type public enum CommandWord { // A value for each command word, // plus one for unrecognised commands. GO, QUIT, HELP, UNKNOWN; } Each name represents an object of the enum type, e.g., CommandWord.HELP. Enum objects are not created directly. Enum definitions can also have fields, constructors and methods. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Review Programs are continuously changed. It is important to make this change possible. Quality of code requires much more than just performing correct at one time. Code must be understandable and maintainable. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.

Review Good quality code avoids duplication, displays high cohesion, low coupling. Coding style (commenting, naming, layout, etc.) is also important. There is a big difference in the amount of work required to change poorly structured and well structured code. © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved.