Dummy objects are passed around but never actually used. Usually, they’re simply used to fill parameter lists.

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).

Stubs provide answers to calls made during the test, usually not responding to anything outside what’s programmed for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’ or only how many messages it ‘sent’.

Mocks are what we’re talking about here. Mocks are objects pre-programmed with expectations forming a specification of the calls they expect to receive.

But as with all things, first a bit of context.

The Agile Development Methodology

Agile is a software development methodology that borrows from Scrum (opens in a new window) project management practices, Extreme Programming (opens in a new window) (XP), and Test Driven Development (opens in a new window) (TDD).

It’s not my intention to write about Scrum, XP, and TDD in excruciating detail since there are many excellent books on these subjects. I would, however, like to share my view on why TDD is foundational to any software engineering effort.

Scrum

As most are aware, Scrum is an iterative, incremental framework for managing complex work and though intended for management of software development projects, it can be used as a general program management approach. Contrary to popular belief, however, Scrum is not an acronym. First used to describe hyper-productive development in 1987 by Ikujiro Nonaka (opens in a new window) and Hirotaka Takeuchi (opens in a new window) , Scrum actually refers to the mechanism used in rugby for getting an out-of-play ball back into play.

Many software engineering teams still practice the Waterfall development methodology and for some projects – in particular when requirements are static and rarely change – it’s an appropriate practice. The building of a jet propulsion engine is a good example of a project that likely benefits from the Waterfall development methodology. In contrast, Scrum’s two pillars are team empowerment and adaptability:

1. Team empowerment: Once teams are given work to do, they are responsible for figuring out how to do it. The team does the best it can during each iteration. While a team works, their only interaction with management is to tell management what is getting in their way and needs to be removed to improve their productivity.

2. Adaptability: Scrum uses “punctuated equilibrium”. The team maintains an equilibrium during each iteration, insulated from outside disturbance. Iteration are generally punctuated every thirty days so that the team and management can evaluate what should be done during the next iteration; this decision is based on what the team has accomplished and what the environment dictates is the next most important thing to do.

Velocity

It’s difficult to discuss the importance of writing tests without first discussing the notion of velocity and while I could write a dissertation just on the notion of velocity, it is simply defined as how many story points of effort a team can complete in a single iteration. Once established, velocity can be used to plan projects and forecast release and product completion dates. A team’s velocity is an important key performance indicator.

eXtreme Programming

From XP, we borrow pair programming and continuous integration. Code reviews are good so let’s do them all the time; this is pair programming. Measuring code quality and ensuring a source level change didn’t cause any regressions is good so let’s do it as often as possible; continuous integration.

It should be no surprise that writing automated tests and measuring code coverage go hand-in-hand with continuous integration.

Test-Driven Development

For any particular software engineering effort, there are three axes to control: quality, schedule, and scope. Quality remains locked at “high” and so the engineering team must choose how to balance the remaining two.

Clean code that works…now. This is the seeming contradiction that lies behind much of the pain of programming. Test driven development replies to this contradiction with a paradox – test the program before you write it.

• Test Driven Development: By Example, 2002

Regardless of your development methodology, writing tests are important. Automated testing underpins many Agile practices, most significantly as part of Continuous Integration (opens in a new window) . TDD is a process by which the tests are written before the code itself. Through a rapid cycle of adding new tests, making them pass, and then refactoring to clean code, the software design evolves through the tests.

Red, Green, Refactor

When a test is first written, it most likely won’t even compile - the implementation hasn’t been written. Modern IDEs allow a developer to rapidly create code and then refactor it into shape. After adding a test, a developer strives to reach a “green bar” (all tests passing) as quickly as possible, and then refactors backed up by the safety of the tests. This quickly becomes a cycle of “red, green, refactor”, adding a kind of rhythm to the development process. When a new feature is required, tests are added, code is written to make the tests pass, and finally refactoring removes any duplication.

Benefits of Writing Tests

Whether your project is open source, commercial, or corporate, there are clear and important advantages to writing automated tests.

1. Courage. Writing tests allows one to move from a state of uncertainty to that of courage. When you write tests, you know the state of the your code. Intimately. You know if your code works or if it doesn’t. You know if your old code, and the code of your colleagues works as expected.
2. Communication. Tests can also be used for communication. This works well to communicate what the software does. We all may not know how to speak the same language but as a member of a particular software engineering team, we all know how to communicate using a specific programming language. We all can read and write code with good clarity.
3. Documentation. Beyond shore-to-shore communication, tests also make a good candidate to use as examples in documentation and in comments.
4. Refactoring. Setting your minimum allowable test coverage percentage to a respectable number (90 percent and greater) allows you to refactor your source code with confidence. Use cases pivot. You refactor the code. Then simply make all failing tests pass again.
5. Design. Writing tests first leads to a better design.
   1. It forces you to think about the shape of your API up front; to really understand how your consumer uses the API before you spend valuable time writing the implementation.
   2. It allows you to understand any possible frustrations and complexities with the shape of your API before your consumer.
   3. It saves time by ensuring the API satisfies your design goals and nothing more.

All of these points are critical to a team’s velocity.

Rules of Engagement

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC-2119 (opens in a new window) .

In the end, automated tests are just code. Even with best intentions, they can be written incorrectly and contain bugs. Here are a few rules to consider.

1. Keep unit tests small and fast. Ideally the entire test suite SHOULD be executed before every code check in. Keeping the tests fast reduce the development turnaround time.
2. Tests MUST be fully automated and non-interactive.
3. Keep tests independent. To ensure testing robustness and simplify maintenance, tests SHALL NOT rely on other tests and SHALL NOT depend on the order in which other tests are executed.
4. A test MUST leave the environment exactly as it was before execution began. This is an extremely important point since test execution order is never guaranteed and so environmental changes may cause sporadic test failures, which can waste precious time.
5. A test MUST contain at least one assertion.
6. A test MUST contain 3 logical sections: arrange, act, and assert.
7. A test MUST cover boundary cases.
8. A test fixture MUST provide negative tests. Negative tests intentionally misuse the code and verify robustness and appropriate error handling.
9. Write tests to reproduce bugs. When a bug is reported, write a test to reproduce the bug (i.e. a failing test) and use this test as success criteria when fixing the code.
10. Conduct peer code reviews (opens in a new window) on all tests.

Regarding bullet 6, William C. Wake wrote about (opens in a new window) using the “arrange, act, assert” pattern in 2003. Here’s a summary:

