The Silver Lining

Lessons & Learnings from a salesforce certified technical architect.

Archive for the ‘Design’ Category

A Beginner’s Guide to Object-Oriented Programming with Apex: 2. Abstraction

with one comment

This is part 3 in the series “A Beginner’s Guide to Object-Oriented Programming with Apex” and will cover the aspect of Abstraction. For other posts in this series see the links below.

A Beginner’s Guide to Object-Oriented Programming with Apex

  1. Introduction
  2. Encapsulation
  3. Abstraction (this post)
  4. Polymorphism

What the hell is Abstraction?

Abstraction is a very interesting and surprisingly simple concept. At its core it’s about context and if Abstraction were a company it’s motto would be “Provide the right tools and data at the right time.”. There are many analogies in the “real world” e.g.

  • The Force.com Platform is an abstraction of the complex, underlying hardware and software that provides us with a simplified set of tools that can achieve the same level of benefit as those complex, underlying hardware and software!
  • A technical architect and developer both experience the creation of software but the developer’s perspective is far more detailed and requires different knowledge and tools. A technical architect has a different perspective and usually is not interested in the same information and tools that the developer needs. The detail of the developer’s work is abstracted from the technical architect although they will have a higher-level understanding of the same applications.
  • The driver of the car has a very different perspective (interface, information, goals, tools) than the engineer of the same car. Imagine if you had to know how all the parts of a car work together in order to drive! Those details are abstracted from the driver.

Where is this applicable to developers on the platform? Ever created a Visualforce component or Apex utility class? Well you my friend you are already using abstraction!

This sounds a lot like Encapsulation!

Abstraction and Encapsulation go hand in hand but they are different. Encapsulation is one of the ways you can achieve abstraction but does not encompass the entire concept. As stated previously Encapsulation is about hiding data and logic-implementations whereas Abstraction is described as providing the appropriate perspective to the appropriate consumer.

How do we Abstract?

There is a lot that is already abstracted on the platform e.g. 

  • The declarative features of the platform abstract the complexity that you would have to employ in order to replicate them through code.
  • The mechanisms for CRUD access to data are abstracted through SObjects (using a technique called ORM) in order to simplify this access.
  • Apex and Visualforce give you the ability to encapsulate and abstract complexity and expose this to consumers (other code and/orwebservices) through simplified interfaces.
    • These abstractions can be very sophisticated as has been shown several times on Andy Fawcett’s blog e.g. the domain, selector and service layer patterns in this repo provide patterns that allow the implementor to create simple mechanisms to connect and exercise complex logic. Those that use this logic need not be aware of the complexity contained beneath.

So how do you use abstraction? This is a topic that could take a year at University to teach but let me provide two examples, one simple and another more complex.

1. Simple Example

Calculating the area of a circle requires some specialised knowledge so you may want to create an abstraction of this calculation i.e. give other developers a way to calculate the area of a circle without having to know the actual calculation.

public Double calculateArea( Integer radius ) {

  return (radius)*(radius)*(Math.acos(-1)); // Pi = Math.acos(-1)

}

Obviously this is a very simple example but you could imagine a public method that is a lot more complex and whose inner workings you don’t really care to know too much about!

Note that this could also be used as an example of encapsulation! The difference however is that when considering this code as:

  • Encapsulation ~ we are hiding the implementation.
  • Abstraction ~ we are providing the appropriately simplified interface in order to access this functionality.

A subtle but important difference.

2. Complex Example

The complex examples considers a potential design pattern for your Apex code.

This example works at a higher level of abstraction than the previous one (pretty meta huh?) but the concept is similar. A developer creates a class (or set of classes) that contain all of complex business logic for the marketing department (this might be called your Service Layer if you were layering your application logic). This logic is then consumed by several other platform components such as trigger handlers, page controllers and bulk apex classes. The class methods and properties expose simplified interfaces to this logic and the details of the logic are abstracted from the consumers.

The benefit of abstraction here is that (in theory) you don’t need understand the details of the logic within the business logic classes you just need to understand their general purpose, know the method signature for the appropriate method and if necessary pass it the right data to get the expect result. And

Why Should I Use Abstraction?

If you’re a developer – much as with Encapsulation – you’ve probably been using Abstraction without even knowing it. The benefits are that by employing abstraction you’re making things easier for you and your team by presenting only the relevant information and tools at the appropriate time. This means a less confusing world, so less time is spent comprehending an application, fewer errors are made and everyone is happier.

