Packages

RHS – SOC 2

Packages in Java

• When using NetBeans, you have (hopefully) observed that files are organised into packages

• What is the purpose of using packages…?

RHS – SOC 3

Packages in Java

• As soon as a Java project grows beyond a few classes, we should organise the classes into packages– Makes it easier for the programmer to locate

and use a specific class– Avoids name clashes– Enables a certain level of access control

RHS – SOC 4

Packages in Java

• How do I create a package…?

• Choose a proper name for it (not quite trivial, see later)

• In NetBeans:– Highlight ”Source Packages”– Right-click– Choose New | Java Package

RHS – SOC 5

Packages in Java

RHS – SOC 6

Packages in Java

• How do I create a class (or interface) within a specific package…?

• You have (hopefully) already tried this • In NetBeans:

– Highlight the package in which to put the new class (or interface)

– Right-click– Choose New | Java Class (or Interface)

RHS – SOC 7

Packages in Java

RHS – SOC 8

Packages in Java

• How do I move a class from one package to another package…?

• In NetBeans:– Use drag-and-drop– Drag the class to the new package, and

release it there– This is formally considered to ”refactor” the

class, so a dialog appears

RHS – SOC 9

Packages in Java

Just click ”Refactor”

RHS – SOC 10

Packages in Java

• What happens ”under the hood”…?

• Actually, not very much…– When a new package is created, a new

subfolder with that name is created in the project folder

– When a class is created in a package, the package statement in the class is set to the name of that package

RHS – SOC 11

Packages in Java

RHS – SOC 12

Naming a package

• One purpose of placing classes in packages is to avoid name clashes

• A name clash occurs when two classes in the same package have the same name

• Compiler cannot distinguish the classes

• However, two classes with the same name – but placed in different packages – is perfectly legal

RHS – SOC 13

Naming a package

// These two classes are unrelated…

jane.Square jS = new jane.Square();

...

graphics.Square gS = new graphics.Square();

// Note that the fully qualified names of

// the classes are used

RHS – SOC 14

Naming a package

// This is legal..

import jane.Square;

// This now means jane.Square

Square jS = new Square();

...

graphics.Square gS = new graphics.Square();

RHS – SOC 15

Naming a package

// This is NOT legal..

import jane.Square;

import graphics.Square

// cannot determine what Square means…

Square jS = new Square();

...

Square gS = new Square();

RHS – SOC 16

Naming a package

• Using packages does not save us completely from name clashes

• What if two packages have the same name…?

• A package name should preferably be unique ”world-wide”

RHS – SOC 17

Naming a package

• How can we make package names unique…?

• Impossible…but we can try our best • One convention is to name packages:

companyName.packageName

• or (to avoid internal name clashes)

companyName.regionName.packageName

RHS – SOC 18

Naming a package

• In student projects, name clashes it not really a problem in practice

• Only matters if someone else is going to use your classes

• Common practice to start a class name with a lowercase letter, to avoid confusion with classes themselves

RHS – SOC 19

Using a package

• A class can use a class in a different package in several ways:– Use fully qualified name– Import specific class– Import entire package

RHS – SOC 20

Using a package

• Fully qualified name

• When refering to the class, prefix the class name with the package name, like:

graphics.Rectangle• No need for import statements

• Fine if you only refer to classes outside your own package a few times

RHS – SOC 21

Using a package

• Import specific class

• Use an import statement, like:

import graphics.Rectangle;

• You can then refer to the class just by the class name:

Rectangle r = new Rectangle();

RHS – SOC 22

Using a package

• Import all classes in a package

• Use an import statement, like:

import graphics.*;

• You can then refer to all classes in that package just by the class name

RHS – SOC 23

Using a package

• NB: Packages do not form a hierarchy!

• Suppose we have packages:graphics

graphics.2d

graphics.3d

• The statement import graphics.* will only import the classes in graphics, not the classes in the other libraries

RHS – SOC 24

Organising packages

• The big question is now:

• How should we actually organise the classes into packages…?

• More specifically; along which ”dimensions” should we create packages?

RHS – SOC 25

Organising packages

• In any system architec-tures, we have two main ”dimensions”– Functional layers (GUI,

business logic, data)– Services (isolated pieces of

functionality)

RHS – SOC 26

DataLayer

LogicLayer

GUI Layer

Balance Service

Withdraw Service

Deposit Service

Organising packages

DepositGUI

DepositLogic

DepositData

WithdrawGUI

WithdrawLogic

WithdrawData

BalanceGUI

BalanceLogic

BalanceData

RHS – SOC 27

Organising packages

• There is no ”silver bullet” to how to organise packages

• Use common sense!

• Try to avoid packages with just one or two classes

• Also try to avoid packages with too many (>10 ?) classes

RHS – SOC 28

Exercises

• Download the three NetBeans projects listed below (found on the website, under Classes – week 44)– AbstractFactoryExample

– CarRentalDB

– CommandExample

• For each project, consider what would be the most relevant way of reorganising the classes

• Try to reorganise the classes in each project, by defining new packages, and moving the classes to packages

• Take a look inside the classes – what has changed?• Also take a look inside the folders for the projects – what has

changed?