A Simple Rule For Using Arrays

Based upon the Law of Demeter, I often am confronted with problems with a fear of creating arrays in methods and parsing them around, especially when the array falls into a collection and represents a data type almost.

For example:
// logmatches[0] ~ id of log
// logmatches[1] ~ regex of log
// logmatches[2] ~ matches
int[] logmatches = new int[3];

Now I know this is simple, but yes I often get caught creating these arrays and parsing them around, when I should rather create and object or container and use that within the collection.

// Refactor to encapusalte, but you get the idea.
public class task {
    private int id = 0;
    private String regex = “”;
    private int matchesFound = 0;
}

TTFN

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

Items 2: Enforce the Singleton property with a private constructor

A singleton is a simple class that is instantiated only once.

Best method for using a singleton:

public class CustomerList {
   private static final CustomerList INSTANCE = new CustomerList();

   private CustomerList()
   {}
 
   public static CustomerList getInstance()
   {
      return INSTANCE;
   }

   .. // Remainder omitted
}

Main advantage of this approach is it allows for the flexibility to change your mind about the class without changing the API.
Use this approach when you uncertain to the dynamics of the class.
If you are certain it will forever remain a singleton, stick to a “public static final” as opposed to a private through public accessor.

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

Item 1: Consider Providing static (factory) methods instead of constructors

Advantages:

  1. Unlike constructors they have names
  2. Static factory unlike constructors do not require creation of a new object
  3. Static factory can return an object of any subtype of their return type

Disadvantages:

  1. Main disadvantage is that classes without public or protected constructors cannot be subclassed. (A subclass is a class which inherits a method or methods from a superclass)
  2. Static methods are not readibly distinguishable from other static methods (do not stand out like constructors in documentation and outside the norm)
Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

Logic to Calculate Time Differences

For example, hour minute difference for 3:35pm – 7:20pm

a)First work out, how short of an hour the minutes are in 3:35pm
60 – 35 = 25;
b) Then increment (round-up) 3:35am to closest hour ~ 4:00pm
c) Then work out how many minutes are used within an hour in 7:20pm.
Obvious, but elaborate logic breakdown (20 minutes).
d) Then decrement (round-down) 7:20pm to 7:00pm.

Equation then: (my own logical algorithmic representation)
= 25 + (7:00pm – 4:00pm) + 20
= 25 min + 3 hours + 20 min
= 3:45

Now obviously this is over elaborate as mentioned above in steps and explanation; but in reality, if you stick to the equation, you can work it out on one line in 10 seconds.

Little stupid efficiencies ok! I like it!

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

Abstract Class Vs Interface

An Abstract Class can contain default Implementation, where as an Interface should not contain anyimplementation at all. An Interface should contain only definitions but no implementation. where as anabstract class can contain abstract and non-abstract methods. When a class inherits from an abstract, thederived class must implement all the abstract methods declared in the base class. an abstract class can inherit from another non-abstract class.

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

Unit Testing Principals

(jUnit In Action)

a) Benefit from Access Modifiers
b) Don’t mix instantiation into your application logic
c) Don’t work in the constructor
d) Follow the Principle of Least Knowledge (Law of Demeter)
e) Avoid hidden dependencies
f) There is a bad side to singletons
g) Avoid static methods (Builds procedural programming)
h) Favor polymorphism over conditionals. (no long decisions)

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

Difference between ID and Name in HTML

Name is coming from the initial DOM 0 (DOM Zero Level) interface
model. In this model form controls are identified by name or by index
in elements collection:
document.forms[0].elements[0];
document.forms[0].elements[“FirstControl”];
Only controls having name attribute set are being submitted, this rule
is in effect since then and forever.

id attribute was introduced only in DOM 1. As other poster pointed out
ID supposed to be unique for the given document, while name can be the
same for many elements (think of radio buttons group for instance).

This is why say accesskey is attached to ID and not to name. That is
not the only neither the main reason but it gives the idea why
sometimes it is useful to set both id and name for a form control,
like:

<input type=”radio” value=”yes” name=”rdg” id=”rd01″>
<label for=”rd01″>Yes</label>

<input type=”radio” value=”no” name=”rdg” id=”rd02″>
<label for=”rd02″>No</label>

For anchors and links collections name attribute usage is deprecated
and rarely used.

document.images[“ImageName”] is still pretty much in use.

Original Document

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

Double the Threads, Double the Handles, Double The Memory

So, I spent 1 week trying to track down a problem in my code.
And it got to a point of feeling helpless and quiet demotivated. My code had an anomaly, a bug that resulting in a doubling of handles and a doubling of Threads.

I must have sifted through every piece of code possible, only to find a small an really stupid unclosed handle.
Now in hindsight I’ve realised, in finding this evil little bugs, comment out key functionality, deploy, debug, until you can gain a handle on more or less where the bug might be happening. Then, spend time there checking:

a) Poorly handled exceptions
b) Unclosed resource handles
c) A Freeing of Memory Used if making native calls
d) All Database connections are closed
e) Tight Loops
f) Scanners used with calling a next()

I just keeping adding that as a reminder of silly mistakes I make that I should avoid.

HTH me!

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone