The Chosen Frameworks

• Castle Project
• StructureMap
• Ninject
• Unity
• Autofac

The Criteria

Maturity: Maturity measures the extent of a framework’s travel.  In other words, maturity is a proxy for length and for frequency of usage.  These measures are a simple method to approximate quality.  Although age does not necessitate it, older frameworks tend to have fewer bugs than younger frameworks do. Consequently, maturity is a solid approximation of quality.

Functionality: Functionality is a bipartite metric; it measures both the completeness of the functionality and the functionality’s usefulness. Both aspects are required, because each one measures a different aspect of functionality.  Completeness measures breadth, which is a proxy for applicability. Usefulness is a measure of utility.  Ideally, a framework should be applicable to a great many situations and highly useful to what a developer wants to achieve.  Functionality measures the degree to which a framework matches the aforementioned ideal.

Performance:  Performance measures the extent to which a given framework affects the response time of software.  Slow response times elicit frustration – a reaction that tends to degrade a user base. Consequently, frameworks that negatively affect performance become unusable – so performance is a very critical criterion.

Fault Tolerance: Fault tolerance measures the gracefulness with which a framework fails – an inevitable occurrence in software as all frameworks will fail at one point or another. The question is, therefore, the gracefulness of the aforementioned failure.  Some frameworks are quite graceful in their failures while others are ham-handed.  The latter sort of handling introduces bugs, which forces the surrounding software to manage carefully what is passes to the framework to prevent catastrophic failure.  However, no software is perfectly careful, so clumsy failures will inevitably lead to serious bugs.  For this reason, good frameworks fail gracefully, allowing the surround software to recover.  Fault tolerance measures the degree to which a framework has this sort of grace.

The Evaluation

Maturity: StructureMap and Castle are the most mature frameworks by far.  According to StructureMap, it has been used in production systems since 2004.  According to the Castle, it began as a project in 2003.  An article that Wikipedia cites corroborates this evidence by stating that in 2006, the second release of Castle’s version one was already available.  The other frameworks have little information on their history so as best I can conclude, the projects behind these frameworks emerged between 2008 and 2010.  Consequently, StructureMap and the Castle are clearly the most mature frameworks.

Functionality: Author Mark Seeman provides short comparison of functionality on Stackoverflow.  According to Seeman, Castle is complete – although he does state that Castle’s API is “quirky” in places – but the other frameworks either lack Castle’s features or implement them poorly, so one must take Seeman’s criticism of Castle with a grain of salt.  Another comparison corroborates Seeman’s conclusion by stating that Castle has – when compared to the other frameworks – a nice set of features.  However, Castle is hardly the most beloved kid on the block.  The writer of the aforementioned comparison states that he had a negative experience with Castle and a poll indicates that a sizeable number of people hate Castle for no rational reason.  Clearly, Castle has, in spite of its excellent feature set, some detractors – yet the aforementioned poll also shows a sizeable number of people who have found Castle to be a very good solution to their problems.  As a side note, StructureMap also polls well – an indicator that it is, in spite of its missing features, a very good solution.  Seeman’s comparison corroborates these poll results.   Given the aforementioned information, Castle clearly emerges as the functional valedictorian, but StructureMap appears to be solid salutatorian.

Performance:   Any measure of performance is heavily dependent upon the nature of the benchmark in question – as some benchmarks are biased towards particular frameworks – so the only true way to guard against tendentious measurements is to use multiple benchmarks.  I found three benchmarks – two of which were very detailed and one of which seemed rather poorly defined – but I was still able to draw some conclusions.  In the first benchmark, which provides no description of its methodology, StructureMap and Autofac emerge as winners, because both frameworks performed well on one test and both frameworks did admirably well on all of the tests.  The second benchmark, which very specifically defines its methodology, directly contradicts the result of the first benchmark.  With regard to Singletons, Castle does not perform as poorly as it did on the first benchmark; and with regard to Transients, Castle is not as slow as it was in the first benchmark either but in the middle instead.  The most detailed by far, the third benchmark settles the argument.  Castle does not have any serious performance issues, as the first benchmark indicates.  In fact, it is has relatively standard performance.  However, as all of the benchmarks indicate, StructureMap has excellent performance and Ninject has poor performance, so some consensus does exist.  Regardless, no serious performance drags exist, with the exception of Ninject and Unity, so all of the IOC frameworks appear to be solid choices with regard to performance.

Fault Tolerance:  Little attention was paid to fault tolerance, so I was only able to find one comparison that addressed it.  Take what I write with a grain of salt, but the conclusions seem clear enough that they warrant mention.  When dependency resolution problems occur, Autofac and Castle throw meaningful exceptions while the others throw Stackoverflow exceptions – a contrast that indicates that Castle and Autofac are frameworks that are more graceful than the other ones are.  Stackoverflow exceptions crash programs, so they force an application to manage carefully what it passes to the IOC framework, because one poorly considered dependency injection could crash the application.   Such concerns cannot be entirely obviated – even when one is perfectly aware of them – so graceless errors such as Stackoverflow exceptions are a serious problem – a conclusion that makes Castle and Autofac appear all the better.

Conclusions

Castle and StructureMap are quite close to each other in this comparison, yet one area distinguishes them: fault tolerance.  Castle does not metaphorically blow up in your hand if it encounters a problem, as StructureMap does – so a programmer can feel comfortable using Castle in software that must be stable.  Castle’s detractors are likely to doubt this conclusion and their scoffery is well founded. Castle is quirky in places and these quirks are likely to introduce frustration, which can lead to bugs – yet quirks are tractable, if they are not endemic.  Based upon on the evidence, Castle’s quirks do not appear to be structural, as many developers have found it to be quite useful, so the concerns of Castle’s detractors, while well founded, are moot.  As a result, Castle is, in spite of its quirks, the best IOC solution for .Net.

WindsorContainer rootContainer = new WindsorContainer(); //builds the base container

//a meth to register types to the root container
public void registerToRoot(IWindsorInstaller installer)
{
    installToContainer(rootContainer,installer);
}

//installs a sub container, which can be used to represent systems
public void addContainer(string systemKey,IWindsorInstaller installer)
{
    //castle requires a sub containers to have a config file, but you don't have to use it
    IWindsorContainer container = new WindsorContainer(systemKey, rootContainer, new XmlInterpreter());
    installToContainer(container,installer);
}

//a generic method to install to a container
private static void installToContainer(IWindsorContainer container, IWindsorInstaller installer)
{
   container.Install(installer);
}

//a method to acquire a type from castle
public PolicyType acquireInstance<PolicyType>()
{
   PolicyType acquisition = rootContainer.Resolve<PolicyType>();
   return acquisition;
}

//a method to acquire an implementation from a sub container
public PolicyType acquireInstance<PolicyType>(string systemKey)
{
   PolicyType acquisition = rootContainer.GetChildContainer(systemKey).Resolve<PolicyType>();
   return acquisition;
}

