1. Packages

2. 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…?

3. 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

4. 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

5. RHS – SOC 5 Packages in Java

6. 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)

7. RHS – SOC 7 Packages in Java

8. 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

9. RHS – SOC 9 Packages in Java Just click ”Refactor”

10. 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

11. RHS – SOC 11 Packages in Java

12. 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

13. 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

14. 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();

15. 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();

16. 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”

17. 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

18. 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

19. 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

20. 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

21. 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();

22. 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

23. 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

24. 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?

25. 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)

26. RHS – SOC 26 Data Layer Logic Layer GUI Layer Balance Service Withdraw Service Deposit Service Organising packages Deposit GUI Deposit Logic Deposit Data Withdraw GUI Withdraw Logic Withdraw Data Balance GUI Balance Logic Balance Data

27. 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

28. 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?