Date post: | 19-Dec-2015 |
Category: |
Documents |
View: | 221 times |
Download: | 1 times |
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 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 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 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 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?