• Arrange: What is being set up and initialized is contained in the arrange section.
• Act: What method is being executed is contained in the act section
• Assert: What determines the outcome of the test is in the the assert section.

I’ll write about dummies, mocks, stubs, and fakes in a future post.

Conclusion

With test-driven development, robust code is delivered along with a comprehensive suite of tests, allowing developers to make future changes with confidence. I firmly believe that unless you’ve been a contributing member of a software team responsible for a complex code base that it may be difficult to appreciate the critical importance of having a suite of automated unit, integration, and story tests.

Move away from a position of uncertainty to one of confidence. Write tests.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. – C.A.R. Hoare

Mobile, cloud, social, and non-relational storage technologies (big data) represent agility for many businesses. In particular, the convergence of these technologies equip businesses with efficient methods to attribute key performance indicators, optimize direction, and, equally as important, allocate changes in business processes; all in real-time and for a vast array of incoming data formats. Individually, each of these technology areas are immense and yet are enablers for each other; and so in early 2008, I began to focus my attention, application of algorithms, and research to the convergence of these technologies.

The technology shifts created by mobile, cloud, social, and big data have changed and are drastically changing the business landscape. The convergence of these technologies began years ago and has matured considerably since 2008. Social media has contributed to this significantly. Big Table (opens in a new window) and, subsequently, HBase (opens in a new window) was born out of need within Google and the open source community, respectively. The Apache Cassandra (opens in a new window) project was born out of need within Facebook. We’re able to learn interesting statistics like the half-life of links shared on Twitter is approximately 2.8 hours, sports stories spread the fastest of any topics, and there’s a material difference between what people share and what they click. From a sales and marketing perspective, we can use big data to better leverage social channels to rapidly detect changes in buyer activities and preferences, identify market shifts, monitor competitive activity, and identify opportunities for your business. Social media is analyzed to understand behavior, although it’s important to remember as with all population sampling, it only provides a specialized subset of opinions about a particular topic.

Big Data and Analytics

Big Data is primarily classified by the use of non-relational durable storage solutions that embrace the following characteristics of information technology.

• Volume. As of 2012, about 2.5 exabytes of data are created each day, and that number is doubling every 40 months or so. More data cross the internet every second than were stored in the entire internet just 20 years ago. For example, it is estimated that Wal Mart collects more than 2.5 petabytes (opens in a new window) of data every hour from its customer transactions.
• Velocity. For many applications, the speed of data creation is more important than the volume. Real-time or nearly real time information makes it possible for a company to be much more agile than its competitors. Just consider the speed at which information is collected from the sheer number of active mobile devices each and every day.
• Variety. Information now flows from a plethora of sources in the form of messages, updates, and images from social networks; electronic communication; instrumented machinery; readings from sensors; GPS signals from mobile phones; point of sale terminals; and so on. Structured databases are not well suited to storing and processing information from these disparate sources.

…and it’s only becoming even more challenging. Each and every day, three times per second, we produce the equivalent of the amount of data that the Library of Congress has in its entire print collection. Most of the data produced is irrelevant noise. Clearly, the challenge is in filtering this noise and distilling the remaining information into meaningful results. This vast amount of information is essentially useless without analytics. Timely analytics. Accurate analytics. Technical solutions in this space must be able to traverse multiple data centers, the cloud, and geographical zones. Accurate, real-time analysis affords us an opportunity to answer crucial business questions by those wanting to confidently pivot in response to key performance indicators (KPI).

Before you delve into the non-relational storage arena, it’s important to understand the CAP theorem (opens in a new window) . The theorem began as a conjecture made by University of California, Berkeley computer scientist Eric Brewer (opens in a new window) at the 2000 Symposium on Principles of Distributed Computing (PODC). In 2002, Seth Gilbert and Nancy Lynch of MIT (opens in a new window) published a formal proof of Brewer’s conjecture, rendering it a theorem.

Formally, in theoretical computer science, the CAP theorem states that it is impossible for a distributed computer system to simultaneously satisfy all three of the following characteristics:

1. Consistency. All nodes possess the same data at the same time.
2. Availability. A guarantee the system is available at all times to fully operate.
3. Partition tolerance. The system continues to operate despite arbitrary message loss or failure of part of the system.

In May 2012, Brewer clarified some of his positions (opens in a new window) on why the oft-used “two out of three” concept can be misleading or misapplied.

Broadly speaking, durable storage technologies are divided into two innate categories: relational and non-relational. Relational databases have been widely used for the past 40 years and are still quite widely used today. Microsoft SQL Server, IBM DB2, Oracle, and MySQL are all examples of relational database implementations. Suffice it to say most non-relational database system architectures favor partition tolerance and availability over strong consistency. Other implementations such as Cassandra (opens in a new window) offer per-operation control over which two characteristics of the CAP theorem you would like to favor. My favorite distribution of Cassandra is DataStax (opens in a new window) , which combines Cassandra, Hadoop (opens in a new window) , and SOLR (opens in a new window) into a single packaged distribution. Their enterprise edition (opens in a new window) is free to developers, which is convenient.

With respect to non-relational databases, one must consider a few orientations.

• Object. Object databases work to void object-relational impedance mismatch that occurs when trying to use a relational database under an application written in an object-oriented programming language. These databases store information in terms of the object themselves and not in terms of columns and rows.
• XML. XML databases are optimized specifically for working with XML and are, essentially, a special form of a document-oriented database. XML databases have one core function: to allow for efficient storage and query of XML documents. Examples of XML databases are Tamino (opens in a new window) (Software AG), eXist (opens in a new window) , Berkeley XML DB (opens in a new window) (Oracle), MarkLogic (opens in a new window) Server, and Sedna (opens in a new window) .
• Document. The basic unit or storage for a document database is a complete document. CouchDB (opens in a new window) and MongoDB (opens in a new window) are examples of document databases. This storage model offers several key advantages over a relational model:
  • A document can store any number of fields of any length, and each field can store multiple values. A relational model requires all fields to be present for every record.
  • An empty (or null) value (and the related field) does not need to be stored, which can save space. On a related note, many relational databases currently offer support for sparse tables.
  • Full text search capabilities are typically an intrinsic feature.
  • Security can be assigned at an individual document level.
  • A predefined schema is not required whereas a relational database does require schema to be defined in advance of performing any storage or retrieval operation.