//the code of the installer, which places implementations in Castle
public sealed class InstallerInstance : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
       /*
       * The code below registers an implementation of an interface.  The lifestyleMethod must be
         filled in with one that you choose (e.g singleton,transient, pooled, etc.)
       *?
       container.Register(Classes.From(someType).BasedOn<someInterface>().WithServiceAllInterfaces().LifestyleMethod());
    }
}

Unlike relational databases, which are built around columns and rows, document-oriented databases are designed around blocks of data – a quality that makes them ideal for storing unstructured data. In a document-oriented database, a block can be a single field such as name or an amalgamated structure such as an author, which itself can contain fields and structures.  In other words, data is designed, in a document-oriented database, as though it is document.  This schema provides a convenient way to build a structure to hold data that does not fit readily into the traditional schema of rows and columns because unlike relational databases, the block structure of document-oriented databases is very flexible. As a result, document-oriented databases are quite useful with regard to unstructured data, which necessitates structural flexibility.

The most obvious of these uses is document storage.  Documents, or files, can more easily be stored and more easily retrieved from a document-oriented database than they can be stored and retrieved from a relational database.   The block schema employed by document-oriented databases provides a more facile way to store documents than the rows-columns schema of relational databases does. Relational databases do provide a way to handle documents through data types such as blobs or through functionality such as file streaming.  However, these methodologies are hacks added onto the database schema to handle a common but inconvenient problem.  As a result, the easy with which document-oriented databases handle is appealing.  In fact, document-oriented databases appear to be emerging rapidly as the standard for storing documents.  They are proving to be more than simply an interesting theory regarding data storage.  Real organizations are using them.

However, documents are only a small section of the potential uses for document-oriented databases; among them is content management – because any content management system (CMS) requires a storage medium.  Typically, this storage medium has been a relational database.  As previously stated, such databases have some limitations.  A relational database requires that data be defined in terms of tables, columns, and rows.  This type of structure is very restrictive and content does not fit neatly into this type of structure.  Realizing this limitation, some Java-based CMS’s use a Java Content Repository (JCR), which stores content in a tree structure instead of a collection of tables.  However, if an organization does not use Java, a JCR is not a viable solution – yet this quagmire of finding a language-compatible solution can be obviated by using a document-oriented database to store content.  Document-oriented databases are not language specific, yet they provide the same structural qualities of a JCR. As a result, content in a document-oriented database can be constructed hierarchically just as it can in a JCR – so a document-oriented database is applicable to the same problem set.  However, a document-oriented database does not lock an organization into a language – a quality that allows for solutions that are more flexible. However, I am unaware of any organization who utilizes them in this manner, but I mention this usage, because I see the potential for an elegant solution.

Document-oriented databases do have their limitations, though; chief among them is the lack of discipline that relational databases enforce. Flexibility, which document-oriented databases allow, is not conducive to discipline – because flexibility brings with it the temptation for poor design. Inelegance is pursuant to this temptation.  Ideally, inelegance should be avoided and it should never be introduced by choice. As a result, storage mediums that make, in certain instances, inelegance facile should not be used under these conditions. Consequently, document-oriented databases should be avoided for that data that necessitates adherence to a strict structure i.e. the data in question is structured.  For data of this sort, relational databases are a better solution than document-oriented databases are.  Consequently, document-oriented databases are not intended to replace relational ones but to augment them instead.

In spite of this ancillary status, document-oriented databases are still quite useful.  I recommend considering adding them to the IT toolkit, because they have the potential to solve certain problems more elegantly than relational databases do.  One such database to consider is MongoDB.  Give it a look.  MongoDB might help to solve some previously intractable problems.

Regarding the types of objects that can be managed, an object manager has no inherent restrictions, but a developer might want to impose some anyway.  For example, a developer might consider creating – to limit the types of objects that a manager can manage – an interface (e.g. IManagedObject) that indicates that an object is managed.  Moreover, a manager frequently allows coders to find a specific object – so managed objects should also be limited to types that are uniquely identifiable – types that extend a special interface (e.g. IUnique) indicating that an object is unique.  Such restrictions are prudent to manage objects effectively.

However, a prudent design of managed objects does not describe how an object manager manages its objects.    Fortunately, this ambiguity can be made removed.  Put simply, object managers perform only a few simple tasks: addition, removal, search, and retrieval of the collection.  Addition adds objects to the manager.  Removal removes objects from the manager.  Search finds a specific object, if it exists.  Retrieval of the collection grabs the collection of managed objects. All of these tasks must be handled by every object manager.

After reading the previous paragraph, however, some coders might ask – “Shouldn’t more functionality be included in a manager?”  While quite keen, this question conflates what an object manager does with its uses inside of an application.  While a given object manager has many uses, only a few of them are endemic to managing objects.   The rest of the uses can be implemented by using the functionality described in the previous paragraph.  For example, a manager’s collection can be retrieved and the data from each object can used to search inside of another manager for one of its objects. Such a composite function does not need to be implemented inside either manager – because the standard management functions can be used to implement the composite function.

However, knowing what a manager manages and what a manager does is insufficient to implement an actual manager – a problem that a manager paradigm helps to eliminate.  Such a paradigm is detailed, briefly, in the subsequent code.  By extending it, one can construct a specific manager.

public interface ICodExploUnique
{
}

public interface ICodExploManagedObject<ObjectType> : ICodExploUnique
   where ObjectType : ICodExploManagedObject<ObjectType>
{
   ICodExploManager<ObjectType> Manager { get; set; }
}
public interface ICodExploManager<ObjectType>
  where ObjectType : ICodExploManagedObject<ObjectType>
{
  IList<ObjectType> Objects { get; }
  void addObject(ObjectType obj);
  void clearObjects();
}

public interface ICodExploKeyed : ICodExploUnique
{
  String Key { get; set; }
}

public interface ICodExploKeyedManagedObject<ObjectType> : ICodExploManagedObject<ObjectType>, ICodExploKeyed
   where ObjectType : ICodExploKeyedManagedObject<ObjectType>
{
}

public interface ICodExploKeyedManager<ObjectType> : ICodExploManager<ObjectType>
   where ObjectType : ICodExploKeyedManagedObject<ObjectType>
{
   ObjectType findObject(String key);
   void removeObject(String key);
}

public abstract class BaseKeyedManager<ObjectType> : ICodExploKeyedManager<ObjectType>
		where ObjectType : ICodExploKeyedManagedObject<ObjectType>
	{
		#region Data

		private IList<ObjectType> objects;

		#endregion

		#region Constructors

		public BaseKeyedManager()
		{
			Objects = new List<ObjectType>(0);
		}

		#endregion

		#region ICodExploKeyedManager

		public ObjectType findObject(string key)
		{
			if (key == null)
			{
				throw new CodExploManagerException("An object cannot be found without a key");
			}
			else { }

			ObjectType found = default(ObjectType);

			foreach (ObjectType obj in objects)
			{
				if (obj.Key != null)
				{
					if (obj.Key == key)
					{
						found = obj;
						break;
					}
					else { }
				}
				else { }
			}

			return found;
		}

		public void removeObject(string key)
		{
			ObjectType found = findObject(key);

			if (found != null)
			{
				objects.Remove(found);
				found.Manager = null;

				if (found is ICodExploDestroyable)
				{
					((ICodExploDestroyable)found).destroy();
				}
				else { }
			}
			else { }
		}

		public IList<ObjectType> Objects
		{
			get { return objects; }
			private set { objects = value; }
		}

		public void addObject(ObjectType obj)
		{
			if (obj == null)
			{
				throw new CodExploManagerException("A null object cannot be added");
			}
			else { }

			obj.Manager = this;

			if (obj is ICodExploInitializeable)
			{
				((ICodExploInitializeable)obj).init();
			}
			else { }

			objects.Add(obj);
		}

		public void clearObjects()
		{
			objects.Clear();
		}

		#endregion
	}

public final class RenderUtility {
    public static Geometry createGeometry(String name, Mesh msh, Vector3f loc){
        if(name == null || msh == null || loc == null){
            throw new RenderableException("One or more parameters is null");
        }else{}

        Geometry geom = new Geometry(name, msh); //error in here when cylinder

        geom.setLocalTranslation(loc);

        return geom;
    }

    public static AbstractBox createBox(Vector3f size, boolean isFilled){
        if(size == null){
            throw new RenderableException("One or more parameters is null");
        }else{}

        AbstractBox bx = null;

        if(isFilled){
           bx = new Box(size.getX(),size.getY(),size.getZ());
        }else{
            bx = new StripBox(size.getX(),size.getY(),size.getZ());
        }

        return bx;
    }

    public static Dome createDome(int planes, int radialSamples, float radius){
        return new Dome(planes, radialSamples, radius);
    }

    public static Cylinder createCylinder(int axisSamples, int radialSamples, float radius, float height){
        return new Cylinder(axisSamples, radialSamples, radius, height);
    }

    //need to reduce parameters but will do that later
    public static Material createMaterial(AssetManager mngr, String matName, String colorName, ColorRGBA color){
        if(mngr == null || matName == null){
            throw new RenderableException("One or more parameters is null");
        }else{}

        Material mat = new Material(mngr,matName);

        if(colorName != null && color != null){
            mat.setColor(colorName, color);
        }else{}

        return mat;
    }

    public static Texture createTexture(String textureName, AssetManager mngr){
        if(textureName == null || mngr == null){
            throw new RenderableException("One or more parameters is null");
        }else{}

        return mngr.loadTexture(textureName);
    }

    public static Spatial loadObjModel(AssetManager manager, String modelName, Vector3f scale, Vector3f loc){
        if(manager == null || modelName == null || scale == null){
            throw new RenderableException("Could not load model");
        }else{}

        Spatial mdlSptl = manager.loadModel(modelName);
        mdlSptl.scale(scale.getX(), scale.getY(), scale.getZ());

        if(!(mdlSptl instanceof Geometry)){
            throw new RenderableException("The model is not a geometry");
        }else{}

        ((Geometry)mdlSptl).setLocalTranslation(loc);

        return mdlSptl;
    }

    public static IScienceCraftLight createDirectionalLight(ColorRGBA color, Vector3f vec, String name){
        IScienceCraftLight light = new StandardDirectionalLight();
        light.setKey(name);

        light.setLight(createDirectionalLightSource(color,vec,name));

        return light;
    }

    public static IScienceCraftLight createPointLight(ColorRGBA color, float radius,Vector3f pos, String name){
        IScienceCraftLight light = new StandardPointLight();
        light.setKey(name);
        light.setLight(createPointLightSource(color,radius,pos,name));

        return light;
    }

    public static IScienceCraftLight createAmbientLight(ColorRGBA color, String name){
        IScienceCraftLight light = new StandardAmbientLight();
        light.setKey(name);
        light.setLight(createAmbientLightSource(color,name));

        return light;
    }

    //from: http://jmonkeyengine.org/wiki/doku.php/jme3:advanced:light_)and_shadow
    private static DirectionalLight createDirectionalLightSource(ColorRGBA color, Vector3f vec, String name){
        DirectionalLight light = new DirectionalLight();
        light.setName(name);
        light.setColor(color);
        light.setDirection(vec.normalizeLocal());

        return light;
    }

    //from: http://jmonkeyengine.org/wiki/doku.php/jme3:advanced:light_and_shadow
    private static PointLight createPointLightSource(ColorRGBA color, float radius,Vector3f pos, String name){
        PointLight light = new PointLight();
        light.setColor(color);
        light.setRadius(radius);
        light.setPosition(pos);
        light.setName(name);

        return light;
    }

    //from: http://jmonkeyengine.org/wiki/doku.php/jme3:advanced:light_and_shadow
    private static AmbientLight createAmbientLightSource(ColorRGBA color, String name){
        AmbientLight light = new AmbientLight();
        light.setColor(color);
        light.setName(name);

        return light;
    }
}

• Type information:  Class metadata stores information, which can be used, for example, to test whether a class extends another class or vice versa.   If code requires that different actions be taken for different classes, this information is clearly useful.  However, both Java and C# provide operators to test this sort of information on objects, so type reflection seems pointless, yet a code block might not be operating on an object.  It might be working on actual class information in which case the ability to test type information is actually quite helpful.
• Object construction:  Classes have constructors.  Constructors build objects.  Through type reflection, a coder can grab a specific constructor for a class.  This constructor can be used to build an object.  Typically, a coder knows the class with which he is working and simply uses the appropriate constructor – so access to constructor information seems useless. A coder might not know the class with which he is working, though.  He might only have access to the class data.  In such cases, the only way to construct an object is through type reflection.
• Type Obfuscation:  Using type reflection, class information can be grabbed by its fully qualified name.  Unlike the other examples, however, this process is very language dependent – but the concept is, regardless of the specific mechanism, the same in every language.   A string that contains all of the information to identify specifically a class is required.   This string can be used to grab the desired class information.  With this class information, type information can be tested and objects can be constructed.  A coder can use a class without having necessarily to declare it by name.

//grabbing a class
Class<?> c = null;
String classString = "com.codexplo.somepackage.SomeClass";
c = Class.forName(classString);

//Testing type information
boolean doesClassExtend = c.isAssignableFrom(SomeOtherClass.class);

//Building An Object
Constructor<?> constr = c.getConstructor(new Class<?>[]{}); //get empty constructor
SomeClass obj = obj = (SomeClass)constr.newInstance(new Object[]{}); //use empty constructor

Example Code

Classes often contain methods for building themselves.  Initialization might have needs beyond what a constructor provides, so an additional method is required.  Design taxonomy refers to these methods as factory methods, because they build objects.   A designer can place these methods in a separate utility class. They do not need to exist in the class that they are designed to build.  Including factory methods inside of a class leads to bloat, which is deleterious to design, so one should place, where possible, such methods in a separate class.  Following this rule reduces the size of one’s classes and as a result, the quality of design will improve.

Some methods perform operations using a class, but do not need to have complete access to the class’s internal data.  A designer can place such methods in a utility class. For example, code might need the ability to combine two people through a reproductive process.   That reproductive process does need not complete internal access, so the reproductive operation need not be an internal operation.   On occasion, however, an operation such as reproduction might require functionality that is otherwise unsupported.  In such cases, a designer should create methods to handle that functionality.   Operations such as reproduction can continue to remain separate from the person class.  With that separation, the person class is less bloated than it otherwise would be.

Separating the methods above and others allows a designer to achieve a clearer design.  With more focused and less bloated classes, a reader of code can more easily understand its design. For that reason, narrow, lean classes are canonical to good design.   Separating static methods from classes where possible is one aid to achieving the lean, focused classes that good design demands.

The sample code

One of the more common ways to generate a string is the amalgamation of multiple strings into one, which a coder typically achieves through concatenation. However, concatenation is awkward and messy.  Dot Net has a more graceful method.  String.Format achieves the same result but in a more agile way.  By using String.Format, a coder can insert several strings into a surrounding template.  From those strings and template, String.Format produces a string.  Code that produces strings in this manner is much more graceful than concatenation is, because the intended result is much clearer.   Consequently, String.Format produces less clunky code.

Still, the more graceful String.Format only provides so much benefit.  A coder cannot obviate all of problems of string generation through String.Format.  For starters, the parts of a string template can be complex and/or highly variable.   A programmer can make each part of the template simpler by adding more parts, but that cure might be worse than the disease ease.  A string template with a large number of parts does not look much better than a string created through concatenation does.  As a result, graceful string generation requires another utility.

Similar to String.Format, StringBuilder allows a coder to create a string out of several parts.   Unlike String.Format, however, StringBuilder allows a coder to add parts as needed; a string can be piecemealed.  That ability to build a string a piece at a time is incredibly useful.   Highly variable pieces of strings that cannot be built using String.Format can be built using StringBuilder. As a result, StringBuilder enhances the Dot Net tool belt.

Using these tools of the DotNet tool belt, String.Format and StringBuilder, a coder is able to construct strings in a graceful way. With its templates, String.Format can wrap a highly complex and variable string constructed through StringBuilder inside a template.  A coder wielding this technique can generate even the most unwieldy of strings in a graceful way.  As a result, a coder can alleviate a sizeable part of a major source of his headaches.

/*
			 * The code below uses String.Format to build a string out parts.
			 * As one can clearly see, the resulting is clear, but this code
			 * becomes brittle if the need to change.
			 */
			String tableName = "Table1";
			String fields = "field1, field2, field3";
			String parameters = "@field1, @field2, @field3";
			String insertStatement = String.Format("INSERT INTO {0} ({1}) VALUES ({2}); SET NOCOUNT ON; SELECT Scope_Identity();", tableName, fields, parameters);

			System.Console.WriteLine(insertStatement);

			/*
			 * The code below demontrates the combination of String.Format
			 * and StringBuilder.  The field array is hard coded but using this
			 * approach.  The array and table name could easily from an object.
			 * The approach still produces clear strings but is much more
			 * flexible.
			 */

			StringBuilder fieldsBldr = new StringBuilder();
			StringBuilder parameterBldr = new StringBuilder();
			String[] fieldsArr = new String[] { "field1", "field2", "field3" };

			bool isFirst = true;
			foreach (String field in fieldsArr)
			{
				if (isFirst)
				{
					fieldsBldr.Append(field);
					parameterBldr.Append(String.Format("@{0}", field));
					isFirst = false;
				}
				else {
					fieldsBldr.Append(", ");
					fieldsBldr.Append(field);
					parameterBldr.Append(", ");
					parameterBldr.Append(String.Format("@{0}", field));
				}
			}

			String bldrFormatInsertStatement = String.Format("INSERT INTO {0} ({1}) VALUES ({2}); SET NOCOUNT ON; SELECT Scope_Identity();", tableName, fieldsBldr.ToString(), parameterBldr.ToString());

			System.Console.WriteLine(bldrFormatInsertStatement);

