Before I start coding, I will outline my idea for the application:

1. the application will be written in Scala
2. it will be implementing the simplest poker flavor – the five-card draw with 24 cards
3. there will be 4 player limit for each game
4. it will have an HTML front-end
5. the Akka actors library will be used
6. the Play! framework will be used

The architecture design will be as follows:

The application will be divided into two tiers:

• Tier 1 – will be based on the PLAY! framework and will be responsible for rendering the UI
• Tier 2 – will be the actual game engine
• the communication between T1 and T2 will be handled by the Akka actors library

Before starting the development, we must set up the environment. To set up the environment, we need to:

1. download and install the Typesafe 2.0 stack
2. download and install the latest JDK6 and add the Java bin directory to the path
3. you may need also a Scala IDE, I’am personally using the Scala IDE for Eclipse

The development will start from the T1. To create a Play! Framework application one must:

1. open the console, cd to a suitable location and execute: g8 typesafehub/play-scala
2. you will be prompted to enter the application name after the sources download is finished, type „poker”
3. after the process is finished cd to the poker directory and type sbt

The SBT (Simple Build Tool) is a console tool that will help us to manage the project. To start the application, type run. The application will be started and it is accessible under localhost:9000. More options for the sbt play console are available under the help play command.

The real coding will start from pt.2, so stay tuned

Otóż, pewna stara programistyczna fama głosi, że gdy kod jest łatwo testowalny, to prawdopodobnie jego jakość, a przynajmniej architektura będzie wysokiej jakości. Automatycznie na myśl przychodzi takie proste rozwiązanie, że skoro kod ma być łatwo testowalny, to najlepiej by było zacząć jego tworzenie od napisania testów. Takie podejście nazywa się TDD (Test Driven Development). Pewnie wielu z Was słyszało o takim podejściu, natomiast jeżeli pracujecie w typowej firmie wytwarzającej „stronki”, to pewnie nie mieliście wielu okazji by zastosować takie podejście.

Oczywiście nie koniecznie jest to grzech – w prostych projektach zastosowanie TDD może być dyskusyjne ze względu na narzut czasowy jaki generuje. Znając jednak życie, prosty projekt zwykle przeradza się w projekt skomplikowany, którego skali nikt nie przewidział.

Abstrahując jednak od TDD, chciałbym się podzielić z Wami, moimi spostrzeżeniami na temat typowych „wzorców” w kodzie, które znacząco obniżają jego testowalność. Przy okazji zaproponuje sposoby ich rozwiązania poprzez refaktoring kodu oraz omówię konsekwencje jakie niosą za sobą poszczególne antypatterny.

Tak więc, jeżeli spotkasz jeden z podanych poniżej przypadków – wiedz, że coś się dzieje

1. Testując dany obiekt sprawdzam jego stan po wywołaniu danej metody:
2. Testując dany obiekt tworzymy mocki obiektów od których jest zależny w sposób łańcuchowy
3. Testując dany obiekt łapiemy się na tym, że testując metodę publiczną w istocie chcielibyśmy przetestować metody prywatne z których ona korzysta

Kilka przykładów kodu, żeby było wiadomo o co chodzi:

Przykład nr. 1:

class Bar(var i: Int) {

}

class TestSubject1 {
      
  def doFoo(bar: Bar){
    bar.i = 10
  }
  
}

def testCase1() {
    val bar = new Bar(0)
    
    val testedObject = new TestSubject1
    testedObject.doFoo(bar)
    
    if(bar.i == 10){
      println("true")
    } else {
      println("false")
    }
  }

Mamy zdefiniowane dwie klasy – Bar, która ma property „i” oraz klasę TestSubject1 która jest testowana przy użyciu funkcji testCase1. Co jest złego w tego rodzaju kodzie ? Przede wszystkim następuje niejawna manipulacja obiektem klasy Bar. Poza tym, jako, że metoda ma typ void (w tym przypadku w Scali jest to Unit), programista, który chce użyć takiego kodu, tak naprawdę nie wie jaki jest efekt jego działania. Kod po refaktoringu:

class TestCase1refactored {
  
  def doFoo(bar: Bar): Bar = {
    val result = new Bar(bar.i + 10)
    return result
  }
  
}

def testCase1refactored() {
    val bar = new Bar(0)
    
    val testedObject = new TestSubject1refactored()
    val result = testedObject.doFoo(bar)
    
    if(result.i == 10){
      println("true")
    } else {
      println("false")
    }
  } 

Jak widać, metoda po refaktoringu zwraca jakąś konkretną wartość, poza tym zamiast zmieniać stan obiektu, tworze nowy ze zmienioną wartością, dzięki czemu unikam modyfikowania globalnego stanu.

Przykład nr.2:

class Bar(var i: Int) {
  
}

class Baz(bar: Bar) {
  var barProperty = bar
}

class TestSubject2 {

  def doFoo(baz: Baz):Int ={
    val someUsefulValue = baz.barProperty.i
    return doRealyFoo(someUsefulValue)
  }
  
  private def doRealyFoo(input: Int):Int = {
    return input + 10
  }
  
}