• Key-Value. A key/value database stores values based on keys and are classically represented as a Distributed Hashtable (DHT). In a relational model, we tend to first consider the tables that our domain requires, then think of how we can normalize the tables to avoid duplicate data. In a key-value store, however, typically we don’t define a schema. Examples of key-value databases are MongoDB (opens in a new window) , Redis (opens in a new window) , Amazon Dynamo (opens in a new window) , and Project Voldemort (opens in a new window) .
• Graph. Graph databases differ from other non-relational database offerings (such as key-value stores) in that they represent the edge intrinsically. Instead of tables and columns, a graph database uses three basic constructs to represent data: nodes, edges, and properties. A node is a standalone, independent object. An edge is an object that depends on the existence of two nodes. Properties represent attributes of a node. Examples of graph databases are FlockDB (opens in a new window) (open sourced by Twitter in April 2010) and Neo4J (opens in a new window) .
• Columnar. A columnar database organizes data around columns instead of rows. This subtle difference optimizes some workloads—in particular, data warehouse and analytics applications that require computing aggregate values over very large sets of data—for certain kinds of problems. Databases that follow this orientation represent distributed hash tables ( DHTs ). Examples of columnar databases are Cassandra (opens in a new window) , Google Bigtable (opens in a new window) , HBase (opens in a new window) , and Hypertable (opens in a new window) .

It’s worth noting, a few databases exist that represent hybrid orientation implementations; for example, Riak (opens in a new window) is a hybrid implementation based on Amazon’s Dynamo in that it is both a document-oriented and key-value implementation.

Though, just as with relational databases, planning is key when thinking about launching a non-relational database project. Non-relational database projects require a slightly different software engineering approach. In a relational model, we tend to consider our data model first and then we build queries to satisfy application requirements. Even though a database may be schema-less, in a non-relational model we MUST (opens in a new window) first understand an application’s queries as a starting point since that influences database and table layout.

Even companies with a large investment in relational-based analytics tools can leverage non-relational storage technologies but even so, the definition of a taxonomy (or multiple taxonomies) for analytics processing is of paramount importance. Typically, companies that are heavily invested in relational technology as their primary systems of record employ extract transform and load (ETL) processes to periodically restructure information based on defined taxonomies into non-relational storage products so they are able to take advantage of more efficient and real-time processing using massively parallel analytics technologies such as Hadoop and Map Reduce.

Capturing data without analytics in mind from a business’ point of view is generally moot. Consider the goals, and what key data sets are needed to reach those goals. More important is to consider the set of business questions you are attempting to answer and, to that point, I strongly recommend you bring in a data scientist to perform an audit of an existing data architecture.

Mobile

Business-to-consumer (B2C) mobile applications impose different requirements than that of business-to-business (B2B) and corporate applications not only in terms of marketing but in terms of the requirement for an extremely efficient and aesthetically pleasant user experience (UX) and more stringent software engineering practices. It’s very difficult to recover from poor reviews and customer feedback.

In the mobile space, three companies represent the majority globally: Apple, Google, and Microsoft. Apple and Google make up 96% of the entire mobile space. Microsoft is less than 1% with the remaining (just over 3%) still on others such as RIM, Symbian, etc. If we add tablets to the equation (so now not just mobile phones) then as of April 2013 Apple iOS represents 59.04%, Google Android represents 26.02%, and Microsoft Windows Phone represents 1.14%; see Net Marketshare (opens in a new window) .

Across all mobile operating systems, if you observe how people use smartphones and look beyond telephone calls, email, and texting then you’ll see that native applications dominate. Users spend on average, 82% of their mobile minutes with native applications and 18% with web browsers. They download approximately 50 to 75 applications to their phones (out of more than a million available) but regularly use about 10.

As another data point, mobile applications broadly fall into six categories:

1. Games and Entertainment
2. Social Networks ( FaceBook (opens in a new window) , Twitter (opens in a new window) , Pinterest (opens in a new window) , Path (opens in a new window) , Tumblr (opens in a new window) , etc)
3. Utilities (maps, clocks, calendars, cameras, email, etc.)
4. Discovery ( Yelp (opens in a new window) , GrubHub (opens in a new window) , etc.)
5. Education ( AccelaStudy (opens in a new window) , Contig (opens in a new window) , Flashcard Champion (opens in a new window) , etc.)
6. Brands ( Nike (opens in a new window) , Red Bull (opens in a new window) , etc.)

Regardless of your application’s category, native mobile applications offer the absolute best user experience in many aspects with frame rates, offline support, and access to the device’s hardware to name but a few. Contrary to what some may espouse, mobile devices are not well connected; even within major United States and European cities where connectivity is commonly sporadic and network latency is commonly high. Consider many scenarios whereby consumers pass in and out of good network connectivity while on mass transit systems; even mobile applications that “think” they are connected to a hi-fidelity wireless network may really be connected to a personal hotspot that is in turn connected to the internet over a cellular channel. It is for these reasons I strongly discourage the creation of hybrid and HTML 5 mobile applications. Granted, hybrid and HTML 5 mobile applications may prove satisfactory in some corporate settings but if you want your application to be among the 10 regularly used ones then write native applications; it’s that simple. And for the record, I am not a fan of “ 4GL (opens in a new window) ” Integrated Development Environments (IDE) that generate code for multiple mobile platforms. Perhaps I am a purist but I prefer to have direct access to and control over the core mobile platform rather than having to interact with process and technical abstractions. Your consumers do appreciate this level of attention to detail and UX refinement.

If you do write applications in the consumer space and if you’ve purchased a smartphone or tablet recently, and if it doesn’t have an Apple logo on it then it’s likely you already know of Android. Android is an open sourced Linux-based operating system (OS) launched approximately 5 years ago as of the time of this writing. The Android operating system dates back to 2003 when Rich Milner, Nick Sears, Chris White, and Andy Rubin began working on a mobile operating system, which Google would eventually purchase in 2005.

For years, the dominant OS was Symbian, which has its roots in Psion’s EPOC (opens in a new window) OS. By 2007, Symbian accounted for over 63% of the worldwide smartphone market. However, by 2008, when it was purchased by Nokia, that number dropped to 52%. At that time, the closest competitors were Research in Motion’s Blackberry OS (16.6%), Microsoft Windows Mobile (11.8%), and the still very new iOS (8.2%). With Nokia’s OS was poorly equipped to compete with iOS, RIM not wanting to leave its business focus comfort zone and Microsoft’s mobile attempts clearly failing, it was Google’s purchase of Android Inc in 2005 that would eventually provide competition. The Linux-based, open-source mobile operating system would eventually find its way to the market with the release of the T-Mobile G1 in 2008. The G1 sold well and that elevated Android to reach a 3.9% share in the smartphone market in 2009. At this point, iOS had doubled its share to 14.4%, RIM grew to just under 20%, Windows Mobile had dropped to 8.7%, and Symbian correspondingly dropped to 46.9%. Today, Android is used in 61% of the smartphones (excluding tablets) sold worldwide, which is primarily attributed to the fact it can be found in both high-end handsets (targeting the Apple iPhone) and in lower budget smartphones (where Symbian once dominated). Apple iOS commands 20.5% of the worldwide smartphone marketshare, which is impressive considering it’s only included in Apple’s own high-end phones. RIM is now down to less than 1.5%.

