Factory and Abstract Factory Pattern in Apex

While building solution over force.com platform, you can easily observe MVC pattern across the platform, but when you scale to enterprise level solution, design pattern you chose, on top of MVC play a key role in putting direction the custom development and specially designing enterprise level of services. There are common design patterns and associated best practices for Apex Developer and how can you leverage those patterns.

I recommend reading common apex pattern here in official podium. So lets talk about common and most use designed pattern (factory) pattern, I already have written an example here on this. But over the period of time, I learned there is low understanding among peers on Factory Pattern and Abstract Factory Pattern.  Lets go in detail on the pattern with their class diagram for proper understanding on this

Supported Keywords in Apex 

Factory pattern

Factory pattern is a creational pattern (meaning it will deal with creation of objects). A creation pattern abstracts the object creation or instantiation of objects by hiding how the objects are created and in turn offer independency on object creation process. On the other hand, an Abstract Factory Pattern adds another level of abstraction little higher than factory pattern, and in-turn return Factory classes.

Scenario : Imagine writing a custom application, when you want the end-user to record a machine install on client location. This machine can be installed on-site or could be a remote install. In both the case install() is the common method on each type of install. Below is the UML diagram to add clarity on this.

Abstract Factory pattern

An Abstract factory pattern is one level of abstraction higher than a factory method pattern, which means the abstract factory returns the appropriate factory classes, which will later on return one of the product subclasses. Let’s look at a code now

When to use Factory and Abstract Factory Pattern ?

Factory pattern returns an instance of several (product hierarchy) subclasses (like Onsite, Remote etc), but the calling code is unaware of the actual implementation class.

The calling code invokes the method on the interface for example Install and using polymorphism the correct getInstall() method gets invoked. So, as you can see, the factory pattern reduces the coupling or the dependencies between the calling code and called objects like Onsite, Remote etc. This is a very powerful and common feature in many frameworks.

You do not have to create a new Onsite or a new Remote on each invocation as shown in the sample code, which is for the purpose of illustration and simplicity.

Another benefit going for the factory is that unlike calling constructors directly, factory patterns have more meaningful names like getInstall(...), getInstance(...) etc, which may make calling code more clear.

Using Singleton Pattern in Factory Pattern

Another important aspect to consider when writing your factory class is that, it does not make sense to create a new factory object for each invocation as it is shown in the sample code, which is just fine for the illustration purpose.

InstallFactory factory = new SimpleInstallFactory();

To overcome this, you can incorporate the singleton design pattern into your factory pattern code. The singleton design pattern will create only a single instance of your SimpleInstallFactory class.

Since an abstract factory pattern is unlike factory pattern, where you need to have an instance for each of the two factories (i.e. SimpleInstallFactory and ComplexInstallFactory) returned, you can still incorporate the singleton pattern as an access point and have an instance of a HashMap, store your instances of both factories.

What is Singleton Pattern? 

A singleton is a class that can be instantiated only one time. Repeated calls always return the same instance. Ensures that a class has only one instance, and provide a global point of access.

How to make responsive visualforce pages without using design frameworks

Clearly, crafting sites for optimal viewing and interaction experience is must. In salesforce (not lightning) I see there is big need for responsive pages. Quite often people use material design and bootstrap to achieve powerful UX/UI, but I do come across scenarios where people still want Salesforce layout on top of page and still want content to be quite responsive.

What is the problem in keeping header and sidebar active?

Leaving header and sidebar is old fashioned, yet you still need to meet many business case. Adding design framework makes it fairly easy to add responsiveness but other stylesheet override classes and you mess up side bar and header fairly easily.

Responsive Style Sheet 

Lets write our own css to add responsiveness and then design the style for our custom grid-pattern
In here, I added a wrapper class with row and defined coloumn of 10px to segregate the columns in the grid layout. Also I imported, material Roboto Font for my grid-content.

Media Support 

Now you notice here that

@media all and ( min-width: 300px)
This is the minimum width are placing for our media device width size, in other words if you device width is lower, you may break responsive behavior.

Defining Grid 

Grid is how you want to partition the page, very similar to material design and bootstrap and I simply breaking down page into 12 grid layout and defining styles to each grid layout

Resulting responsiveness (shown in codepen)

Now lets combine and style in a page see how it reflects in codepen, just shrink this codepen or blog page to see content in action

See the Pen Responsive Grid in HTML by Harshit Pandey (@oyecode) on CodePen.

Responsive Visualforce Template

Lets finish it up and responsiveness to Visualforce Page.

Download the code from here

Caveat with Sidebar/Header

Remember Salesforce standard-layout had @media responsive block size of width-600px. Once you squeeze your screen below 600px with sidebar/header on, you content will be in potential risk to break responsiveness.

Cloud9 Editor for Salesforce

Salesforce officially partnered with Cloud9 to produce a IDE dedicated for Salesforce Developer. This has been in talks for more than a year, but now its officially out for public. As we all know, Salesforce cloud based editor (developer console) is buggy, and do not synchronize/save code perfectly.

Cloud9 clearly offer better user experience to developer over developer console. Cloud9 have proven itself on many ground by offering support for multiple technologies and have more graduated offering. Clearly salesforce matches this model, at minimum on web level, this is significantly better

SOQL IN Cloud9

Query Editor is fairly simple and straight forward

Team Collaboration 

Not sure the use case behind this, but you can share your code live for online collaboration

Test Classes

Running test is on-click as it loads all tests

Aura Bundle (Lighting Component Bundle)

IDE supports aura (lightning) components and you can build lighting bundles like developer console

Linking your Github

You can fairly link Github repository with IDE, by linking with your repositories

What are the limitations ?

It is paid, pricy, do not see auto-suggestion and intelli-sense working smoothly as of now, no option to create new class/visualforce pages by right clicking. Not sure about logs view as of now and extra meta-data components besides the standard components and product little pricy for what it offers. May be this is early preview but overall richness of IDE makes it smoother than officially salesforce developer console

Try Cloud IDE for Salesforce at  https://get.c9.io/salesforce/