A life committed to learning.

Category: Software

Continue Reading

Hey, did you know Java is a typed language…?

Hi,

Java is a typed language (Duuhh!!!), it means that we can create new types like:

public class User {
    private final string name;

     public User(String aName) {
         this.name = aName;
     }
}

And we can later on bring Users live into our virtual world, that is our app. If our app deal with objects and their interactions, we should care that those objects are of a given type, that’s why we define our app’s blueprint (java code, for that matter).

If my app has two users, somewhere in my code I’ll find something similar to this:

User userJon = new User("Jon");
...
User userDoe = new User("Doe");

I’m bringing those two Users live and hold a reference to them, so I can control their behaviour :). These references are of a given type, and I can figure out what I can do with them when in my hands.

Knowing object’s type is pretty nice because it expresses better the thoughts in code, easier to read, indeed. For me that have bad a memory is great to remember 🙂

Now, my model evolves and my customer is telling me that a user has many friends, that are also players in the virtual world!! I start to model something like:

public class User {
    private final string name;
    private List<User> friendsList = new ArrayList<>();

     public User(String aName) {
         this.name = aName;
     }
     ...
     public List<User> getFriendsList() {
         return Collections.unmodifiableList(frinedsList);
     }
}

Clients of the User type can interact with the reference like:


   List<Users> userFriends = user.getFriendsList();

P.S. – Java 7!

Pretty straight forward! User’s clients know that when they send a message to a user object they will receive a list of users, and the client code defines meaning for that list of users as being the friends of the user, using the name userFriends for the reference, for that matter. Later in the code, the client may use this reference, and when it uses it knows the context of that list of users, it’s a list of friends, duhh!!

Now, other guy may write this code:


   List<Users> user = user.getFriendsList();

It’s still ok, but… later in the code the only context I would infer immediately from this reference is that is a list of users but and it represents??? oops, I lost my self in a loads of complex code, give an help for the maintainer please!! 🙂

Getting things worst, in pre generics era, I would model something like:

public class User {
    private final string name;
    private List friendsList;

     public User(String aName) {
         this.name = aName;
     }

     public List getFriendsList() {
         return Collections.unmodifiableList(friendsList);
     }

}

And later in my code, getting the user’s friends would look something like:

   List users = user.getFriendsList();

Now, I completely lost. So, have a list of objects but hey, their type may be users, since the name of the reference is trying to give a hint, but it may be wrong…who knows? This code knows:

   Object obj = users.get(0);
   if (obj instanceof User) {
       User = (User)Object;
   }

Getting back in time!!!

The point here is that the Java language has evolved it’s type system, so will I!

I would prefer to model something like this:

public class User {
    private final string name;
    private FriendsList friendsList = new FriendsList();
    public User(String aName) {
         this.name = aName;
     }
     ...
     public FriendsList getFriendsList() {
         return friendsList
     }
}

public class FriendsList {
    private final string name;
    private List<User> = new ArrayList<User>();

     public FriendsList() {
     }
     ...
     public Iterator<User> getFriendsListIterator() {
         return friendsList.iterator();
     }
}

Now I have context everywhere. Since Java is a Strongly typed language, let’s use types. What you think?

Continue Reading
Continue Reading
Continue Reading

Inheritance in JPA Entities

“..but equals should usually compare state, not identity. This is particularly true for “data-centric” classes which map to database records. […] If you extend a concrete class, and add a new field which contributes to equals, then it is not possible to write a perfectly correct equals method for the new class. Instead, you should use composition instead of inheritance. (See Effective Java by Joshua Bloch for more information.) ”

From http://www.javapractices.com/topic/TopicAction.do?Id=17

This can be interpreted as “It’s not a good idea to use inheritance in, for example, JPA Entities. It’s better to use composition”.  I tend to agree. Deep hierarchies of JPA entities,  can be a daunting task to understand, maintain and extends. Having small hierarchies, I think it’s ok. If a JPA model, most of the time models real world concepts, and if real world concepts are better described in terms of composition, instead of inheritance, why complicate things? Take the typical Car exercise, would you model most of your car using inheritance or composition?