In general, it’s easier to get an application released onto Android, but from technical engineering and business points of view, Android does have significant disadvantages over Apple’s iOS:

• Google Play is not nearly as mature as Apple’s AppStore
• People are reluctant to pay for Android applications
• Piracy of applications is widespread
• Security concerns and malware
• Little to no enterprise penetration
• OS upgrades are cumbersome, slow, and generally require intervention by the carrier

However, one can’t ignore Android these days; and in particular for the consumer space. Corporate and business applications are a different matter altogether and I’ll save that discussion for a later point in time time.

Cloud

So, where does cloud technology fit into all of this? Everywhere. Cloud is the cohesive technology between mobile, social, and big data. Over the past nearly 6 years, and after nearly 500 mobile applications shipped, I can think of exactly one mobile application I’ve written that did not involve hosted cloud services; and cloud providers are only getting better. Cloud providers such as Amazon AWS (opens in a new window) and Microsoft Windows Azure (opens in a new window) provide full featured platform-as-a-service (PaaS) and infrastructure-as-a-service (IaaS) offerings that complement solutions spanning the mobile, social, and non-relational database solution domains. There are other providers such as Linode (opens in a new window) that offer competitive IaaS offerings and with a very approachable cost model. Discussing the technical offering of each cloud provider is not in scope of this post; perhaps at a later point in time.

The use of cloud computing technologies offer companies an opportunity to recognize cost savings that would otherwise not be possible with on-premise hardware. For example, it’s not uncommon to develop scripts that create an environment starting with mere credentials to a fully functioning application stack in a matter of minutes only to tear it down once the day is over. Patterns such as this are quite attractive to stakeholders.

Conclusion

For organizations seeking a fast, easy and cost-effective way to manage business operations, the convergence of mobile, cloud, social, and non-relational storage technologies equips parallel and distributed system designers and business stakeholders with a unique opportunity and insight into new patterns that would otherwise require a much higher degree of cooperation and effort among disperate teams. an architecture that seeks signals, models them for their impact, and then adapts to the business process of the organization. These technologies also facilitate pattern-based strategy architectures, which are attractive to both technical architects and business stakeholders. A pattern-based strategy identifies signals, models them for their impact, and then adapts to the business process of the organization instead of current strategies defined by making hypotheses, performing analyses, and reaching conclusions that are often wrong given the time to implement the change and pivot occurs at a slower pace than the tracked market trends.

Good architectures don’t just happen, they are designed.

References:

• Andrew McAfee and Erik Brynjolfsson. “Big Data: The Management Revolution”. Harvard Business Review, October 2012.

Additionally, iOS 5 introduces a new compile-time memory management feature known as Automatic Reference Counting (ARC) (opens in a new window) . The abridged version is you will never need to type retain or release again, which dramatically simplifies the development process while reducing crashes and memory leaks. The compiler has a complete understanding of your objects, and releases each object the instant it is no longer used, so apps execute much faster, with predictable, smooth performance. However, it’ll take the community some time to refactor various open source libraries to support ARC. Therefore, we have a much larger need today than ever before to move these source files into static libraries that are compiled with ARC disabled so we can compile our primary applications with ARC enabled.

Alternatively, if you are including files that don’t yet support ARC in a project that is ARC enabled, you can set the -fno-objc-arc compiler flag for each of these files. To do this in Xcode, go to your active target and select the “Build Phases” tab. In the “Compiler Flags” column, set -fno-objc-arc for each of the source files. Of course, this can be a very laborious process.

Apple defines a framework (opens in a new window) as a bundle (a structured directory) that contains a dynamic shared library along with associated resources, such as nib files, image files, and header files. When you develop an application, your project links to one or more frameworks. For example, iOS application projects link by default to the Foundation, UIKit, and Core Graphics frameworks. Your code accesses the capabilities of a framework through the application programming interface (API), which is published by the framework through its header files. Because the library is dynamically shared, multiple applications can access the framework code and resources simultaneously. The system loads the code and resources of a framework into memory, as needed, and shares the one copy of a resource among all applications. A universal (or multi-architecture) file is nothing more than an application bundle.

As I mentioned above, iOS does not support dynamic shared libraries but using lipo (opens in a new window) (a tool which comes with iOS SDK (opens in a new window) ) we are able to merge several static libraries into a single static library. By using lipo, we are able to create a static library that supports all architectures (armv6, armv7, and i386) packaged as a universal framework. Here’s how.

Within Xcode, either create a new iOS project or open an existing iOS project. If you do decide to create a new project then feel free to choose any application template you prefer. Which one you choose is irrelevant. Add a “Cocoa Bundle” target (not Cocoa Touch Bundle). Select the newly created bundle target in the left navigation panel, select the “Build Settings” tab and modify the following settings (opens in a new window) as required:

• Architectures (ARCHS): Standard (armv6 armv7 armv7s). In Xcode 4.2, use the value of $(ARCHS_STANDARD_32_BIT). If you wish to compile for older devices then add a new line with a value of armv6. Please see this (opens in a new window) Apple Developer forum post for more details.
• Base SDK (SDKROOT). Latest iOS (iOS X.X).
• Build Active Architecture Only (ONLY_ACTIVE_ARCH). No. This allows us to compile for armv6 and armv7.
• Valid Architecture (VALID_ARCHS): Standard (armv6 armv7 armv7s). In Xcode 4.2 and greater, use the value of $(ARCHS_STANDARD_32_BIT). If you wish to compile for older devices then add a new line with a value of armv6.
• Dead Code Stripping (DEAD_CODE_STRIPPING): No
• Link With Standard Libraries (LINK_WITH_STANDARD_LIBRARIES): No
• Mach-O Type (MACH_O_TYPE): Relocatable Object File. This is the most important change. Here, we instruct the compiler to treat the Bundle as a relocatable file, by doing this, we can turn it into a framework with the wrapper setting.
• Wrapper Extension (WRAPPER_EXTENSION). framework. Here we change the Bundle to a Framework. To Xcode, frameworks is just a folder with the extension .framework, which has inside one or more compiled binary sources, resources and some folders, a folder, usually called Headers, contains all the public headers.
• Generate Debug Symbols (GCC_GENERATE_DEBUGGING_SYMBOLS): No.
• Generate Position-Dependent Code (GCC_DYNAMIC_NO_PIC): No
• Targeted Device Family (TARGETED_DEVICE_FAMILY). iPhone/iPad.

