Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Good Class Design - Introduction to Programming in Java - Lecture Slides, Slides of Java Programming

In this course, Introduction to Programming in Java, we learned all programming concepts and implement them in java. Key points in these lecture slides are: Good Class Design, Introduce Coupling, Cohesion, Responsibility-Driven Design, Refactoring, Zuul, Code Design Concepts, Code Duplication, Ease of Modification, Implicit Coupling

Typology: Slides

2012/2013

Uploaded on 04/22/2013

sathaye
sathaye 🇮🇳

4.8

(8)

106 documents

1 / 69

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Objectives
introduce coupling, cohesion,
responsibility-driven design, and
refactoring
7. Good Class Design
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35
pf36
pf37
pf38
pf39
pf3a
pf3b
pf3c
pf3d
pf3e
pf3f
pf40
pf41
pf42
pf43
pf44
pf45

Partial preview of the text

Download Good Class Design - Introduction to Programming in Java - Lecture Slides and more Slides Java Programming in PDF only on Docsity!

  • Objectives
    • introduce coupling, cohesion, responsibility-driven design, and refactoring

7. Good Class Design

Topics

    1. Why Class Design?
    1. World of Zuul
    1. Code Design Concepts
    1. Code Duplication
    1. Poor RDD
    1. Ease of Modification
    1. Implicit Coupling

continued Docsity.com

1. Why Class Design?

  • This part concentrates on how to create well-designed classes - getting code to work isn't enough
  • Benefits of good design:
    • simplifies debugging, modification, maintenance
    • increases the chances of reusing code

2. World of Zuul

  • We look at two versions of a simple adventure game called "World of Zuul" (Zuul for short).
  • Both versions have the same features, but the first is full of bad design choices, which I'll correct, leading to an improved second version.

Zuul Concepts

  • Zuul is quite basic:
    • the user can move between a series of rooms, get help, and quit
  • A real adventure game would allow multiple users, include hidden treasure, secret passwords, death traps, and more.

Zuul Map

pub outside theatre

lab office

rooms

exits/ doors

The user starts in the The exits are to the "outside" room. North, South, East, and West

Class Descriptions

  • ZuulGame
    • creates the rooms, the parser, and starts the game. It evaluates and executes the commands that the parser returns.
  • Parser
    • repeatedly reads a line from the terminal and interprets it as a two word command which it returns as a Command object continued Docsity.com
  • CommandWords
    • holds an array of all the command words in the game, which is used to recognise commands - "go", "quit", "help"
  • Room
    • represents a room in the game, connected to other rooms via exits. The exits are labelled "north", "east", "south", and "west".

continued Docsity.com

The First Adventure Game

  • Colossal Cave Adventure (1976) was the first computer adventure game.
  • It was designed by Will Crowther, a real-life cave explorer, who based the game's layout on part of an actual US cave system.

continued Docsity.com

  • More info:
    • http://www.rickadams.org/adventure/
    • http://en.wikipedia.org/wiki/ Colossal_Cave_Adventure

3.1. Coupling

  • Coupling refers to the links between separate units (classes) in an application.
  • If two classes depend closely on many details of each other, they are tightly coupled. Usually bad.
  • Good design aims for loose coupling. Good.

Loose Coupling

  • In class diagrams, loose coupling means less association lines
  • Loose coupling makes it possible to:
    • understand one class without reading others
    • change one class without affecting others
  • Loose coupling make debugging, maintenance, and modification easier.
  • High cohesion makes it easier to:
    • understand a class or method
    • use descriptive names
    • reuse classes or methods in other applications

3.3. Responsibility-driven Design (RDD)

  • Each class should be responsible for manipulating and protecting its own data - e.g. don't use public fields
  • RDD leads to low coupling, where code changes are localized - i.e. they only affect the class/method that is being modified