def testCase2() {
    val bar = new Bar(10)
    val baz = new Baz(bar)
    val testedObject = new TestCase2
    
    val result = testedObject.doFoo(baz)
    
    if(result == 20){
      println("true")
    } else {
      println("false")
    }
  }

W kolejnym przykładzie, klasa TestSubject2 wyłuskuje wartość „i” poprzez zawołanie kilku (widziałem nawet kilkanaście) getterów w łańcuchu, nie muszę oczywiście mówić jak utrudnia to testowanie – należy po kolei zamockować i ustawić obiekty zwracane przez każdy z getterów, co może zająć wiele linii kodu, jest irytujące i bardzo wk****jące . Oczywiście taki kod jest jawnym pogwałceniem zasady enkapsulacji i ukrywania wewnętrznej implementacji. Na szczęście jest na to proste rozwiązanie:

class BazRefactored(bar: Bar) {
  def doRealyFoo(input: Int):Int = {
    return bar.i + input
  }
}

class BazRefactoredMock extends BazRefactored(new Bar(10)) {

}

class TestSubject2refactored {
  def doFoo(baz: BazRefactored):Int ={
    val result = baz.doRealyFoo(10)
    return result
  }
}

def testCase2refactored() {
    val baz = new BazRefactoredMock;
    val testedObject = new TestSubject2refactored
    
    val result = testedObject.doFoo(baz)
    
    if(result == 20){
      println("true")
    } else {
      println("false")
    }
  }

W powyższym kodzie przenieśliśmy metodę roboczą „doRealyFoo” do klasy na której tak naprawdę pracuje. Dzięki temu, z perspektywy klasy TestSubject2 nie interesują nas w ogóle „wnętrzności” klasy Baz, co zwalnia nas z łańcuchowego mockowania dziesiątek obiektów.

Czas na ostatni przypadek:

class TestSubject3 {

  val prop1 = 1;
  val prop2 = 2;
  
  def doFoo():Boolean = {
    val someText = doFoo1();
    val textToSend = doFoo2(someText);
    
    return callSomeWebService(textToSend);
  }
  
  protected def doFoo1(): String = {
    return "some complicated logic" + prop1
  }
  
  protected def doFoo2(input: String): String = {
    return input + " more very complicated logic " + prop2
  }
  
  protected def callSomeWebService(textToSend: String): Boolean = {
    return true;
  }
}

def testCase3(){
    val testSubject = new TestCase3
    
    if(testSubject.doFoo1() == "some complicated logic1"){
      if(testSubject.doFoo2("some complicated logic1") == "some complicated logic1 more very complicated logic 2"){
        if(testSubject.callSomeWebService("aaa") == true){
          println("true")
          return
        }
      }
    }
    println("false")
  }

Mamy to kilka ciekawych rzeczy – metodę publiczną, która zwraca nam true/false w zależności od wyniku interakcji z webservice’m, oraz kilka metod oznaczonych jako protected – przygotowujących dane do wysłania do webservice’u. Dlaczego w ogóle potrzebujemy testować metody „doFoo1″ oraz „doFoo2″ ? Wynika to z faktu, że są one tak naprawdę głównym koniem roboczym tej publicznej metody. Gdyby metoda „callSomeWebService” wywoływała zamockowany webservice, który zawsze zwraca true, to tak naprawdę  nie jesteśmy w stanie jej sensownie przetestować. Oczywiście możemy je przetestować tak jak jest to pokazane w powyższym przykładzie – poprzez ustawienie modyfikatora dostępu protected. Nie jest to jednak rozwiązanie eleganckie, głównie dlatego, że wymaga naszej wiedzy o szczegółach implementacji metody „doFoo”.

Można to jednak bardzo łatwo zmienić:

class TestSubject3refactored(doFoo1: DoFoo1, doFoo2: DoFoo2) {

  val prop1 = 1;
  val prop2 = 2;
  
  def doFoo():Boolean = {
    val someText = doFoo1.doFoo1(prop1)
    val textToSend = doFoo2.doFoo2(someText, prop2)
    
    return callSomeWebService(textToSend)
  }
  
  private def callSomeWebService(textToSend: String): Boolean = {
    return true;
  }
}

def testCase3refactored(){
    val doFoo1 = new DoFoo1;
    val doFoo2 = new DoFoo2;
    
    val testSubject = new TestSubject3refactored(doFoo1,doFoo2)
    if(testSubject.doFoo()){
      println("true")
    } else {
      println("false")
    }
    
  }

Ekstrahujemy obie metody do osobnych klas, dzięki czemu są one niezależnie testowalne. Co więcej, dzięki temu zabiegowi, w przyszłości będziemy mogli małym nakładem pracy podmienić implementację obu metod gdyby się to okazało potrzebne.

My interlocutors had a little different point of view – they stated, that although you should avoid them, there are some cases when G&S are a must. I came up with classic example of a Human, which we can image as:

public class Human {
    
    private Legs legs;
    private Heart heart;
    private Brain brain; 

    public Human(Heart heart, Brain brain, Legs legs){
        this.legs = legs;
        this.heart = heart;
        this.brain = brain;
    }
    
    public Distance walk(Place origin, Place destination) throws UnreachableDestinationException {
        heart.accelerateRate(150);
        Distance summaryDistance = new Distance(0, Unit.METER);        

        while(!origin.equals(destination)){
            if(!brain.canMoveByStep()){            
                throw new UnreachableDestinationException(destination);
            }
            Distance stepDistance = legs.moveStep();
            summaryDistance = summaryDistance.add(stepDistance);
            origin = origin.move(stepDistance);
        }
        return summaryDistance;
    }
    
    public void talk(Human interlocutor){
        //some code
    }
    
    public WorkResult work(Task task){
        //some code
    }
}

As we see in this code, you don’t have any getters or setters, all possible actions of a Human are expressed by the methods attached to its class.

So fine, so good, but what happens if we want to model the following situation – a Human walking down the street gets hit by a car and suffers from an injury ? If the injury is serious, he will be taken to the hospital. In the hospital he will be medically examined by some (let us hope) skilled medical personnel. If the injury was real worse, the situation may require to perform an operation on an open heart.

Unfortunately our properly encapsulated Human doesn’t expose its internal state of which the heart is part of. So, what can (and does) a surgeon ? He just simply breaks the encapsulation by cutting the chest and gets his job done.

If we wanted to translate (model) the actions of a surgeon in Java code, we would write:

public class Surgeon {

    private HashMap<String, MedicalProcedure> knownProcedures;
    
    public Boolean operate(Human patient, String procedureName) throws FamilyDoesNotAllowException {

        Field[] fields = Human.class.getDeclaredFields();
        try {
            List<Organ> organs = new ArrayList<Organ>();
            for (Field field : fields) {
                field.setAccessible(true);
                Organ organ = (Organ)field.get(patient);
                organs.add(organ);
            }
            MedicalProcedure procedure = knownProcedures.get(procedureName);
            return procedure.execute(organs);
            
        } catch (IllegalAccessException e) {
            throw new FamilyDoesNotAllowException();
        }
    }
}

In the above example, the Java Reflection API was used to break the encapsulation of the instance of a Human class. If we dive into the body of the method „operate”, we could see that an exception could be thrown – the IllegalAccessException. This is because the JVM could be configured to ban such usages of the reflection API. In the real world, the family could also disagree to operate the patient.

So much for drawing parallels between the real world and Java code. As we see, we cannot rely on this particular feature of Java Reflection API. If we want to save our innocent Human being, we have two options:

1. write getters and setters for the organs
2. add a new method to the Human class, to let him be operated

Let write some code to see, how could it be implemented. We will begin with the getter/setter case:

public class Human {
   
    private Heart heart;
    private Brain brain;
    private Legs legs;

    public Distance walk(Place origin, Place destination) throws UnreachableDestinationException {
        //some code
    }
    
    public void talk(Human interlocutor){
        //some code
    }
    
    public WorkResult work(Task task){
        //some code
    }
    
    public Heart getHeart() {
        return heart;
    }

    public void setHeart(Heart heart) {
        this.heart = heart;
    }

    //getters and setters for the rest of properties

}

public class Surgeon {

    private HashMap<String, MedicalProcedure> knownProcedures;

    public boolean operate(Human patient, String procedureName) {

        List<Organ> organs = new ArrayList<Organ>();
        organs.add(patient.getBrain());
        organs.add(patient.getHeart());
        
        MedicalProcedure procedure = knownProcedures.get(procedureName);
        Boolean isSuccessful = procedure.execute(organs);

        return isSuccessful;
    }
}

The code from the original example was altered and some getters/setters were added. The added G&S are actually some kind of extension points.

The positive of this approach is that anyone is free to do anything with our code, so when another scenario emerges – for example our Human gets started in an Olympics game, we could support this scenario without the need of altering the class itself.

The negative side of this approach is directly connected with the positive side – if someone is free to do anything with our code, than he could do something that he isn’t supposed to. An example of such situation would be the code, which sets the heart property to null – all other code depending of this property will simply fail.

After examining the G&S case, lets focus on the the second one. The code:

public class Surgeon {
    private HashMap<String, MedicalProcedure> knownProcedures;
    
    Boolean operate(Organ[] organs, String procedureName){
        MedicalProcedure procedure = knownProcedures.get(procedureName);        
        Boolean result = procedure.execute(organs);
        
        return result;    
    }
}

public class Treatment {
    
    private Surgeon surgeon;
    private String procedureName;
    
    Treatment(Surgeon surgeon, String procedureName){
        this.surgeon = surgeon;
        this.procedureName = procedureName;
    }
    
    Boolean execute(Organ[] organs){
        return surgeon.operate(organs, procedureName);
    }    
}

public class Surgeon {
    private HashMap<String, MedicalProcedure> knownProcedures;
    
    Boolean operate(Organ[] organs, String procedureName){
        MedicalProcedure procedure = knownProcedures.get(procedureName);        
        Boolean result = procedure.execute(organs);
        
        return result;    
    }
}

public class Human {
    
    private Legs legs;
    private Heart heart;
    private Brain brain;

    //some code
    
    public Boolean letBeOperated(Treatment treatment){
    
        Organ[] organs = {heart,brain};
        Boolean result = treatment.execute(organs);
        
        return result;
    }
}

In this approach we added another method named „letBeOperated” which is responsible for passing in a controlled manner some of the organs to an instance of a Treatment class which effectively performs the treatment of the patient.

We have avoided getters and setters, so our Human is once again perfectly encapsulated and nobody messes with the inner state of our object without our control.

We could think, that we have found a silver bullet, a technique which solves all of our problems. But one must be very cautious, because this one also has its drawbacks.

The first thing, you may notice is that, our Human class violates the Single Responsibility Principle – what has working and walking to do with being operated? The second thing is a consequence of the first one – if a class handles more than one responsibility it will have multiple dependencies and also it’s code base will grow very fast. How can we fix this obvious flaw?

If we closely look at the use cases that we try to implement, we may notice,  that the Human class appears in different contexts. One context is for walking down the street and the other is for being hospitalized. This is a very fundamental thing, that many developers seem simply to ignore, although it is very important for proper problem modeling.

Let us organize our problem domain knowledge:

• we have two contexts: Walking Context and Hospitalization Context
• in the Walking Context, a Human plays a role of a Walker and in the Hospitalization Context he plays a role of a Patient

How can we refactor our code then ? I see mainly two patterns applicable:

• Data Context Interaction (DCI)
• Bound Context (from DDD)

The Bound Context pattern refers mainly to general systems design, so I will just describe it without examples:

Applying the Bound Context pattern to an application means, that we divide the application into highly cohesive modules. Each module is a bound context – a set of classes, functions etc that are specialized over one „domain”. Because these software building blocks are very specialized, there may be a situation that we will have two classes sharing the same name in different bound contexts. These two classes will have different behavior that is custom to their bound context, neither will they be interchangeable, nor even share the same inheritance tree.

As I said, the Bound Context pattern is more a system design pattern and it mostly applies to some bigger systems. In most cases, the Data Context Interaction pattern should be sufficient.

So can we implement the DCI pattern using our Human-Walker-Patient example ?

We can do it in two ways, depending of what language we are using, lets start with the hard way – in Java

The code:

public class Human {

	protected Legs legs;
	protected Brain brain;
	protected Heart heart;

	public Human(Legs legs, Heart heart, Brain brain){
		this.legs = legs;
		this.heart = heart;
		this.brain = brain;
	}

	public Human(Human human){
		this(human.legs, human.heart, human.brain);
	}

}

public interface Walkable {
	public Distance walk(Place origin, Place destination) throws UnreachableDestinationException;
}

public interface Treatable {
	public Boolean letBeOperated(Treatment treatment);
}

public class Walker extends Human implements Walkable {

	public Walker(Human human) {
		super(human);
	}

	@Override
	public Distance walk(Place origin, Place destination)
			throws UnreachableDestinationException {
		heart.accelerateRate(150);
        Distance summaryDistance = new Distance(0, Unit.METER);

        while(!origin.equals(destination)){
            if(!brain.canMoveByStep()){
                throw new UnreachableDestinationException(destination);
            }
            Distance stepDistance = legs.moveStep();
            summaryDistance = summaryDistance.add(stepDistance);
            origin = origin.move(stepDistance);
        }
        return summaryDistance;
	}

}

public class Patient extends Human implements Treatable{

	public Patient(Human human) {
		super(human);
	}

	@Override
	public Boolean letBeOperated(Treatment treatment){

        Organ[] organs = {heart,brain};
        Boolean result = treatment.execute(organs);
        
        return result;
    }

}

How to use it:

public class Main {

	public static void main(String[] args) {
		Human human = new Human(new Legs(),new Heart(), new Brain());

		//let the human walk somewhere
		Walker walker = new Walker(human);
		walkFromHomeToWork(walker);

		//oops! there was an accident when walking		
		Patient patient = new Patient(human);
		treatAfterAccident(patient);

	}

	public static void walkFromHomeToWork(Walkable walker){
		walker.walk(new Place("Home"), new Place("Work"));
	}

	public static void treatAfterAccident(Treatable patient){
		Surgeon surgeon = new Surgeon();
		Treatment treatment = new Treatment(surgeon, "some medical procedure");
		patient.letBeOperated(treatment);
	}

}

Explanation:

We have created two interfaces – Walkable and Treatable, they represent the actions that we want an object to be capable of. Then we created two classes – Walker and Patient, that implement the mentioned interfaces. Both classes extend the base Human class to provide support for both interfaces.  The Walker and Patient classes are just simple wrappers but they share the same inheritance hierarchy to indicate, that they are specializations of a Human class (and also avoid the use of getters/setters ).

As I said before, the Java implementation is the hard way. Now let’s have some joy from programming, the next example will be in Scala.

The whole code:

class Human(
  protected[Human] val legsObj: Legs,
  protected[Human] val heartObj: Heart,
  protected[Human] val brainObj: Brain) {

  def this(human: Human) = {
    this(human.legsObj, human.heartObj, human.brainObj)
  }

}

trait Walkable extends Human {
  def walk(origin: Place, destination: Place): Distance = {
    heartObj.accelerateRate(150);
    
    var summaryDistance = new Distance(0, Meter);
    var currentPosition = origin;
    
    while (!origin.equals(destination)) {
      if (!brainObj.canMoveByStep) {
        throw new UnreachableDestinationException(destination);
      }
      val stepDistance = legsObj.moveStep;
      summaryDistance = summaryDistance.add(stepDistance);
      currentPosition = currentPosition.move(stepDistance);
    }
    
    return summaryDistance;
  }
}

trait Treatable extends Human {
  def letBeOperated(treatment: Treatment): Boolean = {
    val organs = Array(heartObj, brainObj);
    val result = treatment.execute(organs);

    return result;
  }
}

object Main extends App {

  implicit def humanInWalkingContext(human: Human) = (
    new Human(human) with Walkable)

  implicit def humanInMedicalContext(human: Human) = (
    new Human(human) with Treatable)

  override def main(args: Array[String]) = {
    val human = new Human(new Legs, new Heart, new Brain)
    human.walk(new Place, new Place)

    val surgeon = new Surgeon
    val treatment = new Treatment(surgeon, "some medical procedure")
    
    human.letBeOperated(treatment)
    
  }

} 

Explanation:

The Scala example has the same architecture as Java one, but the devil lies in the details . The first thing that you may notice is the absence of the Walker and Patient classes – they are not needed, because traits (Scala’s aproach to interfaces) already have an implementation of the needed methods.

The second thing that will surely confuse you (if you are not a Scala hacker ) is the main method. You may ask yourself – where have all the conversions go and how can you call methods on a class that doesn’t physically have them ?

The answer is very simple – we are using a very clever technique called views. Thanks to these two tiny bits of code above (starting with implicit def) we tell the compiler to implicitly mixin both traits into our sample Human class.

1. UI widgets / DOM manipulation frameworks
2. class based type system frameworks

In this post I would like to focus on the latter. Every time is see a new framework of this type popping on the news I tend to ask myself the same question – why ? Why one does write all does frameworks, why people so much need classes in Javascript ?

After some thinking I’ve got to a conclusion, that people need them mainly because they are used to the concept of the „class” and to a typical type system like this found in Java, PHP or „name your favorite mainstream programming language here”. This is understandable, as naturally human beings are resistive to change.  Also, some people tend to „not get” what’s going on in the prototypical type system. We cannot also blame them here because it has  some quirks and well, no one teaches it in schools ( ;P ).

One may ask himself – do we have an other choices to write clean, readable and understandable code other than using JS frameworks ? I think the answer for this question would be affirmative.

But before we come up for a solution. We must think for a second and summarize what we are trying to achieve. I think that are needs wrap in:

1. new object instantiation
2. information hiding
3. code reuse
4. modularization

The thing that some one will miss would be inheritance. Should it be on the list ? I don’t think so. The reason for the lack of inheritance is simple – inheritance has two purposes:

1. vertical code reuse – the type lower in the hierarchy inherits behavior from the type higher in it
2. signature checking – in statically typed class based languages, polymorphism is achieved through inheritance

we could achieve code reuse by other means in Javascript and as JS has no type checking we don’t need inheritance at all.

For our „no framework JS framework” we will use mainly such features of JS as first class functions and JSON. So behold, some common patterns for our daily JS programming:

//persons module
persons = (function(){

    //private Person object constructor
    var Person = function(firstName, lastName, birthDate){    
        var foo = "bar";
    
        var name = function(){
            return firstName + " " + lastName;
        }
    
        var age = function(){
            var currentYear = (new Date()).getYear()
            var birthDayYear = birthDate.getYear()
            
            return currentYear - birthDayYear      
        }
    
        var saySomething = function(){
            return foo;
        }
        
        //the methods that will be public
        return {
            "name": name,
            "age": age,
            "saySomething": saySomething
        }
    }
    
    //private FitnessAddict object constructor
    var FitnessAddict = function(firstName, lastName, birthDate, weight, height){        
        var person = Person(firstName, lastName, birthDate);
        
        var bmi = function(){
            return weight / (height*height);
        }
        
        var isWeightNormal = function(){
            var currentBmi = bmi()
            if(currentBmi > 25){
                return false
            }
            if(currentBmi < 18.5){
                return false
            }
            return true
        }
        
        //we make isWeightNormal method public
        person.isWeightNormal = isWeightNormal;
        
        return person;   
    }

    //we make the fitnessAddict object constructor public
    return {
        "FitnessAddict": FitnessAddict
    }
})()

Usage of the example:

var fa = persons.FitnessAddict(
    "Bar",
    "Baz",
    new Date(1990,5,5),
    80,
    1.8)
    
fa.isWeightNormal() // true
fa.saySomething() // "bar"
fa.name() // "Bar Baz"    

The first example proves, that we can achieve all of our goals through simple Javascript, without the need for frameworks. The additional benefit is that, because all is private by default, we improve the „cleanliness” of our API.