Here are the steps…

• With the bundle target still in focus, select the “Info” tab and ensure the “Bundle OS Type code” is equal to FMWK.
• Add any source code and resources to the bundle. With the bundle target selected, click the “Build Phase” tab. At the bottom, press the “Add Phase” button and then “Add Copy Headers“.
• Open the newly created “Copy Headers” section and separate your public headers from private or project headers.
• Open the “Compile Source” section and add any .m, .c, .mm, .cpp and any other compilable source file. If your framework contains any non-compilable files such as images, sounds, and other resources, you can add them to the “Copy Bundle Resources” section.

You can access any non-compilable resources by using NSBundle.

[[NSBundle mainBundle] pathForResource:@"MyFramework.framework/Resources/FileName" ofType:@"fileExtension"];

Next we’ll create a new Aggregate Target. As mentioned earlier, to join both architectures products into one, we must to use lipo.

• Add a new target by pressing the “Add Target” button.
• Under the Cocoa Touch section, select the “Other” subcategory and then choose the “Aggregate” target. The “Product Name” is arbitrary.
• Add a new “Run Script” phase under this newly created target. Copy and paste the following script into the “Run Script” phase.

# The framework name and version
X_FRAMEWORK_NAME=CoreFramework
X_FRAMEWORK_VERSION=A

# This folder contains the final output of the framework.
X_INSTALL_DIR=${SRCROOT}/Products/${X_FRAMEWORK_NAME}.framework

# This working directory will be deleted after completion.
X_WORKING_DIR=build
X_DEVICE_DIR=${X_WORKING_DIR}/${CONFIGURATION}-iphoneos/${X_FRAMEWORK_NAME}.framework
X_SIMULATOR_DIR=${X_WORKING_DIR}/${CONFIGURATION}-iphonesimulator/${X_FRAMEWORK_NAME}.framework

echo "******************************************************"
echo "X_DEVICE_DIR = ${X_DEVICE_DIR}"
echo "X_SIMULATOR_DIR = ${X_SIMULATOR_DIR}"
echo "******************************************************"
echo "SYMROOT = ${SYMROOT}"
echo "OBJROOT = ${OBJROOT}"
echo "PROJECT_DIR = ${PROJECT_DIR}"
echo "CONFIGURATION_BUILD_DIR = ${CONFIGURATION_BUILD_DIR}"
echo "CONFIGURATION = ${CONFIGURATION}"
echo "CONFIGURATION_TEMP_DIR = ${CONFIGURATION_TEMP_DIR}"
echo "DERIVED_FILE_DIR = ${DERIVED_FILE_DIR}"
echo "BUILD_PRODUCTS_DIR = ${BUILT_PRODUCTS_DIR}"
echo "BUILD_DIR = ${BUILD_DIR}"
echo "TARGET_TEMP_DIR = ${TARGET_TEMP_DIR}"
echo "PROJECT_TEMP_DIR = ${PROJECT_TEMP_DIR}"
echo "PRODUCT_NAME = ${PRODUCT_NAME}"
echo "******************************************************"

# Build both simulator and device architectures.
xcodebuild clean
xcodebuild -configuration ${CONFIGURATION} -target "${X_FRAMEWORK_NAME}" -sdk iphoneos -SYMROOT=${SYMROOT} -OBJROOT=${OBJROOT}
xcodebuild -configuration ${CONFIGURATION} -target "${X_FRAMEWORK_NAME}" -sdk iphonesimulator -SYMROOT=${SYMROOT} -OBJROOT=${OBJROOT}

# Clean the oldest.
if [ -d "${X_INSTALL_DIR}" ]
then
rm -rf "${X_INSTALL_DIR}"
fi

# Recreate the folder structure for the final product binaries.
mkdir -p "${X_INSTALL_DIR}"
mkdir -p "${X_INSTALL_DIR}/Versions"
mkdir -p "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}"
mkdir -p "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/Resources"
mkdir -p "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/Headers"

# Create the required symbolic links. Please note the paths MUST relative, 
# otherwise the symbolic links will be invalid when the folder is copied/moved.
ln -s "${X_FRAMEWORK_VERSION}" "${X_INSTALL_DIR}/Versions/Current"
ln -s "Versions/Current/Headers" "${X_INSTALL_DIR}/Headers"
ln -s "Versions/Current/Resources" "${X_INSTALL_DIR}/Resources"
ln -s "Versions/Current/${X_FRAMEWORK_NAME}" "${X_INSTALL_DIR}/${X_FRAMEWORK_NAME}"

# Copy the headers and resources files to the final product folder.
cp -R "${X_DEVICE_DIR}/Headers/" "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/Headers/"
cp -R "${X_DEVICE_DIR}/" "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/Resources/"

# Remove artifacts from the resources folder.
rm -r "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/Resources/Headers" "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/Resources/${X_FRAMEWORK_NAME}"

# Use lipo to merge both binary files (i386 + armv6/armv7) into one universal files.
lipo -create "${X_DEVICE_DIR}/${X_FRAMEWORK_NAME}" "${X_SIMULATOR_DIR}/${X_FRAMEWORK_NAME}" -output "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/${X_FRAMEWORK_NAME}"

# Remove the working directory
rm -r "${X_WORKING_DIR}"

You’ll need to modify the first non-comment line in the script to be equal to the product name of your framework bundle target.

Now build the Aggregate target. It does not matter which architecture you select to build (iOS Device or Simulator) since the script creates a working folder, compiles the framework target twice (once for the iOS device and once for the iOS Simulator) and generates the output to a folder named “Products” located in the $(SRCROOT) root folder

If you previously upgraded from Xcode 3.x to 4.2, then your existing (SYMROOT) value will very likely cause the above script to fail. The failure is caused because the script expects your (SYMROOT) value to be set to the new Xcode 4 value of “build”, which refers to a relative path to $(SRCROOT). Unfortunately, you are not able to modify this setting in Xcode 4 due to an already reported bug. To work around this bug, close Xcode and simply delete the existing SYMROOT key and value from your com.apple.dt.Xcode.plist file, which is located in ~/Library/Preferences/.

