Inheritance is evil, and must be destroyed

Good article about inheritance  - http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/.
Mix-in and Strategy are great replacements for it.

BDD Beautiful development

In next couple of weeks I'm going to try BDD for java project - http://easyb.org/.
This tool looks promising compared to existing in-house solutions.

How to write javadoc tips

Worst documentation for code is one that repeats code. Some companies want to avoid this pitfall by implementing "no javadoc" rule (I'm talking about java). This is wrong.
Using following tips (hopefully) will help you to produce meaningful documentation for code:

•  Use questions in templates for documentation. It's more mind stimulating to answer "What does this class do ?" than replace template "Write description of the class"
• Write CRC in documentation. CRC means class-responsibility-collaborator data. Example:
• class: What is it ?
• responsibility: What and when does it work, what valuable does it do ?
• collaborator: What classes/modules uses this class ? What classes/modules is used by it ?
• Example of use. Basic usage scenario in javadoc is most useful thing. It's got noticed on first place (almost every class in JDK has one).
• Design By Contract: For both class and method it's important to know:
• Precondition: 
• When it's legal to use class/method?
•  What is a valid types and boundary conditions for arguments? Null, string format, data range
• What is true about method/class execution (thread safe, can produce exception, require external resources, linked with other methods/classes)
• What is possible outcome ? (Empty array, value object)

Last, a bit vague advice -  do not repeat class/method name. Describe code in business terms, using different words than in code. If you can-not do it or method is pretty obvious - don't write it.

Translator pattern

One common task in banking is translating from one form to another. I couldn't find an effectife solution for this problem, but TranslatorPattern offers interesting approach.
I've used similar functionality in Amoeba utility classes:

 private static interface Amoeba<Value> {

  boolean consume(Amoeba<Value> amoeba);

  Value produce() throws Exception;
 }

 private static class AmoebaUtils {

  static <Value> boolean populate(Collection<Amoeba<Value>> colony, Amoeba<Value> nominate) {
   for (Amoeba<Value> citizen : colony) {
    if (citizen.equals(nominate)) {
     return citizen.consume(nominate);
    }
   }
   return colony.add(nominate);
  }

  static <Value> Collection<Value> produce(Set<Amoeba<Value>> colony) throws Exception {
   Set<Value> values = new HashSet<Value>();
   for (Amoeba<Value> citizen : colony) {
    values.add(citizen.produce());
   }

   return values;
  }
 }



This gives ability to absorb source notes by related destination nodes, providing natural grouping and translating of information. This is kind of builder and translator, with non-linear rules of transformation (source node != dest node).

List of Lists

Task: to order input data according 2 integer keys.
Example: we have bunch of options. Options have indexes and legs. Legs have indexes and other useful information.
Question: how to extract one type of information from legs?
Answer:
...
private final List<List<FinDate>> expiryDateByOptionAndLeg;
expiryDateByOptionAndLeg = new ArrayList<List<FinDate>>(size){
...
@Override
public List<FinDate> get(int index) { 
 List<FinDate> rez = null;
  rez = super.get(index);
  if(rez == null) {
   rez = new ArrayList<FinDate>(2);
   add(index, rez);
  }
  return rez;
}
};
...
  expiryDateByOptionAndLeg.get(optionsIndex).set(legIndex, expiryDate);



Answer: To use approach suggested in ThreadLocal class javadocs. In this way we receive clear 2-indeger index without need to create list in business code. Similar approach could be applied to Maps.
It's simpler than creating  separate business object and still readable and expressive.

Api Design: Key vs Session

During discussion of our new API an question come up, why session is better than a simple key.
Session concept is to have per connection object with details on customer, it's preferences, etc.
Key concept is to have passive key and number of services that uses it.
I came up with following:

Session	Key
Holds request specific data	Need to hold request specific data in api objects
More agile approach, you can make you session active, have one master instance for actions or session-specific actors	Managing class and a collection of keys are needed for two way communication
Visible list of services available	You should knew about service existence before use it
It's complex to fake system	It's easy to confuse keys

It's subject to update. Please place you thoughts about it.

Legacy system development

If you're like me, then you probably faced developing new features for legacy systems (system with no test coverage) without full understanding of source. I've done this a couple times, and want to share lessons learnt:

Legacy documentation

There are 3 sources of information about system - experienced colleagues, documentation(if exists, including javadocs and tests) and source. Fact is, you should not trust first two and use them only to understand third.
Colleagues may forget smth or think of it as of obvious thing. Tests, if they exists may be incorrect or deprecated. If documentation isn't a part of delivery, noone bothers keeping it up-to-date.

Development surroundings

Most likely new development will introduce bugs. Mine does. But not in feature you're working on. It will be some other functionality, linked with yours.
So, you need to recheck code you're depending on and recheck code, that depends on your new logic.

Also requirements is important - if you haven't understand them, you will not deliver valuable feature.

Summary

• Use all information you can get, but dont rely on it
• Only reliable source of information - code
• Check and recheck code you're depending on and code that depends on your's code
• Understand your requirements