Next time I’ll talk about my favourite part of these OOP principles, Polymorphism. It’s more than just a fun word to say!

Written by Wes

July 31, 2014 at 4:32 pm

Posted in Design, SalesForce

Tagged with , , ,

Across the Pond with Shannon Hale

leave a comment »

Shannon is Senior Product Manager for Declarative Apps at Salesforce.com

@abhinavguptas and I were curious as to the identity of the creator of the SetupScripter, which is now incorporated into the salesforce.com Org setup menu. I dug around a bit and managed to uncover her real identity – community please meet Shannon Hale, Shannon Hale this is the community. She didn’t just stop with that wonderful piece of UX but has moved onto bigger and better things, but I’ll let her tell you about those.

If you’d like to learn more about the genius that is Shannon or just have a chat with her you can get her on twitter at @shannonsans or @bathtubdreamer. You can also check out her online presence at shannonsansserif.com and bathtubdreamer.com.

Onto the Q&A!

Who is Shannon Hale? How did you get into software development and UX design?

I started out as a writer, but in a different field — I wrote and edited for some independent Canadian music and culture magazines. I started technical writing to help pay the bills, and from there wandered through a series of tech positions: technical training, systems analysis and design, and software development. In 2001 I became obsessed with why a product I was coding was difficult to use, and began to independently study interaction design and user experience.

When I’m not being a complete geek — which I am even at home, I always have personal and volunteer web projects going on — I’m sewing, knitting, or binding books. I’m one of those people who always needs to be doing something with their hands.

Read the rest of this entry »

Written by Wes

October 14, 2011 at 10:49 am

Cloud Computing – A Programmer’s Implementation of Hardware and Software Infrastructure?

with 5 comments

Geeks - so efficient even lunch only takes half the time.

Yes, it’s a sweeping statement, and the comparison I’ll make probably doesn’t fill every nook and cranny but it’s just so darn tasty that I had to quickly knock something out. I think that the developer collective have a massive influence over the direction of software evolution, and therefore it’s underlying technologies. In times gone past the influence probably wasn’t so large (or was it Mr Turing?), but with the rise and rise of the Socially Networked era I think the effect has snowballed.

So where is my justification? Well it lies primarily in anecdote – yes yes I hear your nerdy cries you sons & daughters of empirical science, but hear me out m’kay. We, the developers, spend probably more time online than even an opposite-sex obsessed teen does on facebook (yes, I know it’s part of the internet). We search and we scrounge, getting easily bored and looking for the next interesting tidbit, that scrap of information that will make us better programmers or just entertain us. We take the weak, inefficient and uninteresting and toss it aside while rolling The Good Stuff ™ into our work thereby influencing something as small as the font-family used in the corporate intranet, to something as grand as your start-ups Next Big Idea.

I’ve waxed lyrical but I’d like to get down-right specific. Some large parallels can be drawn between the world of OOP and the advent of Cloud Computing, and it is primarily for this reason that I suspect that some developers somewhere (past or present) were key in architecting what we today call Cloud Computing. OOP is by no means the alpha-and-omega of programming philosophy but it was a fundamental and incredibly intelligent paradigm shift – as is Cloud Computing. My comparison is made by drawing parallels with 2 of the main tenets of OOP.

Encapsulation

Encapsulation can be defined as an information hiding mechanism – and I don’t mean in a Wikileaks expose kind of way. Broadly this is described as:

the internal representation of an object is generally hidden from view outside of the object’s definition. Typically, only the object’s own methods can directly inspect or manipulate its fields.

To those familiar with Cloud Computing the correlation is immediately apparent. As a customer of Cloud XYZ I expect the provider to deal with all of the infrastructure setup and maintenance while providing interfaces that let me create applications or host servers or whatever. For example, if I’m using GAE I don’t really need to know how many servers you have or the amount of RAM that each has installed, I just need to know that I can develop, build, deploy and run my application and that it will scale well.

Cloud Computing hides the implementation of the tools that you need in order to complete development whilst providing interfaces to these tools that make this possible.

Abstraction

Single Rainbow! WHAT DOES IT MEAN?!

For those unfamiliar with the concept it can be quite… abstract. Examples always help:

Abstraction is simplifying complex reality by modelling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem.
For example, Lassie the Dog may be treated as a Dog much of the time, a Collie when necessary to access Collie-specific attributes or behaviors, and as an Animal (perhaps the parent class of Dog) when counting Timmy’s pets.

All of the clouds together i.e. all those platforms ending in “aaS” can be seen to form the highest level of abstraction. If you need a platform to host your Ruby applications then you’d starting shopping for a PaaS. Once your platform is chosen then you deal with the next layer of abstraction which might be concepts/requirements such as database space, CPU time and amount of RAM. The next layer might then be the application itself and so on and so forth.

Cloud Computing takes complex systems and breaks them into easy to digest chunks. By organising these into abstracted layers (imagine zoom-levels on a map) you can concentrate on, and understand, the level of information most applicable to your situation.

It is largely accepted that there are 2 more core principles of OOP namely Inheritance and Polymorphism. While parallels with Cloud Computing can be drawn for these two concepts I don’t think they’re as revolutionary as Encapsulation and Abstraction. Perhaps you disagree and if you do I’d love to hear your explanations.

So you’ve said some stuff and now I should believe you?

Of course not, but if you’re a developer I’m going to bet my bottom dollar (pound) that this makes sense to you; and not only does it make sense but you can see how big an improvement it really is. I have the utmost respect for those bigwigs in management as well as those well-dressed consultants, but for me I cannot see this type of vision being born anywhere else except in the mind of someone who’s gotten stuck into meaty application development and application architecture. Who ever it was, and where ever they may be, I salute them (live long and prosper).

Written by Wes

February 13, 2011 at 2:58 pm

Salesforce: Programmatically Populating Sample Data Post-Deployment

with 12 comments

I’m not sure if this concept is obvious when reading my previous post, so I thought I’d run through it with a specific example.

Rule one of packaging - Finish your bolognese first!

Let’s say that you’ve created what can only be described as an exemplary application in the form of a Managed Package. Although your user interface is beyond compare, you’d also like to populate some of your core objects with example data. Some options that immediately spring to mind are:

  1. Get the person that installs the package to call you, and you can do it post-installation.
  2. Get the person that installs the package to create sample data manually post-installation.
  3. Give the user a “Start Here” page with a call-to-action – such as a commandButton – that fetches the data from some API and parses into object data.

Option 3 is pretty excellent, especially now that you can package Remote Site Settings but I think we can do one better. And when I say better I mean simpler and with fewer potential points of failure. Read the rest of this entry »

Written by Wes

January 28, 2011 at 6:45 pm

Announcing the Salesforce Handbook

with 6 comments

Recently, Jeff Douglas and I saw the potential for a beginner’s book – aimed at business owners, analysts and developers, that comprehensively documents Salesforce and Force.com. There is a tonne of documentation out there and we thought “Wouldn’t it be nice to have a handbook that lightly summarised the most important areas of the platforms as well as offering some best practise advice”. We mulled it over for a time, and today we’d like to announce that we’re currently writing:

The Salesforce Handbook

A newcomer’s guide to building applications on Salesforce.com and the Force.com Platform.

Hand-in-hand with the book we’ll be publishing content from the book on a WordPress site. Here you can expect to find excerpts from the book, but also content that supplements the book e.g. areas that’ll serve as best-practice hubs with links to official documentation, blog posts that rock the party, and even superb discussion forum threads.

We’d love to get your feedback on the book as it progresses, but for now you can checkout the announcement and let us know what you think of the idea.

Friends Romans Country[wo]men

with 24 comments

In an attempt to attend DreamForce this year – I will conquer the Atlantic! – I’ve written up a white paper on a set of tools and workflows that I’ve found superb in more ways than one. I’d be happy & ecstatic(hapstatic?) if you could take a gander at my paper and, if it tickles your fancy, give it your vote. The idea itself describes the paper, but I failed to proof read it (and shock! Horror! There is no edit capability) so I’ll post a more refined version here,

Rapid application development is one of the strongest selling points of Salesforce and Force.com Platform; one that I’ve personally experienced time and time again. However, when it comes to translating that beautiful design document into a VisualForce interface, going from the design bits

The design document built from the 960.gs template

to a cross-browser, standards-compliant site prototype can be troublesome and often takes several days… and let’s be honest, potentially weeks. Read the rest of this entry »

Written by Wes

April 11, 2010 at 9:52 pm

Formatting – PageBlockSectionItem, InputField & OutPutField

with 4 comments

There are a collection of forum posts asking why VisualForce formatting isn’t being applied correctly to PageBlockSectionItems and/or InputFields, and the answer isn’t immediately obvious so let’s see what we can throw together. Read the rest of this entry »

Follow

Get every new post delivered to your Inbox.

Join 2,199 other followers

%d bloggers like this: