Glue classes proposal beta

OVERVIEW

Notice that it's beta specification: it's not described in full details, half validated (translation), and it's provided for you to pre-analyse. I still need some time to provide syntax which fully supports generics. Multi-glue classes are under consideration as well, but this may occur to be to complex to handle by any earth living programmer.

FEATURE SUMMARY:
Glue classes allow to link utils direct with objects.

MAJOR ADVANTAGE:
Forgotten functionality can be not such big deal now.

MAJOR BENEFIT(s):

• New functions can be easy localised (critically important while introduce new peoples into project).
• Security: glue class do not see anything protected.
• Light binding new functions with existing classes.
• Number of used classes reduction.
• Allow to assign methods and functions(static methods) to arrays, classes, interfaces, …
• It's proof against same method occurs in class and delegator as well like in two delegators.
• Allow to link gained(.jar) logic with new one, witch is impossible before final developer implements his classes.
• Allow to project compact interfaces and do not worry about additional logic.

MAJOR DISADVANTAGE:
Do not know any ;) sorry.

ALTERNATIVES:
Utils classes.

EXAMPLES

SIMPLE EXAMPLE:

public class base glue <? extends Date>
{

  private static final SimpleDateFormat  sdf  = new SimpleDateFormat("yyyy.MM.dd");

  public String format(This this) {
    synchronized (sdf) {
      return sdf.format(this);
    }
  }

  private static final Date applicationStart = new Date();

  public static Date applicationStart() {
    return applicationStart;
  }

}

• base: logic name, should start with lowercase because it's representing logic not class.
• glue <? extends Date>: logic will glue to all classes extending Date.
• .format(This this): method that will be 'visible' for declared objects.
• This: Object type representing this.getClass()
• this: equivalent with given bound (? extends Date).

Usage:

import java.util.Date;
import pl.some.utils.base; // imported to allow ..format() execution

public class Test {

  public static void test_0(Date date) {
    System.out.println(date..format()); //simple usage
  }

  public static void test_1(Date date) {
    System.out.println(date..base.format()); //used when we have more logics with same methods
  }

  public static void test_2(Date date) {
    System.out.println(date..pl.some.utils.base.format()); // full declaration
  }
  public static void test_3() {
    System.out.println(Date..applicationStart()..format()); // mixed case
  }

}

ADVANCED EXAMPLE:
Will come...

DETAILS

SPECIFICATION:
JLS 8.8: http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.8 ClassDeclaration:
  NormalClassDeclaration
  GlueClassDeclaration
  EnumDeclaration

GlueClassDeclaration
  ClassModifiers_opt class Identifier glue<ActualTypeArgument> GlueClassBody

ActualTypeArgument
  (JLS 4.5.1) represent objects for witch glue works: <? extends Date>, <Date>, <Object[][]>, ...

COMPILATION:
Everything we need is already in JDK, we just need little trick to bind static method in compilation time with existing classes.

TESTING:
Like simple static methods.

LIBRARY SUPPORT:
No.

REFLECTIVE APIS:
No.

OTHER CHANGES:
No.

MIGRATION:
None.

COMPATIBILITY

New jars are fully compatible. Code is only backward compatible.

REFERENCES

Glue classes proposal beta: http://lasu2string.blogspot.com/2009/03/glue-classes-proposal.html

Krucjata przeciwko dziedziczeniu. Wyprawa 2.

Instrukcje

Zapewne nie raz zdarzyło się wam pisać metody do już istniejących klas. Jeśli klasa nie pochodziła z 'zewnętrznych' bibliotek to pół biedy, co się dzieje jeśli jednak pochodzi?

• Dziedziczymy? Ależ oczywiście, że tak.
• Metody statyczne? I to porozrzucane po całym projekcie.
• Lub po prostu więcej kodu.

Efekty nie są przyjemne. Zwiększenie komplikacji samego kodu, jego logiki, oraz struktury klas. Nie raz zdarza się, że nowy pracownik pisze rzeczy już napisane ponieważ nie potrafi ich zlokalizować.

Rozważmy klasy które zamiast gromadząc statyczne metody doklejała by je do już istniejącej klasy.

Wyobraźmy sobie sytuacje gdy przy obiekcie Date po postawieniu kropki obok standardowych metod wyświetlają się nam:

..sformatujDoBazyDanych() : String

..sformatujDoWyświetlenia() : String

Sytuacja staje się na tyle jasna, że nawet nowo przybyły pracownik wie co ma robić. Ile czasu oszczędziło by to już paracującym? Oraz ograniczyło ilość używanych klas w kodzie.

Ciekawym rozwiązaniem może być także doklejanie metod do interfejsów.

Przykładowe schematy obrazujące przyklejone klasy.

Klasa z metodami statycznymi

Zwykła klasa

Klasy przyklejone	Klasyczne metody podejścia
Klasa + klasa przyklejona.	Klasa + klasa pomocnicza z metodami statycznymi.
Klasa + dwie klasy przyklejone.	Klasa + klasa pomocnicza z metodami statycznymi + dziedziczenie.
Klasa + cztery klasy przyklejone.	Klasa + dwie klasy pomocnicze z metodami statycznymi + dziedziczenie.

Przegląd

Główne zalety / korzyści:

• Szybka lokalizacja nowych funkcjonalności.
• 'Lekkie' wiązania nowych funkcji z istniejącymi klasami.
• Znaczna redukcja ilości używanych klas.
• Umożliwia podpięcie statycznych metod pod interfejsy.
• Umożliwia 'bezpieczne' rozszerzenie klas finalnych.
• Umożliwia tworzenie zwięzłych klas(nie trzeba od razu pamiętać o wszystkich funkcjach).

Najistotniejsze wady:

• Określenie sposobu selektywnego wyłączania przyklejonych klas.

Inne rozwiązania:

• Modlitwa ;) .
• Nie zatrudniać nowych ludzi.

Podsumowanie:

Przykłady:

… glue class DisplayDate extends Date{

  private static final SimpleDateFormat sdf
    =new SimpleDateFormat("yyyy.MM.dd");

  public glue String format(){
  synchronized (sdf) {
    f.format(this);
    }
  }

}

Wywołanie:

   ...(){
   Date cur = new Date();
   return cur..format();
   }


   ...(){
   Date cur = new Date();
   return cur..DisplayDate.format();
   }


Detale rozwiązania:

this reprezentuje klasę + interfejsy warunkujące doklejanie.

Do rozważenia są także metody potrafiące się doklejać do więcej niż jednej klasy...

Dodatkowo nie należy zapominać, że metody statyczne też powinny mieć możliwość warunkowego doklejania.

Metody doklejane nie powinny mieć dostępu do prywatnych pól i metod.

Kompatybilność:

Wsteczna:
Pełna.

W przód:
Brak.