Isn’t it about time for the WWDC to be here again?

I suggest reading Apple’s Thread Programming Guide (opens in a new window) as a prerequisite, which also covers some of the basic concepts behind Blocks and Grand Central Dispatch (GCD) (opens in a new window) .

Singletons

For purposes of this discussion, a singleton is a class that only allows a single instance of itself to be created within an operating system process.

Apple’s documentation (opens in a new window) on creating a singleton recommends a pattern that works for most iOS applications but is not thread-safe. Beginning with iOS 2.0 and prior to iOS 4.1, one of the most widely used methods to introduce a thread-safe singleton was through the use of the @synchronized (opens in a new window) directive.

+ (MyClass*) instance {
    static MyClass *gInstance = nil;
    @synchronized(self) {
        if(nil == gInstance) {
            gInstance = [[MyClass alloc] init];
        }
    }
    return (gInstance);
}

There are a few inefficiencies with this approach because not only generates a recursive mutex lock but also introduces an exception handler. Specifically, Apple’s documentation indicates that as a precautionary measure, the @synchronized block implicitly adds an exception handler to the protected code. This handler automatically releases the mutex in the event that an exception is thrown. This means that in order to use the @synchronized directive, you must also enable Objective-C exception handling in your code. If you do not want the additional overhead caused by the implicit exception handler, you should consider using the lock classes.

At the time of this writing, the @synchronized directive turns into this basic pseudo-code:

id _eval_once = ;
objc_sync_enter( _eval_once );
@try {
    /* code goes here */
}
@finally {
    objc_sync_exit( _eval_once );
}

For implementation details see: http://www.opensource.apple.com/source/objc4/objc4-437.1/runtime/objc-sync.m (opens in a new window)

Much of Apple’s sample code prior to iOS 4.0 use this approach. There is a technically more efficient and lock-free approach for applications that target operating systems earlier than Mac OS X version 10.5 or iOS 4.0.

+ (MyClass*) gInstance {
    static void * volatile gInstance = nil;
    while (!gInstance) {
        MyClass *temp = [MyClass [alloc] init];
        if(!OSAtomicCompareAndSwapPtrBarrier(0x0, temp, &gInstance)) {
            [temp release];
        }
    }
    return (gInstance);
}

You can read more about preferred versions of the atomic and synchronization operations here (opens in a new window) .

For applications that target operating systems equal to or greater than Mac OS X 10.6 or iOS 4.0, the recommended singleton pattern uses dispatch_once, which relies on components of Grand Central Dispatch (GCD).

+ (MyClass *) instance {
    static MyClass* gInstance = nil;
    static dispatch_once_t pred;
 
    dispatch_once(&pred, ^{
        gInstance = [[MyClass alloc] init];
    });
    return (gInstance);
}

It should go without saying but I’ll do so for completeness. All instance-level methods of classes that implement a singleton pattern MUST (opens in a new window) be thread-safe.

NSCache

I suspect this class remains relatively unused by most iOS developers. NSCache (opens in a new window) is essentially a container that it stores key-value pairs but unfortunately does so without an O(1) time complexity (like that of NSMutableDictionary (opens in a new window) ) but does automatically evicts objects from its store when the ‘cost’ (a heuristic that of course involves memory pressure) of the cache rises above a configurable threshold.

Per Apple’s documentation, NSCache objects differ from other mutable collections in a few ways:

• The NSCache class incorporates various auto-removal policies, which ensure that it does not use too much of the system’s memory. The system automatically carries out these policies if memory is needed by other applications. When invoked, these policies remove some items from the cache, minimizing its memory footprint.
• You can add, remove, and query items in the cache from different threads without having to lock the cache yourself.
• Retrieving something from an NSCache object returns an autoreleased result.
• Unlike an NSMutableDictionary object, a cache does not copy the key objects that are put into it.These features are necessary for the NSCache class, as the cache may decide to automatically mutate itself asynchronously behind the scenes if it is called to free up memory.

Though not required, NSCache works in conjunction with objects that implement the NSDiscardableContent (opens in a new window) protocol in that the discardContentIfPossible (opens in a new window) method is called when an object is removed.

The two most widely used caching strategies are proactive and reactive loading.

1. Proactive Cache Loading. A proactive cache loading strategy attempts to retrieve all required state when a process or application starts and cache it for the lifetime of the process or application. A decision to use a proactive cache loading strategy is generally done so in conjunction with either asynchronous pull loading based on expected not actual usage of the information being cached or notification-based loading whereby an application’s services are notified when cached state changes.
2. Reactive Cache Loading. A reactive cache loading strategy retrieves data as it is requested by the application and caches it for future requests. A decision to use a reactive cache loading strategy is generally done so in conjunction with synchronous pull loading since the pattern is relatively easy to test and implement.

Regardless of the selected caching strategy, determining a cache expiration policy is is key for most applications. There are a plethora of expiration policy patterns but the majority of them fall into the following general categories:

• Time-based. Cached information is invalidated based on relative (sliding window) or absolute time periods.
• Notification-based. Cached information is invalidated based on instructions from a source.
• Counter-based. Cached information is invalidated based on a reference counts.

Regardless of the expiration policy, scavenging based on memory pressure and other heuristics are key to a proper cache design and symmetry of that design is a key component in any distributed algorithm.

For most applications, a reactive cache loading strategy with a synchronous pull model is the most appropriate option. NSCache does evict objects based on memory pressure and so I strongly recommend you implement the NSDiscardableContent protocol for any objects you plan to store in NSCache. NSDiscardableContent is a simple counter-based pattern. For information stored in NSCache that represents NSData objects, Apple provides the NSPurgeableData (opens in a new window) class. NSPurgeable data inherits from NSMutableData and is available in iOS 4.0 and Mac OS X 10.6 and later. A description of how to use this class can be found be reading Caching and Purgeable Memory (opens in a new window) .

I’d like to make one last point. Please be careful not to over-engineer your caching strategy but be elegant about your design.

Make no mistake, software is art. Some artists prefer oil on canvas as their medium. Others choose water color. As software design engineers (SDEs), we have chosen 1s and 0s to communicate our creative visions. Elegance must exist at each step in the engineering process and not only as an afterthought in the development phase. Elegance is the responsibility of each and every participant with accountability functioning as the enforcement point. Without accountability, chaos reigns. Accountability starts within.