To code clearly, one must use to indentify coding elements appropriate, precise names.  Named appropriately and precisely, the names of coding elements provide to the reader clear, accurate information.  With that information, the reader is able to understand more easily the code that he is perusing.  Consequently, naming conventions that produce appropriate, precise names are essential for writing good code. As a means to achieve such names, the list below provides guidelines.

1. The names of all interfaces and classes should begin with a capital letter.   This convention is simply good, object-oriented form.  Beginning classes and interfaces with a capital letter helps a reader to identify types.
2. All interface names should begin with the letter “I.”   This convention is borrowed from DotNet.  The letter “I” provides a shorthanded, simple way to identify interfaces.
3. Any class that is intended to be used as a base class should have in its name the word “base.”  With “base” in the name, a reader knows that the designer intended a class to be used as a building -block.  As a result, a reader can easily distinguish between building blocks and non-building-blocks.
4. Any class that contains only static methods should have in its name the word “utility” or “library.”  Such words signify to the coder that a class is intended to be used as a helper.
5. The names of all methods and functions should begin with a lowercase letter.  Similar to the first rule, this convention is simply good, object-oriented form.  Such a convention assists a reader in distinguishing easily between classes and methods.
6. All method names and function names should contain a verb.  Including in the name a verb allows the reader to identify easily actions.
7. All variable names and field names should begin with a lowercase letter.  Similar to the first and fourth tips, this convention is simply good, object-oriented form.  Such a convention helps a reader to distinguish easily between data and classes.
8. All variable names and field names should contain, unless their type is Boolean, a noun.  By including a noun in the name, a coder helps reader to identify easily data.
9. Any variable name or field name whose data type is Boolean should be formulated as a question.  Similar to the first, fourth, and sixth tips, this convention is simply good, object-oriented form.   A coder who formulates Boolean data as a question helps a reader to distinguish easily between flags and data.
10. The letters of any constant should be capital letters.  This convention is simply good structured form.  Making a constant’s letters capital allows a reader to distinguish between constants and everything else.