Quote of the Day


Quotes and sayings

Archives

Categories

  • 11Apr

    Item 1. Consider static factory methods instead of constructors.

    Advantages:

    1. One advantage of static factory methods is that, unlike constructors, they have names.
    2. They are not required to create new objects each time they are invoked. This allows immutable classes to use preconstructed instances, or to cache instances as they are constructed.
      Help to increase performance.
    3. Another advantage is that, unlike constructors, they can return an object of any subtype of their return type. This gives you flexibility in choosing the class of the returned object.
    4. They reduce the verbosity of creating parameterized type instances.

    Disadvantages:

    1. The main disadvantage of providing only static factory methods is that classes without public or protected constructors cannot be subclassed.
    2. They are not readily distinguishable from other static methods. Also they do not stand out in the API documentation as constructors do.

    Item 2. Consider a builder when faced with many constructor parameters.

    Static factories and constructors share a limitation: they do not scale well to large numbers of optional parameters.

    Alternative one:

    Traditionally, programmers have used the telescoping constructor pattern, in which you provide a constructor with only the required parameters, another with a single optional parameter, another with two optional parameters and so on, culminating in a constructor with all the optional parameters.
    The telescoping constructor pattern works, but it is hard to write client code when they are many parameters, and harder still to read it.

    Alternative two:

    JavaBeans pattern, in which you call a parameterless constructor to create the object and then call setter methods to set each required parameter and each optional parameter of interest.
    This pattern has none of the disadvantages of the telescoping constructor pattern. Unfortunately, the JavaBeans patter has serious disadvantages of its own. Because construction is split across multiple class, a JavaBean may be in an inconsistent state partway through its construction.

    Third alternative (the good one):

    Using the Builder pattern which combines the Telescoping pattern and the JavaBeans pattern. Instead of making the desired object directly, the client calls a constructor (or static factory) with all of the required parameters and gets a builder object. Then the client calls setter-like methods on the builder object to set each optional parameter of interest. Finally, the client calls a parameterless build method to generate the object, which is immutable. The builder is a static member class of the class it builds.
    The Builder pattern is more verbose than the telescoping constructor pattern, so it should be used only if there are enough parameters, say four or more (but you may want to add parameters in the future).
    In summary: The builder pattern is a good choice when designing classes whose constructors or static factories would have more than a handful of parameters.

    From Effective Java: http://java.sun.com/docs/books/effective/

    Tags: ,

  • 27May

    Today I started using EclEmma which is a free Java code coverage tool for Eclipse IDE.

    Basically it helps to identify the areas in your code that are (and are not) covered by a test case. This will help to improve the way you code and create JUnits.  You may become the one in your team with a 100% code coverage  :)

    More info here.

    Tags: , ,

  • 16Apr

    Team trust is something we need but something we just don´t build.

    Key points to consider to build professional trust (from Esther Derby)

    Address Issues Directly

    Building trust depends on team members having the courage to speak directly to the person “bugging them”, rather than going through a manager to communicate these concernes. This can be done also through a feedback (or “feelbad” as a friend says :D )

    Share Relevant Information

    Speak your mind. If you don´t agree, say it! Don´t wait until the disuccion has over and then came back saying you disagree. Also consider doing it in a constructive way.

    Follow Through on Commitments or Give Early Notice When You Can’t.

    Just do your best to be honest with your progress and be proactive when things are not going as planned for you. This is related to point #4.

    Say No When You Mean No.

    I guess in my case, I almost say always yes to everything related to work and then I have to say No because I just can´t with all the tasks assigned to me.

    So, you don´t have to say “yes” to every request in order to look like a “team player”. Saying Yes to everything can lead others to doubt your word. If you can´t say No, your Yes won´t mean anything.

    Admit you don´t have all the answers.

    Show What You Know and What You Don´t Know

    Share the information you have, the things you know, but also be aware and open about the things that you don´t know.

    Tags:

  • 06Apr

    I read this article and I would like to share:

    Ivan Jacobson, author of the original work on Use Cases said in the Software Education SDC conference in Melbourne, Australia that the Agile development needs to “Get Smart”.

    He stated that the information technology industry is very fashion conscious, having a tendency to latch onto silver bullets, and listed the following examples:

    • Fifteen years ago it was all about OO
    • Ten years ago it was about components, UML, Unified Process
    • Five years ago it was about RUP and CMMi
    • Two years ago it was about XP
    • Today it is about Scrum

    All have good elements – but none is what we need, what we need to do is to Work Smarter. He says “Being Smart is an evolution of being Agile”:

    • Agile means being flexible and adaptable
    • Agile provides simple/lightweight starting points
    • Being Smart is knowing when to go beyond agile
    • Knowing when to follow the rules and when to break them
    • Knowing when to be consistent and when to change
    • Knowing when to grow and when to shrink

    Smart is Agile++

    • Unsmart with People – viewing processes and tools as more important than people
    • Smart with People – recognizing and understanding that software is built by people, not with processes and tools!
    • Unsmart with Projects – Trying to follow a waterfall approach
    • Smart with Projects – Build a “skinny system” to demonstrate that you have eliminated all the critical risks, then add more capabilities on top of that skinny system as needed.
    • Unsmart with Process – continuously latching on to the latest fad, and trying to change everything you do in response to the newest rule book
    • Smart with Process – Don’t throw out the baby with the bathwater:
      1. Start with your existing way of working
      2. Find the pain points
      3. Change one practice at a time

    The key element to becoming Smart is to focus on the people, as Jacobson says, and “it all comes down to you”.

    Tags: ,

  • 03Apr

    Developer note: Productivity

    Having the right tools to be more productive. Xplorer2 is a great file management software, it has a lot of features but the one that I like the most is the dual pane mode to browse 2 folders in one single window.

    xplorer2

    There is a lite version free if you are going to use it ONLY for home or academic, otherwise you can try a trial version for 21 days free no obligation, which I tried and its very cool, it really helps to be a little more productive or at least have less win-explorers open.

    Tags:

« Previous Entries   

Recent Comments

  • brilliant!! We need more of this....
  • Yes it definitely helps, after that I saw software projects ...
  • I didnt know about the CAPM until I read your post, so do yo...