Prezentācijas mērķis - vispārīgā līmenī iepazīties ar dažām objektorientācijas kategorijām, it īpaši pievēršoties Javas OO programmēšanas vadlīnijām, kuras būtiskas Web aplikāciju izstrādē.
Šo piezīmju rakstīšanas brīdī Javas pēdējā versija ir JDK 1.6 (sk. JDK6 Update 2 Abās jaunākajās versijās (1.5 un 1.6) ir virkne jaunu jēdzienu - anotācijas, parametrizētie tipi (generic types), uzskaitījuma tipi (enum types).
Valodas Java (Sun Microsystems) un C# (Microsoft .NET) savas attīstības gaitā savstarpēji ietekmējas.
Javas klases deklarācijas piemērs:
package lv.mycompany.myproject.model;
import java.util.Date;
// more imports
public class User {
// atributes
private Integer id;
protected String name;
protected Date birthdate;
// constructor
public User(String name, Date birthdate) {
this.name = name;
this.age = age;
}
// methods
public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Date getBirthdate() {
return birthdate;
}
public void setBirthdate(Date birthdate) {
this.birthdate = birthdate;
}
}
package some.packagename;
<modifiers> class <class_name> {
// class body
}
Klases definīcijas priekšā var rakstīt dažādus modificētājus - "public", "final", u.c. To nozīmes precīzi paskaidrosim vēlāk. Vienkāršākajos gadījumos var visas klases deklarēt kā "public class class_name".
Iekapsulētu kodu var pazīt pēc mērķtiecīgas Javas piekļuves modifikatoru (piemēram, public/private) lietošanas. Parasti visi klases atribūti ir deklarēti kā private vai protected (t.i. ja vēlamies, lai tie būtu pieejami arī mantotajās klasēs). Savukārt daļa metožu parasti ir publiskas.
Metodes, kuras domātas, lai varētu nolasīt vai uzstādīt atribūtu vērtības pakļaujas sekojošai nosaukuma konvencijai (naming convention) - ja atribūta nosaukums ir "xxx" (tas sākas ar mazo burtu - sk. Javas programmu stils), tad metodi šī atribūta nolasīšanai sauks "getXxx()" un metodi tā vērtības uzstādīšanai - attiecīgi "setXxx()".
Sk. iekapsulēšanas piemēru - lietotāja definēta datumu klase.
Projektēšanas paraugi (design patterns) ir risinājumi, kurus lieto dažādās tipiskās situācijās.
/**
* Invariant: degrees value should always
* be equal or more than -273.15
*/
public class RoomTemperature {
public float degrees;
}
public class RoomTemperatureClient {
public invalidValue() {
RoomTemperature tr = new RoomTemperature();
tr.degrees = -300.0F;
}
}
Arī tad, ja RoomTemperature klienti šo klasi lieto pareizi un piešķir pareizas vērtības, var rasties grūtības, ja implementācijā ir jāsāk lietot Kelvina, nevis Celsija grādi. Jo tad visas klientu piešķirtās vērtības kļūst nepareizas.
/**
* Invariant: degrees value should always
* be equal or more than -273.15F
*/
public class RoomTemperature {
private float degrees;
public void setDegrees(float degrees) {
if (degrees < -273.15F) {
throw new IllegalArgumentException(
"Temperatures below -273.15F not allowed");
}
this.degrees = degrees;
}
public float getDegrees() {
return degrees;
}
}
public class RoomTemperatureClient {
public invalidValue() {
RoomTemperature tr = new RoomTemperature();
tr.degrees = -300.0F;
}
}
Katrai klasei var definēt objekta iekšējo stāvokļu (atribūtu vērtību) pieļaujamās vērtības, t.i. reprezentācijas invariantu. Katra klases metode garantē, ka reprezentācijas invariants pēc attiecīgās metodes izsaukuma saglabāsies, pieņemot, ka šis invariants bija spēkā arī pirms metodes izsaukuma.
Reprezentācijas invariants parasti parādās tur, kur pareizi izmanto iekapsulēšanu. Ja nav reprezentācijas invariantu, tad klases iekšējo stāvokli neviens sabojāt nevar un iekapsulēšana (teiksim, privāti atribūti) šai klasei nav nepieciešami vai arī tie kalpo tikai tam, lai varētu mainīt implementāciju un aizstāt šos atribūtus ar citiem.
public void setBirthdate(Date birthdate) {
Date current = new Date();
if (current.getTime() < birthdate.getTime()) {
throw new IllegalArgumentException("Future dates not allowed");
}
else {
this.birthdate = birthdate;
}
}
Kodu nedrīkst kopēt vairākās vietās ("Don't repeat yourself", "Write it once and only once"). Šo principu nav vienkārši ievērot objektorientētās programmās, kurās ir ierobežota piekļuve atribūtiem. Lai izvairītos no koda atkārtošanās, ir ir izmantojama klašu mantošana, kopīgo koda fragmentu iznešana atsevišķās statiskās metodēs un citi paņēmieni.
Vispārīgi principi, lai uzlabotu koda struktūru, nemainot tā uzvedību tiek saukti refaktorizācija. Sk. Refaktorizācija.