Many software engineers find themselves searching for or memorizing patterns that “work” to shortly find themselves bulimically spewing the results onto their canvas. What happened to the elegance of originality? It’s far too easy to become a GP (“Google programmer”). Why? Because creativity and originality aren’t as convenient as letting others do the work, which leads to chaos and hard-to-maintain code; especially, when you’re not the original developer.

Stay with me; we’re only scratching the surface. Do you remember the last time you really evaluated the usability of your consumer API surface? Did your evaluation begin in the design phase? Start with a high-level view of the scenarios. Then oscillate between architectural design and the scenario-based consumer API surface. Do not think about technical design until you’re satisfied with the consumer API surface and the architectural design. Keep in mind; it’s certainly acceptable to refactor your architectural design and consumer API based on the technical design.

An apparent and even larger obstacle I’ve noticed lately is the inability for an SDE to make the jump from procedure (function)-oriented design concepts to that of object-oriented design while keeping an eye to efficiency in terms computational complexity and network round-trips. The devil is in the details. In my opinion, one can’t be an effective architect without being an even more effective SDE; period. The implementation details do change the architecture.

In general, people tend to migrate toward what makes them feel good. Rework doesn’t feel good; no one enjoys it. But, if that was true—if you truly don’t enjoy rework—then why would you not elegantly architect, design, and develop your code initially? Why do you make more work for yourself? Elegance as a foundational element is difficult. More often than not, SDEs take the easy way out because they equate efficiency to speed of completion. I’m not advocating “analysis paralysis” but instead a balanced design. Deadlines must be met. Deadlines should not be met at the expense of elegance.

It’s your canvas.

Let’s begin with formal documentation. The MethodImplOptions.Synchronized option “specifies that the method can be executed by only one thread at a time. Static methods lock on the type, while instance methods lock on the instance. Only one thread can execute in any of the instance functions and only one thread can execute in any of a class’s static functions”.

I’d like to focus on the statement “static methods lock on the type”. Microsoft strongly discourages locking on any public types, or on instances you do not control. This means the common constructs lock(this), lock(typeof(SomeType)), and lock(“myLock”) violate this guideline. If you’re not yet familiar with the reason behind this guideline then please read Joe Duffy’s (opens in a new window) blog entry titled “ Rude unloads and orphaned locks (opens in a new window) “. To provide additional support for Joe’s comments, the formal documentation for MethodImplOptions states “Locking on the instance or on the type, as with the Synchronized flag, is not recommended for public types because code other than your own can take locks on public types and instances. This might cause deadlocks or other synchronization problems.”

To be explicit, the lock(typeof(MyClass)) semantic is exactly what MethodImplOptions.Synchronized implements when adorned on static methods . The lock in this case is across all AppDomains (opens in a new window) in the same operating system process. Consider the following code, which if executed from multiple AppDomains would result in a conflict.

ManualResetEvent e1= new ManualResetEvent(false);
lock (typeof(object)) {
    AppDomain domain = AppDomain.CreateDomain("MyDomain");
    domain.DoCallBack(delegate {
        ThreadPool.QueueUserWorkItem(delegate {
            ManualResetEvent e2= new ManualResetEvent(false);
            lock (typeof(object)) {
                e2.Set();
            }
        });
    });
 
    e1.WaitOne();
}

As a result, you should shy away from using MethodImplOptions.Synchronized for the same reasons you wouldn’t use lock(this) or lock(typeof(SomeClass)).

Additionally, the MethodImplOptions.Synchronized option favors neither readers nor writers. Use of a low-locking technique such as a spinlock (opens in a new window) or the intrinsic ReaderWriterLockSlim (opens in a new window) and Monitor (opens in a new window) classes will perform and scale much better on both single-core and multi-core (CPU) hardware.

The above points are important for several reasons:

1. The scope of a lock is very relevant if a goal of your code is reuse. As a framework writer is it your responsibility to ensure consumers writing applications with differing scalability thresholds and concurrency rates are equally favored; the solution should either work for all consumers or offer options for each category of consumer.
2. If you’re writing code that is to be used in systems where efficient use of system resources (CPU and memory) is paramount then it is your responsibility to provide an implementation that meets this fundamental goal.
3. If you’re executing under the Microsoft SQL Server CLR host and your code takes too long to execute then SQL will force an AppDomain unload, which means (as a specific example), that a finally block wishing to execute Monitor.Exit won’t even be run. As Joe indicates, until you’ve created 4,294,967,295 threads such that the Thread IDs wrap around and the old ID gets assigned to a new thread, and that thread spuriously decides to Exit the Monitor without acquiring it first, your system is going to be locked up for a bit. In other words, deadlocked.
4. The MethodImplAttribute can only be used to adorn (you guessed it) methods.

So how much of a difference can a low-locking technique really make? That obviously depends on the technique. I wrote a parallelized program (using the Microsoft Parallel Extensions for .NET 3.5 (opens in a new window) ) that tests synchronization using MethodImplOptions.Synchronized, Monitor, Interlocked, ReaderWriterLockSlim, and a spin-lock. For those interested, I’ve included my spin-lock implementation to the bottom of this article.

Result Set 1: Write-only access:

• Monitor executed 10,000,000 iterations in 13,372,540 (ticks), which is 747 iterations per tick.
• Interlocked executed 10,000,000 iterations in 18,767,746 (ticks), which is 532 iterations per tick.
• ReaderWriterLockSlim executed 10,000,000 iterations in 18,908,171 (ticks), which is 528 iterations per tick.
• MethodImpl executed 10,000,000 iterations in 22,724,176 (ticks), which is 440 iterations per tick.
• SpinLock executed 10,000,000 iterations in 17,713,122 (ticks), which is 564 iterations per tick.

Result Set 2: Read/write access with an equal read and write frequency:

• Monitor executed 10,000,000 iterations in 23,701,864 (ticks), which is 421 executions iterations per tick.
• Interlocked executed 10,000,000 iterations in 19,864,150 (ticks), which is 503 iterations per tick.
• ReaderWriterLockSlim executed 10,000,000 iterations in 33,751,562 (ticks), which is 296 iterations per tick.
• MethodImpl executed 10,000,000 iterations in 43,442,379 (ticks), which is 230 iterations per tick.
• SpinLock executed 10,000,000 iterations in 20,713,905 (ticks), which is 482 iterations per tick.

Result Sets 3: Read-only access:

