Ukryta implementacja

Ukryta implementacja
Witold Grzelczak
[email protected]
Ale o co chodzi…?
Ukryta implementacja?
Opowiedziałbym coś o tym, ale
muszę odebrać zapasową pelerynę z
pralni.
Nu pagadi Zorro!
Tu sierżant Garcia
mówi.
Ale o co chodzi…???



Ukrywanie implementacji to ogólnie rozumiana kontrola
dostępu. Określa dokładnie co użytkownik klasy może w niej
zmieniać, a czego nie.
Dziś zajmiemy się wyjaśnieniem kilku podstawowych pojęć.
Dowiemy się o konwencji nazewnictwa plików w Javie. Poznamy
modyfikatory dostępu oraz inne, fascynujące rzeczami, które
każdy szanujący się student EZI wiedzieć powinien :-)
Poznamy ładne pojęcie hermetyzacji.
Ready to go?! Go!
Kto lubi LEGO?
WSZYSCY!!!

Niewątpliwą zaletą JAVY jest możliwość korzystania z gotowych
„klocków”, czyli bibliotek komponentów. Są one umieszczane
w pakietach. Zawierają w sobie gotowe klasy, dzięki czemu nie
musimy pisać wszystkiego od podstaw. Wystarczy znaleźć
odpowiednią bibliotekę i wykorzystać jej komponenty.

Używając polecenia import, możemy używać klas znajdujących się
w bibliotekach, tak jakby ich deklaracje znajdowały się w naszym
kodzie programu.
Jak się bawić LEGO?

Do biblioteki, lub do jej części, możemy odwołać się na dwa sposoby:

Poprzez użycie słowa import
folder biblioteka
wszystkie klasy
import java.util.*;

Funkcja ta powoduje wprowadzenie do programu całej biblioteki.
Możemy teraz odwoływać się bezpośrednio do klasy ArrayList (która jest
częścią tej biblioteki)
Bądź poprzez podanie ścieżki dostępu:
(import) java.util.arraylist
W tym przypadku wykorzystujemy zarządzanie plikami OS-u. Kropki są
zamienianie na „/” lub „\”. Dodatkowo folder java musi się z znajdować
w folderze zadeklarowanym w zmiennej CLASSPATH
Chińszczyzna na zimno czyli
„smaczki”
Gdy tworzymy plik z kodem źródłowym Javy, jest on
powszechnie nazywany jednostką kompilacji. Nazwa każdej
jednostki musi mieć rozszerzenie .java . Wewnątrz takiej
jednostki może znajdować się maksymalnie jedna klasa
publiczna o takie samej nazwie, jak jednostka kompilacji.
Dokładność trzeba zachować nawet co do wielkości liter, ale bez
rozszerzenia .java. Reszta klas jest ukryta przed świat(ł)em
zewnętrznym. Stanowią one klasy wspierające.
Vifon: I mam wszystko w … pakiecie

package to instrukcja umożliwiająca udostępnieni już
skompilowanych plików .class. Używa się jej podczas
pisania struktur, które chcemy wykorzystać w
przyszłości. Przy tworzeniu takiego pakietu, wymagane
jest, aby instrukcja package znajdowała się w pierwszej
linii kodu, nie będącej komentarzem, czyli:
//:com:bruceeckel:simple:List.java
// Tworzenie pakietu
package com.bruceeckel.simple;
public class List {
...
}
Wypadki chodzą po ludziach,
czyli kolizje.

Co się dzieje, gdy zaimportujemy dwie biblioteki
zawierające te same nazwy?
import pl.witoldgrzelczak.simple.*;
import java.util.*
Załóżmy, że w obu znajduje się klasa o nazwie Vector.
Powoduje to potencjalną kolizję. Kompilator zgłosi
błąd jedynie w wypadku, gdy stworzymy tę klasę:
Vector w = new Vector();
Add – remove - full custom