Jeżeli bym miał podsumować jednym słowem tworzenie kodu w PHP, to tym słowem było by „var_dump”. Pisząc jakiś kod, jesteśmy przyzwyczajeni do tego, że możemy go w każdej chwili zmodyfikować a potem sprawdzić efekty jego działania przy pomocy przywołanej wcześniej metody. Oczywiście są osoby, które w tym celu używają debuggera, jednakże jak wszyscy wiemy, są problemy z jego integracją z różnorakimi IDE i generalnie „var_dump” wydaje się być dość uniwersalnym narzędziem.

Pisząc w Javie, var_dump jest pierwszym z naszych pehapowych przyzwyczajeń, które powinniśmy schować do szuflady. Po pierwsze dlatego, że nie ma odpowiednika takiej funkcji w Javie, a po drugie dlatego, że var_dump driven development nie ma tam żadnych sensownych racji bytu. Dzieje się tak ze względu na czas jaki zajmuje deployment kodu – każda zmiana, jaką wprowadzimy w kodzie Javowym wymaga rekompilacji zmienionych klas i restartu serwera, co może trwać dość długo (np. w moim projekcie taka operacja trwa mniej więcej około 5 minut). Powstały oczywiście pewne solucje by temu zaradzić, takie jak np. podmienianie klas w trakcie działania serwera (Hot Swap), jednakże nie działają one we wszystkich przypadkach (jak dodanie, bądź usunięcie metody jakieś klasy).

Jak więc sobie radzić w takich warunkach ? Po pierwsze, musimy się zaprzyjaźnić z debuggerem. Wkrótce stanie się on naszym najlepszym przyjacielem, na którym będziemy polegać w każdej sytuacji. Debugger jest standardowo wbudowany w każde Javowe IDE, więc nie będziemy mieli żadnych problemów w korzystaniu z niego. Możliwości debuggera są naprawdę potężne i zaczynają się od przechodzenia kodu krok po kroku i podglądania wartości zmiennych, aż po zmianę ich wartości w locie oraz „cofanie się wstecz” w wykonaniu kodu.

Debuggera oczywiście najczęściej będziemy używać przy okazji poprawiania błędów. Jak natomiast sprawa się ma przy tworzeniu nowego kodu ? Tutaj z pomocą przychodzi nam dobrze znana, również z świata PHP technika Test Driven Development. Stosując TDD w kombinacji z debuggerem możemy dość skutecznie i szybko rozwijać nasz kod. Przy czym generalnie obowiązuje zasada, by raczej napisać jak najwięcej kodu przed jego testowaniem – nawet kompilacja testu, mimo, że jest to bardzo mała ilość kodu w porównaniu do całej aplikacji, którą depoloyujemy na serwerze nie jest natychmiastowa i chwilkę trwa. Jeżeli w tej chwili wyobraziliście sobie, że kompilujecie test tylko po to, żeby okazało się, że z jakiś głupich powodów nie działa, to mam dla Was dobrą informacje – dzięki statycznej naturze Javy, wszystkie „głupie” błędy zwykle podkreśli Wam na czerwono Wasz edytor, albo ostatecznie kompilator w momencie kompilacji.

Na koniec jeszcze taka mała uwaga odnośnie plików Javascriptowych. Zwykle bywa tak, że pliki źródłowe JS są częścią naszego Javowego projektu, w konsekwencji one również deployowane są na serwer wraz ze skompilowanymi klasamy Javy. W rezultacie, każda zmiana plików JS wymaga ponownego deployu projektu oraz restartu serwera co jak już wiemy – trwa dość długo. Na szczęście jak zwykle są na to sposoby . Po pierwsze, jeżeli tylko chcemy zmienić coś w JS do celów testowych, to wieść gminna niesie, że narzędzia deweloperskie Chrome’a  pozwalają zmieniać Javascript „w locie”. Po drugie, w przypadku InteliJ Idea, istnieje opcja „update resources”, która podmienia tylko obrazki, js i inne tego typu pliki dość szybko, bez potrzeby restartu serwera.

Tym radosnym akcentem kończę ten artykuł i ogłaszam, że jest to już ostatni wpis z serii „Kierunek Babilon”, oczywiście dalej zamierzam pisać o PHP i Javie, ale już w trochę innym kontekście.

Na pierwszy rzut oka Dart wygląda na kolejny klon Javy / C# z większym podobieństwem do C#. Jak każdy w miarę nowoczesny język posiada funkcje anonimowe i domknięcia. Jest oparty na klasach więc większość osób łatwo się w nim odnajdzie. Jest to główna i fundamentalna różnica pomiędzy Dartem a Javascriptem, oprócz oczywiście składni. Poza tą różnicą Dart wspiera DSL (domain specific languages), dzięki temu, że podobnie jak w Scali, operatory są tak naprawdę zwykłymi metodami, czyli mamy możliwość wywoływania metod bez użycia kropki. Dart wspiera też opcjonalne typowanie – możemy zadeklarować typ zmiennej i będzie on sprawdzony w czasie kompilacji.

Jeżeli porównamy Darta do PHP, to oprócz wcześniej wymienionych ficzerów jedyną w zasadzie różnicą będzie obsługa funkcji akcesorowych znanych z C# (metod prefiksowanych przez get/set).

Dart posiada jeszcze kilka mniej znaczących smaczków, które są głównie lukrem składniowym i mogą być z łatwością odtworzone przy użyciu innych konstrukcji językowych. Pierwszym z takich smaczków są nazwane konstruktory – czyli googlowy sposób na przeciążanie konstruktora w języku dynamicznie typowanym nieobsługującym przeciążania metod. Drugi sposób to metody fabryczne, czyli metody klasy poprzedzone słowem kluczowym „factory”, ich zastosowanie jest dla mnie generalnie mało zrozumiałe. Ostatnim „ficzerem” jaki zauważyłem są „krótkie konstruktory”, które oszczędzają nam trochę pisania – zamiast:

class Point {
    num x, y;
    Point(num x, num y) {
        this.x = x;
        this.y = y;
    }
}

można napisać tak:

class Point {
   num x, y;
   Point(this.x, this.y);
}

Podsumowując – szału nie ma. Co jak co, ale po Google spodziewałem się więcej. Czego mi brakuje ?

1. Większego nacisku na programowanie funkcyjne – np. łatwego sposóbu na tworzenie immutable data types, chociażby a’la Scala:

    case class User(firstName: String, lastName: String, birthday: Date) 

2. Anonimowe klasy
3. Wsparcie dla przetwarzania równoległego / wielowątkowego – jest w postaci aktorów (podziękowania dla wookieba)
4. Przestrzeni nazw / modułów
5. „Odwróconych” interfejsów a’la GO, czyli coś w rodzaju:

   class Test {
       Integer foo(){
           return 1;
       }
   }
   
   interface Foo {
        Integer foo();
   }
   
   Foo someFoo = new Test(); /* ok! - nie ma błędu -
   klasa Test nie deklaruje, że implementuje interfejs Foo,
   ale sygnatura jej metod jest zgodna z nim */
   

   Więcej na stronie 8tlight

Jestem ciekaw jaka jest Wasza opinia ?

Poprzedni tytuł „La Galere / Propaganda Kapitana Pazura”, już jakiś czas przestał pasować do treści strony, z prostej przyczyny jaką było przeniesienie prywatnych przemyśleń na mój drugi site. Ten blog stał się stricte zawodowo – programistyczny, postanowiłem więc ujednolicić tytuł z podpisem na goldenline – „programista eksplorator”. Dzięki takiemu ujednoliceniu chce podkreślić takie cechy mojej osoby, jak kreatywność, skłonność do patrzenia na problemy z różnych perspektyw oraz szeroki zakres wiedzy zawodowej jaki mam nadzieje posiadam ( ;p ).

Mam nadzieje, że będziecie tak często (albo nawet częściej) odwiedzać moją stronę jak dotąd .

public class Produkt {
    private Integer cena = 0;
    private Integer ilosc = 0;
    private String nazwa = "";

   public Produkty(Integer cena, Integer ilosc, String nazwa);

    /** tu gettery i settery dla wszystkich parametrow parametrow **/

}

public class Koszyk {

    private List<Produkt> produkty;

    public List<Produkty> getProdukty();
    public void setProdukty(List<Produkty> produkty);

}

public class KoszykUtil {

    public static Integer podliczKoszyk(Koszyk koszyk){
        List<Produkty> produkty = koszyk.getProdukty();
        Integer suma = 0;        

        for(Produkt produkt: produkty){
            suma+= produkt.getCena() * produkt.getIlosc();
        }
        return suma;
    }
}

Produkt p1 = new Produkt(12, 1, "baton z ropą");
Produkt p2 = new Produkt(13, 1, "baton z benzyną");
List<Produkty> produkty = new ArrayList<Produkty>();
produkty.add(p1);
produkty.add(p2);

Koszyk k = new Koszyk();
k.setProdukty(produkty);

Integer suma = KoszykUtil.podliczKoszyk(k);
System.out.println(suma);

Obiektowo:

public class Produkt {

    private final String nazwa;
    private final Integer cena;
    private Integer ilosc;

    public Produkt(String nazwa, Integer cena, Integer ilosc);
    public Integer suma(){
        return cena*ilosc;
   }

}

public class Koszyk {

    private List<Produkt> produkty;
    private Integer wartosc = 0;    

    public dodajProdukt(Produkt produkt){
        produkty.add(produkt);
        wartosc += produkt.suma();
    }

    public Integer wartosc(){
        return wartosc;
    }
}

Koszyk k1 = new Koszyk();
Produkt p1 = new Produkt("baton z benzyna" , 10, 1);
Produkt p2 = new Produkt("baton z ropą", 10, 1);
k1.dodajProdukt(p1);
k1.dodajProdukt(p2);

Integer suma = k1.wartosc();
System.out.println(suma);

Funkcyjne:

public interface Sumator<D> {

     public Integer sumuj(Integer suma, D element);
}

public class ListUtil {

    public static <T> Integer sumuj(Sumator s, List<T> dane) {
        Integer suma = 0;
        for (T element : dane) {
            suma = s.sumuj(suma, element);
        }
        return suma;

    }
}

public final class Produkt {
    public final Integer cena;
    public final String nazwa;

    public Produkt(String nazwa, Integer cena){
        this.nazwa = nazwa;
        this.cena = cena;
    }
}