• Monitor executed 10,000,000 iterations in 13,810,171 (ticks), which is 724 iterations per tick.
• Interlocked executed 10,000,000 iterations in 17,628,526 (ticks), which is 567 iterations per tick.
• ReaderWriterLockSlim executed 10,000,000 iterations in 20,326,949 (ticks), which is 491 iterations per tick.
• MethodImpl executed 10,000,000 iterations in 34,891,919 (ticks), which is 286 iterations per tick.
• SpinLock executed 10,000,000 iterations in 7,046,085 (ticks), which is 1,419 iterations per tick.

The results are not surprising. Use of the MethodImplOptions.Synchronized option on static methods resulted in a lower concurrency rate. If you require thread synchronization for static methods then I strongly recommend you consider an alternate synchronization technique.

The full source code can be found here .

For this discussion, I’d like to focus on two of the variables: testability and efficient use of system resources.

Garbage Collection

As a prerequisite, I recommend you read this article (opens in a new window) on how garbage collection works at a high-level in the Microsoft .NET Framework. If you don’t have time (opens in a new window) to read the article then do take time to read the next paragraph.

The following is a good idea what sorts of things we should try to avoid to get the best performance out of the garbage collector:

• Too many allocations.
• Too-large allocation.
• Too many pointers.
• Too many roots.
• Too many object writes.
• Too many Almost-Long-Life objects.
• If you implement IDisposable then suppress finalization to reduce costs.

Dependency Injection (DI)

A foundational pattern in xUnit testing is Dependency Injection (DI) (opens in a new window) , which is a form of Inversion of Control (IoC) (opens in a new window) . Specifically, DI is a programming technique where the implementation of one class is actually performed partially by another. Inversion of Control is where a program gives up control of its own execution and simply responds to requests made of it. In the same way, a class using dependency injection gives up control over some of its implementation and lets the injected class do the work.

Three types of DI exist; constructor injection, property injection, and method call injection. Constructor injection is a pattern whereby dependencies are “injected” into an object during construction. Whereas, property injection uses set operations [on properties] to inject dependencies, which obviously occurs after construction. Method call injection simply uses method calls to inject dependencies.

Several libraries exist in each category. For example, the Castle Project (opens in a new window) and ObjectBuilder (opens in a new window) both provide supports for constructor and property injection. As a side note, the Microsoft Enterprise Library (opens in a new window) uses ObjectBuilder internally as its DI container framework. Unity (opens in a new window) is Microsoft’s latest offering from the Pattern’s & Practices team. Unity offers property, constructor, and method call injection.

Static Classes

A static class (opens in a new window) does not have any instance-level members (including constructors) and is defined by the static modifier (opens in a new window) . The compiler in turn marks a static class as sealed and automatically creates a private constructor.

The main features of a static class are:

• They only contain static members.
• They cannot be instantiated.
• They are sealed.
• They cannot contain Instance Constructors (opens in a new window) .

Inherently in the context of unit (and integration) testing, static classes are not recommended due to the difficulty in implementing a thread-safe property injector DI pattern and being unable to use constructor DI. However, the advantage of a properly written static class is there’s only one object instance per AppDomain (opens in a new window) , which can be very efficient on the GC (see the Too Many Object Writes section of the previously referenced article (opens in a new window) ).

This is a very important and annoying impedance that exists between the use of a constructor DI pattern and efficient use (and preservation) of system resources (in this case CPU and memory). We want to be testable and mindful of system resources.

Singletons

For purposes of this discussion, a singleton is a class that only allows a single instance of itself to be created within an AppDomain. The following are recommended singleton patterns.

Sidebar: Understand the Impact of Low-Lock Techniques in Multithreaded Apps (opens in a new window)

Pattern 1: Niladic Constructor

public class MySingleton {
    private static readonly MySingleton _instance = new MySingleton();
 
    private MySingleton() {
    }
 
    public static MySingleton Instance {
        get { return _instance; }
    }
}

Pattern 2: Niladic Constructor (Full Lazy Initialization)

public class MySingleton {
    class Nested {
        //
        // Explicit static constructor to tell C# compiler not to mark
        // type as BeforeFieldInit
        //
        static Nested() {
        }
 
        internal static readonly MySingleton Instance = new MySingleton();
    }
 
    private MySingleton() {
    }
 
    public static MySingleton Instance {
        get { return Nested.Instance; }
    }
}

Note, the following alternate method results in identical MSIL…

public class MySingleton {
    static class Nested {
        internal static readonly MySingleton Instance = new MySingleton();
    }
 
    private MySingleton() {
    }
 
    public static MySingleton Instance {
        get { return Nested.Instance; }
    }
}

A rather dated but still applicable discussion regarding the use of the double-check lock pattern written by Vance Morrison (opens in a new window) can be found here (opens in a new window) and provides insight into subtle nuances of the Microsoft .NET Framework memory model implementation. I’ve attached a PDF version of the discussion to this entry (at the bottom) in case the archive disappears.

Singleton

So back to the question at hand, which is how do I ensure my production code is testable and uses system resources efficiently as possible? I offer the Singleton class, which is defined as…

public sealed class Singleton where T : new() {
    private static readonly T _instance = new T();
 
    private Singleton() {
    }
 
    public static T Instance {
        get { return _instance; }
    }
}

With the Singleton class, we’re now able to use the following syntax in production code…

public class CustomerManager : BusinessLogicComponent {
    private ICustomerRepository _repository;
 
    //
    // This constructor is required by the Singleton generic class.
    //
    [EditorBrowsable(EditorBrowsableState.Never)]
    public CustomerManager()
        : this(Singleton.Instance) {
    }
 
    //
    //  This constructor is to be used only by test projects.
    //
    [EditorBrowsable(EditorBrowsableState.Never)]
    public CustomerProcessor(ICustomerRepository repository) {
        _repository = repository;
    }
 
    public void Add(Customer customer) {
        _repository.Add(customer);
    }
}

…and the following syntax from test projects.

[Test]
public void Customer_Add_Succeeds() {
    //
    // Create a mock customer repository and inject it into the business
    // logic component (manager).
    //
    ICustomerRepository repository = new MockCustomerRepository();
    CustomerManager manager = new CustomerManager(repository)
 
    //
    // Perform remaining test operations.
    //
}

Consumers of the CustomerManager business logic class in production simply use the Singleton class just as the CustomerManager does with the CustomerRepository class in its niladic constructor.

A final note on thread-safety. The singleton pattern does require all instance level methods to be thread-safe.

Conclusion

The Singleton class provides an implementation pattern to balance between two important variables in any design; that of testability and efficient use of system resources. I encourage you to experiment.

Garbage Collector Basics and Performance Hints.zip