But if  you’re  modelling your JPA entities with object oriented principles , not caring about the mapping stuff, for now, everything that you will need to store in a DB are value types, like Integer, Long, String, byte[], or some composition of these and other value types, so there’s no point to inherit just to add values to an object, it’s better to create a new value type that represents the concept.

Continue Reading

Programmer testing exercise

Some time ago, I wrote here to leave you with a presentation about programmer testing. This post is a kind of follow up, leaving you now with the exercise.

You can see the exercise here

I also have the presentation in PDF stored in google drive. Find it here.

If you have any feedback/comments or whatever, comment this post.

Continue Reading

An introduction to Maven 2

This is an hands-on workshop about Maven. It will help you to get up and running with Maven if you don’t know Maven.
I have included the exercise that you can use to get your hands on Maven. This information is relevant also for Maven 3, though it was developed for Maven 2.

The presentation is here:

If you prefer the PDF, you can view it here: http://bit.ly/Ip7UYl

The exercise can be downloaded/viewed here http://bit.ly/KXB6v3

If you any feedback/comment/whatever comment it.
 

Continue Reading

Quick introduction to REST and JAX-RS

Here are some slides introducing to REST world. Examples are using JAX-RS (JSR 311).

If we’re moving to the cloud-era, the undestanding of this architecture style is essential. In the cloud we are presented with services (Storage, Search, Graph, Geolocation, …) that we can and should use to build applications. Almost all of these services, available  in the cloud, provide some kind of interface and happens that, this  interfaces is, generally, a RESTful Web Service. If I want collaborate with these services I must talk the same language!! Moreover, exploring this architectural style in new applications opens the door for realy distributed and scalable systems, while the simplicity is kept high!

Here the slides:

PDF can be downloaded from here.

Continue Reading

Software Architecture disruption?

:Adrian Colyer is a smart guy and he  put together, in a talk, what software architectures will look like for the next years. True is, most of the services you’re using online today follow these architecture principles. Nothing new, thought.

Nothing in this architecture is can go wrong,  it’s so simple! This type of architecture is the perfect fit for this ubiquitous platform that is Internet.

Btw,  SpringSource makes it really easy to develop applications in this way, just look to Spring Integration project, for example. They have a plenty of projects, built on top of Spring, that makes development of this type of architectures more, and more fun and easy.

(Ignore the sound problems at the beginning 🙂 )

Contrast this with traditional “enterprise” architectures. Which side of the fence you want to be?

Continue Reading

How to violate the Interface Segregation Principle

In my last post, I gave away some slides where OO Design Principles are introduced. I have an though about the big-fail that was the J2EE (before JEE5), in terms of violating the Interface Segregation Principle.

If you you are fortunate enough to have experienced the pain of writing applications with J2EE, then you recall that, for example, when you define an Stateless EJB, you have to implement the SessionBean interface.

Well, this is a clear violation of the Interface Segregation Principle, your EJB component have to implement the EJB lifecycle callback methods, even if you don’t need them. Right?

For instance:

public class MyComponent extends SessionBean {
    public void someCoolBusinessMethod() {
         // Business knowledge is coded here
    }

    public void ejbCreate() {} //Don't have anything to do in this EJB lifecycle callback, but the interface forces me to implement the method

    public void ejbRemove()  {} //Don't have anything to do in this EJB lifecycle callback, but the interface forces me to implement the method

   public void ejbPassivate() { } //Don't have anything to do in this EJB lifecycle callback, but the interface forces me to implement the method
...
}

Latest versions of JEE (5 and 6), allows you to bind methods to component lifecycle events declaratively, with annotations of XML. For example:

public void MyOtheComponent {
    public String realBusinessMethod() {
        return "I do really cool stuff";
    }

@PreDestroy
   private void letMeGo() {
   //Any business that should run before the object is left to the GC
   }
}

They fixed it, but very behind time…

Continue Reading