Dzięki wykorzystaniu opcji package oraz import
możemy sami tworzyć biblioteki. Mamy możliwość
stwarzać własne skróty do najczęściej wpisywanych
komend, bądź nawet pisania własnych pakietów, które
mogą zostać wykorzystane przez innych użytkowników.
P.rint(s)
zamiast
System.out.print(s)
Modyfikatory dostępu

Mamy trzy, a nawet cztery stopnie dostępu:
pakietowy
public
protected
private
Batman…?
W dzisiejszych czasach
nawet Batman musi się
znać na programowaniu…
Kiedy mam wolną chwilę
to stawiam pasjansa - bez
Jokerów.
Pakietowy

Jest to domyślny stopień dostępu i nie posiada swojego słowa kluczowego.
Klasy tego samego pakietu posiadają dostęp nawzajem do swoich
elementów, jednak dla klas poza pakietem wydaje się on prywatny.
Dzięki zastosowaniu dostępu pakietowego, wszystkie klasy wewnątrz tej
samej jednostki kompilacji (pliku) są automatycznie dostępne dla siebie.

Jedynymi sposobami przyznania dostępu do składnika są:
Uczynienie składnika publicznym (modyfikator public),
Zapewnienie dostępu do składnika w ramach pakietu,
Klasa pochodna ma dostęp do składników chronionych (protected) oraz
publicznych (public), nie ma natomiast dostępu do składników prywatnych
(private).
Użycie metod udostępniania get / set. (ale o tym później)
1.
2.
3.
4.
(boston) public
Słowo kluczowe public czyni deklarację następującą po nim
dostępną dla całego świata.
np.:
funkcja dostępna for-everyone
package biblioteka.ksiazka;

public class Cookie {
public Cookie() {
system.out.println("Konstruktor klasy Cookie");
}
void bite () {System.out.println("metoda bite");}
}
funkcja niedostępna jedynie dla klas pakietu
Private – do not disturb
Modyfikator private oznacza, że do danego
składnika klasy nie ma dostępu nikt poza jego
własną klasą. Inne klasy tego samego pakietu nie
mają dostępu do składowych prywatnych.
Może zostać użyty do zablokowania
bezpośredniego dostępu do konstruktora
(hermetyzacja).
Protected
Jeżeli tworzymy nowy pakiet i dziedziczymy po
klasie z innego pakietu, wtedy jedynymi
składowymi, do których mamy dostęp, są
składowe publiczne pakietu oryginalnego.
Jednakże czasem twórca klasy bazowej pragnie
udzielić dostępu do określonego składnika
klasom pochodnym, jednak nie chce go udzielać
wszystkim. Do tego służy modyfikator
protected.
Klasy, a modyfikatory
Tworząc nową klasę dostępną w obrębie pakietu, warto
zadbać o to, aby pola były jak najbardziej prywatne; jeśli
chodzi o metody, to warto stosować dostęp pakietowy
o ile nie koliduje to z ogólną koncepcją programu.
Cała klasa nie może być prywatna lub chroniona.
Wtedy byłaby niedostępna dla użytkownika. Jeżeli nie
chcemy, aby ktokolwiek miał dostęp do klasy, wtedy
możemy uczynić wszystkie konstruktory prywatnymi,
uniemożliwiając wszystkim, poza nami, dostęp do nich.
cdn. czyli Niekończąca się opowieść
cz. II
Trzeba pamiętać, że jeżeli nie stworzymy jawnie
chociaż jednego konstruktora, to zostanie
wyprodukowany konstruktor domyślny
(bezargumentowy). Dzięki napisaniu
konstruktora domyślnego zapobiegamy jego
automatycznemu utworzeniu.
To byłoby na tyle
„Koniec i bomba,
a kto czytał, ten trąba!”*
* Witold Gombrowicz „Ferdydurke”
Bibliografia



Eckel Bruce „Thinking in JAVA edycja polska,
wydanie 3”, wyd. Helion, Gliwice 2003
Kathy Sierra & Bart Bates „Head first JAVA”
wyd. Helion, Gliwice 2005,
Google