Force.com is a powerful platform, complete with a full-fledged programming language, Apex, on par with Java and C#. As a Force.com developer, it is important to understand when to turn to Apex, and what problems are best solved using programmatic solutions. This course delves into many different patterns and scenarios where using Apex is critical, including bulk processing, trigger patterns, wrappers and collections, and working with queues. With a good understanding of these patterns you will have the confidence to fearlessly go forth and develop industrial-strength applications on the Force.com platform.
Adam Purkiss is the Principal Architect at MondayCall Solutions in San Francisco. He spends most of his time designing and developing software in Apex and Visualforce and has been deeply involved in the Force.com community since 2008.
Introduction to Force.com Design Patterns Hi, this is Adam Purkiss with Plurasight. And I'd like to welcome you to Force. com Design Patterns. This course is intended for intermediate to advance developers who are experienced with object-oriented design and development. Prior Apex isn't required but concepts we'll be covering assume that you have at least an intermediate level of experience in language such as C#, Java, C++, or Object Pascal. If you're coming from a higher level language, such Python or Ruby, it may be helpful to review the differences between dynamically and statically typed languages before proceeding. Apex is a statically typed language that syntactically similar to Java with property similar to C# and is intended solely for use on the Force. com platform. Then we will be exploring other aspects of Force. com development including Visualforce. This course focuses primarily on object-oriented design patterns and Apex intended for actual use in production environments.
Wrappers and Collections Hi, this is Adam Purkiss with Pluralsight. In this section, we're going to take a look at the frequently used Apex wrapper class. We will explore some of the specific reasons that for Apex in particular, the wrapper class is an especially powerful and frequently employed design pattern. If you're coming from another object-oriented language such as C#, Java, Python, or Ruby, you're probably familiar with the concept. But just in case, here's an overview. A wrapper is simply an instance of a class that exposes some or all of the properties of a contained object, an object-oriented nomenclature. This would be considered a has-a relationship as opposed to being an is-a. An is-a is what you get when you subclass from or inherit from a parent class. A peach is a fruit for example. A has-a means having an instance of another class, my lunch has a peach.
Trigger Design Patterns So far we've seen wrappers and collections in action and explored some common bulk patterns you'll see frequently in Apex. Now, it's time to talk about Trigger Design Patterns and review some of the related best practices that have evolved over the years. As I've mentioned already in this course, code belongs in classes not triggers. Code that lives in triggers is not reusable, it can be harder to test and winds up being a longer sequential set of instructions than good programing practices would permit. Regardless of how you may have view govern our limits, remember that Apex is a powerful and truly object oriented language, it is architecturally similar to Java and should be treated as such. Because Apex has true interface support, the world of object oriented design patterns is wide open to you and this can be especially handy for trigger design.