1.4-Software-Development-Principles

Packages

Leerdoelen

• Ik kan mijn code opdelen in logische packages
• Ik geef mijn packages heldere namen

Introductie

In Java worden packages gebruikt om klassen, interfaces en andere code-elementen te organiseren. Dit helpt bij het beheren van de “namespace” door het voorkomen van naamconflicten, maar verbetert ook de toegangscontrole met behulp van access modifiers. Bovendien bevordert het gebruik van packages een modulaire programmeringsbenadering, waarbij gerelateerde klassen en interfaces gegroepeerd worden, wat de code onderhoudbaar en herbruikbaar maakt.

Goed Gebruik van Packages

Naam conventies voor packages

• Java vereist dat je uitsluitend kleine letters gebruikt voor packages.
• Probeer de naam van een package een woord te laten zijn. Bijvoorbeeld, de package students bevat de Student klasse en de andere klassen die daarmee verbonden zijn.

Organisatie

Goed ontworpen packages bevatten klassen en interfaces die logisch gerelateerd zijn. Bijvoorbeeld, een package com.myapp.ui kan alle klassen bevatten die betrekking hebben op de gebruikersinterface van een applicatie.

Hier volgt twee voorbeelden van een applicatie die gebruikmaakt van package om classes die logisch bij elkaar horen te groeperen.

Voorbeeld 1: de Desktopapplicatie

Hieronder is een voorbeeld van een package-structuur voor een eenvoudige desktopapplicatie, zoals een eenvoudige notitie-app:

com.myapp
│
├── main // Entry point of the application
│   └── Main.java
│
├── models // Contains classes representing data models or entities
│   ├── Note.java
│   └── User.java
│
├── utilities // Utilities used across the application
│   ├── FileUtils.java
│   └── DateUtils.java
│
├── controllers // Logic for handling user actions and updating the view
│   ├── NoteController.java
│   └── UserController.java
│
└── views // Contains classes related to the user interface
    ├── MainFrame.java
    ├── NoteView.java
    └── LoginView.java

Bovenstaande structuur biedt een heldere scheiding van de applicatielogica:

• main: Bevat de hoofdklasse die als startpunt dient voor de applicatie.
• models: Dit package bevat de klassen die de datamodellen (entiteiten) van je applicatie vertegenwoordigen.
• utilities: Bevat utility-klassen zoals helpers en tools die nuttig zijn door de hele applicatie heen voor taken zoals datumverwerking, bestandsbeheer, enz.
• controllers: In een eenvoudig MVC (Model-View-Controller) patroon, bevat dit package de controllers die verantwoordelijk zijn voor het ontvangen van de input van de gebruiker vanuit de view, het verwerken van die input (mogelijk met behulp van de modellen), en het updaten van de views.
• views: Dit package bevat de klassen die verantwoordelijk zijn voor de gebruikersinterface van de applicatie. Dit kunnen Java Swing componenten zijn, JavaFX scenes, of andere UI-frameworks die je besluit te gebruiken.

Voor beginnende programmeurs is het belangrijk om te beginnen met een eenvoudige structuur zoals deze en naarmate je meer ervaring opdoet, kun je complexere structuren introduceren naargelang de behoeften van je projecten groeien.

Voorbeeld 2: de Webapplicatie

Hieronder is een voorbeeld van een meer gedetailleerde package-structuur voor een denkbeeldige webapplicatie:

com.myapp
│
├── main // Entry point of the application
│   └── Main.java
│
├── models // Contains classes representing data models or entities
│   ├── User.java
│   ├── Product.java
│   └── Order.java
│
├── dao // Data Access Object layer for database interactions
│   ├── UserDao.java
│   ├── ProductDao.java
│   └── OrderDao.java
│
├── services // Contains business logic
│   ├── UserService.java
│   ├── ProductService.java
│   └── OrderService.java
│
├── controllers // Handles incoming web requests and sends responses
│   ├── UserController.java
│   ├── ProductController.java
│   └── OrderController.java
│
├── utils // Utilities and helpers
│   ├── DatabaseConnection.java
│   ├── Logger.java
│   └── ValidationUtils.java
│
├── config // Configuration files and startup configurations
│   ├── AppConfig.java
│   └── DatabaseConfig.java
│
└── web // Web-specific classes like filters, listeners, etc.
    ├── filters
    │   ├── AuthenticationFilter.java
    │   └── LoggingFilter.java
    ├── listeners
    │   └── AppContextListener.java
    └── servlets
        ├── LoginServlet.java
        └── LogoutServlet.java

Deze structuur biedt weer een duidelijke scheiding van verantwoordelijkheden:

• models: Bevat de klassen die de business entiteiten van de applicatie modelleren.
• dao (Data Access Object): Voor de interactie met de database om CRUD-operaties op de modellen uit te voeren.
• services: Bevat de bedrijfslogica die tussen de controllers en de DAO-laag fungeert.
• controllers: Verantwoordelijk voor het afhandelen van de gebruikersverzoeken en het terugsturen van de reacties. In een MVC-framework zouden deze de acties verwerken.
• utils: Bevat hulpprogramma’s en helpers die door de hele applicatie kunnen worden gebruikt, zoals loggers, validators, etc.
• config: Bevat configuratieklassen die kunnen worden gebruikt om de applicatie te configureren en te initialiseren.
• web: Specifiek voor webapplicaties, bevat klassen zoals servlets, filters, en listeners die nodig zijn voor webfunctionaliteit.

Voorkomen van naamconflicten

Packages stellen je in staat om klassen met dezelfde naam te gebruiken in verschillende delen van een programma of in verschillende programma’s, omdat de volledige naam van een klasse de package naam omvat. Bijvoorbeeld, java.util.Date en java.sql.Date zijn twee verschillende klassen en kunnen tegelijkertijd in eenzelfde programma gebruikt worden.

Toegangscontrole

Packages werken nauw samen met access modifiers (public, protected, private, en default (geen modifier)) om de toegankelijkheid van klassen, methoden en variabelen te beheren.

• Public: Een klasse of lid gemarkeerd als public is overal toegankelijk.
• Protected: Toegankelijk binnen dezelfde klasse, package, of subklassen.
• Private: Alleen toegankelijk binnen dezelfde klasse.
• Default (geen modifier): Toegankelijk binnen hetzelfde package. e.g. Dit zijn de klassen die niet expliciet als public, protected of private zijn gedefinieerd.

Goed en slecht gebruik van packages

Het gebruik van packages in Java is cruciaal voor een goede organisatie, onderhoudbaarheid en toegankelijkheid van de code. Hieronder volgen enkele voorbeelden van goed en slecht gebruik van packages die de impact van deze praktijken op softwareprojecten illustreren.

Goede Organisatie

Het groeperen van klassen volgens hun functionaliteit in logisch benoemde packages, bijvoorbeeld com.myapp.model voor datamodellen, com.myapp.controller voor controllers in een MVC-applicatie, en com.myapp.utils voor utility klassen. Dit bevordert een duidelijke structuur en maakt het gemakkelijk om gerelateerde klassen te vinden.

Ongeorganiseerde Structuur

Alle klassen in één package plaatsen of een willekeurige indeling gebruiken, zoals com.myapp.main, com.myapp.stuff, en com.myapp.etc. Dit maakt het moeilijk om de structuur van de applicatie te begrijpen en verhoogt de complexiteit van onderhoud.

Consistente Naamgeving

Het gebruik van omgekeerde domeinnaamstructuur voor package namen om uniekheid te garanderen, zoals com.bedrijfsnaam.projectnaam.module. Dit helpt conflicten te voorkomen bij het gebruik van libraries van derden en bevordert wereldwijde uniciteit.

Inconsistente Naamgeving

Het niet volgen van een consistente naamgevingsconventie voor packages, waardoor het moeilijk wordt om het doel van verschillende packages en de relaties ertussen te begrijpen. Bijvoorbeeld, het mengen van Engelse en niet-Engelse woorden of het gebruik van te algemene namen zoals com.myapp.data1, com.myapp.data2.

Toegangscontrole:

Het benutten van package-private toegangsniveau (default access modifier) om de toegankelijkheid van klassen en leden binnen hetzelfde package te beperken voor betere encapsulatie. Bijvoorbeeld, definieer een klasse DatabaseHelper in plaats van de klasse public DatabaseHelper in het package com.myapp.database die niet bedoeld is voor gebruik buiten dit package.

Overmatig Gebruik van Public Classes en Members:

Alles public maken zonder goede reden. Dit kan leiden tot een gebrek aan encapsulatie, waardoor de interne implementatie van je applicatie te toegankelijk wordt voor andere delen van de applicatie of externe gebruikers. Het kan ook de impact van wijzigingen in de toekomst vergroten, omdat meer delen van de code afhankelijk zijn van de interne implementatiedetails.

Default Package Gebruik

Het plaatsen van klassen in de default package (geen package declaratie). Dit beperkt de mogelijkheid om klassen te importeren in andere packages en vermindert de flexibiliteit bij het organiseren van code. Het belemmert ook het gebruik van toegangsbeperkingen die door packages worden geboden.