Produkt p1 = new Produkt("baton z ropą", 10);
Produkt p2 = new Produkt("baton z benzyna", 10);

List<Produkt> produkty = new ArrayList<Produkt>();
produkty.add(p1);
produkty.add(p2);

produkty = java.util.Collections.unmodifiableList(produkty);
Integer suma = ListUtil.sumuj(new Sumator<Produkt>() {

            @Override
            public Integer sumuj(Integer suma, Produkt element) {
                return suma + element.cena;
            }
        }, produkty);

System.out.println(suma);

Czego można dowiedzieć się z tych prostych przykładów ? Otóż można zauważyć w każdym z nich cechy charakterystyczne danego stylu programowania i tego na co kładzie nacisk.

1. Proceduralny – stawia na swobodny przepływ danych.
2. Obiektowy – abstrakcja, enkapsulacja, odwzorowanie modelu domeny
3. Funkcyjny – niezmienność (immutability), generyczność i funkcja jako pełnoprawny element języka (tutaj emulowana przez anonimową klasę)

Mam nadzieje, że powyższe przykłady były pouczające.Jestem bardzo ciekawy, które z powyższych rozwiązań przypadło Wam do gustu i dlaczego, oraz jaki styl preferujecie.

Dla przypomnienia, powody, dla których postanowiłem zmienić środowisko z PHP na Javę:

1. Rodzaj projektów – miałem dość projektów typu „strona – wizytówka”, portali, cms-ów etc
2. Organizacja pracy – brak sformalizowanego procesu wytwarzania oprogramowania, brak specyfikacji, metodologii etc
3. Zarobki

Czy wobec perspektywy tych trzech powodów, zmiana miała sens ? Jak najbardziej ! Po półtora tygodnia pracy mogę powiedzieć że:

1. Uczestniczę w projekcie a raczej w rozwoju produktu ze skomplikowaną logiką biznesową
2. Proces wytwarzania kodu jest ściśle sformalizowany
3. Oprócz zdecydowanej podwyżki, w stosunku do „PHP-owego okresu mojej kariery”, mam do dyspozycji wiele bonusów (tzw. socjału oraz szkoleń)

Największą różnicą między tym co dotychczas robiłem a tym co teraz robię jest przede wszystkim rozmach. Realizując projekty PHP-owe dotychczas pracowałem zwykle sam, lub maksymalnie w około 5-cio osobowym zespole, który pracował zwykle w jednym pokoju biurko w biurko.

W obecnej pracy, jestem członkiem działu (nie mylić z oddziałem), który tylko w Polsce liczy ponad 100 osób (w firmie, która tylko w Polsce zatrudnia około 1200 osób), jestem członkiem jednego z 4ech zespołów pracujących nad jednym produktem i bezpośrednio współpracuje z około 20-toma osobami. To dość duża zmiana mentalna.

Jeszcze większą mentalną zmianą jest to, że często się zdarza, że nad jednym „user story” (odpowiednik pojedynczego „ficzera”) pracuje nierzadko z kilkoma osobami. Zmienia to zupełnie sposób pracy i wymaga ciągłej komunikacji, zrozumienia i trzymania się ściśle ustalonych standardów.

Kolejnym faktem, który wiele zmienia, są Unit Testy. Pierwszy raz, rozwijam aplikację, której część biznesowa jest prawie w całości pokryta testami jednostkowymi (bo w przypadku frameworków to jest norma).

Generalnie wiele rzeczy prowadzonych jest „książkowo”, jak np. praca w metodyce Scrum. Codzienne „standupy”, iteracje i ich planowanie – uczestniczę w nich i widzę, że ma to sens.

Wracając do rzeczy czysto programistycznych mogę powiedzieć tyle, że łyknąłem już dość dużo Javy, przede wszystkim wszelakich adnotacji i typów generycznych, sposobu obchodzenia się z projektami – Maven, integracja z IDE, debbugger, Tomcat oraz frameworki JUnit oraz Mockito.

Cały czas tutaj wymieniam plusy i zalety, natomiast nie wspomniałem o kilku rzeczach, które można by nazwać wadami tej roboty. Pierwsze co od razu rzuciło mi się w oczy to dość duża biurokracja – na wstępie musiałem wypełnić 11-stronnicowy formularz. Druga kwestia to niestety nieproporcjonalność wyposażenia mojego laptopa do ogromu projektu (poranny update potrafi trwać nawet 15 minut !) – niestety nawet 4gb ramu i najnowszy Core i5 nie zapewniają w jego przypadku komfortowej pracy.

Tak więc pokrótce wyglądają moje wrażenia z pierwszego tygodnia pracy. Jeżeli ktoś chciałby również spróbować pracy w „corpo” z Javą, dajcie znać, chętnie Was polecę

Zastosowań jest całe multum, natomiast chyba najbardziej przydatna jest ta funkcja dla twórców wszelakiej maści frameworków i bibliotek (szczególnie ORM). Dzięki niej, nie trzeba już będzie korzystać ze sztuczek z serialize/deserialize, by stworzyć obiekt z pominięciem konstruktora.