iDev: Design pattern are used on iOS Development other than MVC

Hi Friends,

Here the some list of design pattern with sort description


What is Design Pattern?

A design pattern is a common solution to a software problem. They are helpful for speeding up problem solving, ensuring
that a developer doesn’t have to re-invent the wheel for every situation. They also give developers a common vocabulary with which to get across high-level ideas with minimal explanation and full understanding.

Design patterns are everywhere in iOS Developement,Because iOS is a fairly specific platform, developers often face similar problems over and over, so there are a few design patterns that are extremely common in iOS.

Here is a short list of design patterns used by software engineers:

  • Abstract Factory Pattern
  • Adaptor Pattern
  • Object Modeling Pattern
  • Chain of Responsibility Pattern
  • Command Pattern
  • Composite Pattern
  • Decorator Pattern
  • Façade Pattern
  • Iterator Pattern
  • Mediator Pattern
  • Memento Pattern
  • Model-View-Controller Pattern
  • Observer Pattern
  • Proxy Pattern
  • Receptionist Pattern
  • Singleton Pattern
  • Template Method Pattern
  • S.O.L.I.D. Programming

On iOS :

Abstract Factory

The Abstract Factory pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. The client is decoupled from any of the specifics of the concrete object obtained from the factory.


The Adapter design pattern converts the interface of a class into another interface that clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. It decouples the client from the class of the targeted object.

Chain of Responsibility

The Chain of Responsibility design pattern decouples the sender of a request from its receiver by giving more than one object a chance to handle the request. The pattern chains the receiving objects together and passes the request along the chain until an object handles it. Each object in the chain either handles the request or passes it to the next object in the chain.


The Command design pattern encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. The request object binds together one or more actions on a specific receiver. The Command pattern separates an object making a request from the objects that receive and execute that request.


The Composite design pattern composes related objects into tree structures to represent part-whole hierarchies. The pattern lets clients treat individual objects and compositions of objects uniformly. The Composite pattern is part of the Model-View-Controller aggregate pattern.


The Decorator design pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. As does subclassing, adaptation of the Decorator pattern allows you to incorporate new behavior without modifying existing code. Decorators wrap an object of the class whose behavior they extend. They implement the same interface as the object they wrap and add their own behavior either before or after delegating a task to the wrapped object. The Decorator pattern expresses the design principle that classes should be open to extension but closed to modification.


The Facade design pattern provides a unified interface to a set of interfaces in a subsystem. The pattern defines a higher-level interface that makes the subsystem easier to use by reducing complexity and hiding the communication and dependencies between subsystems.


The Iterator design pattern provides a way to access the elements of an aggregate object (that is, a collection) sequentially without exposing its underlying representation. The Iterator pattern transfers the responsibility for accessing and traversing the elements of a collection from the collection itself to an iterator object. The Iterator defines an interface for accessing collection elements and keeps track of the current element. Different iterators can carry out different traversal policies.


The Mediator design pattern defines an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. These objects can thus remain more reusable. A “mediator object” in this pattern centralizes complex communication and control logic between objects in a system. These objects tell the mediator object when their state changes and, in turn, respond to requests from the mediator object.


The Memento pattern captures and externalizes an object’s internal state—without violating encapsulation—so that the object can be restored to this state later. The Memento pattern keeps the important state of a key object external from that object to maintain cohesion.


The Observer design pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. The Observer pattern is essentially a publish-and-subscribe model in which the subject and its observers are loosely coupled. Communication can take place between the observing and observed objects without either needing to know much about the other.


The Proxy design pattern provides a surrogate, or placeholder, for another object in order to control access to that other object. You use this pattern to create a representative, or proxy, object that controls access to another object, which may be remote, expensive to create, or in need of securing. This pattern is structurally similar to the Decorator pattern but it serves a different purpose; Decorator adds behavior to an object whereas Proxy controls access to an object.


The Receptionist design pattern addresses the general problem of redirecting an event occurring in one execution context of an application to another execution context for handling. It is a hybrid pattern. Although it doesn’t appear in the “Gang of Four” book, it combines elements of the Command, Memo, and Proxy design patterns described in that book. It is also a variant of the Trampoline pattern (which also doesn’t appear in the book); in this pattern, an event initially is received by a trampoline object, so-called because it immediately bounces, or redirects, the event to a target object for handling.


The Singleton design pattern ensures a class only has one instance, and provides a global point of access to it. The class keeps track of its sole instance and ensures that no other instance can be created. Singleton classes are appropriate for situations where it makes sense for a single object to provide access to a global resource.

Template Method

The Template Method design pattern defines the skeleton of an algorithm in an operation, deferring some steps to subclasses. The Template Method pattern lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

Source: Cocoa Design Patterns.

Reference : Stackoverflow.


Thanks 🙂 Keep Coding…


iConcept : What is DOM ?


What is DOM (Document Object Model): Tree and Node Structure of HTML Page

The Document Object Model (DOM) defines a standard way for accessing and manipulating HTML documents. The DOM presents an HTML document as a TREE-STRUCTURE. The DOM is a W3C (World Wide Web Consortium) standard. The W3C Document Object Model (DOM) is a platform and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure, and style of a document.

The Document Object Model (DOM) is the model that describes how all elements in an HTML page, like input fields, images, paragraphs etc., are related to the topmost structure: the document itself.
DOM: The Tree and Node Structure
The HTML DOM views an HTML document as a tree-structure. The tree structure is called a node-tree. In the DOM, everything in an HTML document is a node. All nodes can be accessed through the tree. Their contents can be modified or deleted, and new elements can be created.
Note: The Root Node of DOM Tree is DOCUMENT.
document.documentElement – returns the root node of the document
document.body – gives direct access to the <body> tag
The nodes in the node tree have a hierarchical relationship to each other. On the basis of hierarchy, Nodes can be divided into three categories:
1. Parent Nodes
2. Child Nodes
3. Sibling Nodes:
  Child Nodes on the same level are called siblings (brothers or sisters).
<p>This is a paragraph</p>
Here “p” is parent node and ‘This is a paragraph’ is a child node.
1. In a node tree, the top node is called the root
2. Every node, except the root, has exactly one parent node
3. A node can have any number of children
4. A leaf is a node with no children
5. Siblings are nodes with the same parent
Nodes can also be classified as:
1. Element Nodes: Every HTML element is an element node
2. Text Nodes: The text in the HTML elements are text nodes. In the HTML DOM the value of the text node can be accessed by the innerHTML property.
3. Attribute Nodes: Every HTML attribute is an attribute node
4. Comment Nodes: Comments are also treated as nodes in DOM.
5. Document Node: It is the parent node of DOM.. The entire document is a document node
<p align=”right”>This is a paragraph</p>
Here “p” is element node, ‘This is a paragraph” is a text node and “align” is the attribute node.
Node Properties
In the HTML DOM, each node is an object.Objects have methods and properties that can be accessed and manipulated by JavaScript. Three important node properties are:
1. nodeName
2. nodeValue
3. nodeType
The nodeName Property
The nodeName property specifies the name of a node.
1. nodeName is read-only
2. nodeName of an element node is the same as the tag name
3. nodeName of an attribute node is the attribute name
4. nodeName of a text node is always #text
5. nodeName of the document node is always #document
Note: nodeName always contains the uppercase tag name of an HTML element.
The nodeValue Property
1. The nodeValue property specifies the value of a node.
2. nodeValue for element nodes is undefined
3. nodeValue for text nodes is the text itself
4. nodeValue for attribute nodes is the attribute value
The nodeType Property
The nodeType property returns the type of node. nodeType is read only.
The most important node types are: Element Node, Text Node, Attribute Node, Comment Node and Document Node
HTML DOM Methods:
x.getElementById(id) – get the element with a specified id
x.getElementsByTagName(name) – get all elements with a specified tag name
x.appendChild(node) – insert a child node to x
x.removeChild(node) – remove a child node from x
Note: In the list above, x is a node object (HTML element or node, say document).
HTML DOM Properties
x.innerHTML – the text value of x
x.nodeName – the name of x
x.nodeValue – the value of x
x.parentNode – the parent node of x
x.childNodes – the child nodes of x
x.attributes – the attributes nodes of x
Note: In the list above, x is a node object (HTML element or node, say <p>).
Reference : Click Here


iConcept: GET vs POST

 GET vs POST: Which one is better? A 10 point comparison
1. Data Size Restriction in GET: There is a character restriction of 255 in the URL. This is mostly the old browsers restriction and new ones can handle more than that. But we can’t be sure that all our visitors are using new browsers. So when we show a text area or a text box asking users to enter some data, then there will be a problem if more data is entered. This restriction is not there in POST method. We can transfer unlimited data using POST. In PHP by default 8MB of data can be transferred. (can be changed by setting the post_max_size in the php.ini file)
2. Data Type Restriction in GET: As the data transfers through address bar ( URL ) there are some restrictions in using space, some characters like ampersand ( & ) etc in the GET method of posting data. We have to take special care for encoding (while sending) and decoding (while receiving) data if such special characters are present.
3. Security: In GET method data gets transferred to the processing page in name value pairs as a query string in URL, so it is exposed and can be easily traced by visiting history pages of the browser. Data is always submitted in the form of text. So any login details with password should never be posted by using GET method. On the other hand, POST is much more secure. In case of POST, all the name value pairs are submitted in the Message Body of the request.
4. Speed: GET is faster than POST.
5. Bookmarking: There are some special cases where advantage of using GET method is, one can store the name value pairs as bookmark and directly use them by bypassing the form. But you cannot bookmark using POST method.
6. If POST method is used and if the page is refreshed it would prompt before the request is resubmitted but it would not prompt if GET method is used.
7. Uploading files through input type file is possible in POST but not with GET method.
8. There are chances for data lost after server encoding in GET method but no data loss occurs in case of POST method.
9. GET uses STACK method for passing form variables while POST method uses HEAP method for passing form variables.
10. GET can store up to 18 form variables but there is no limit in case of POST method.
Reference : Click Here
Thanks :), Keep Coding:)

iDiscussion : Writing Apps? Juggling Multiple Platforms and the Bumpy Road Ahead

Targeting multiple operating systems has been an industry goal or non-goal depending on your perspective since some of the earliest days of computing. For both app developers and platform builders, the evolution of their work follow typical patterns—patterns where their goals might be aligned or manageable in the short term but become increasingly divergent over time.

While history does not always repeat itself, the ingredients for a repeat of cross-platform woes currently exist in the domain of mobile apps (mobile means apps developed for modern sealed-case platforms such as iOS, Android, Windows RT, Windows Phone, Blackberry, etc.) The network effects of platforms and the “winner take all” state that many believe is reached (or perhaps desirable) influences the behavior and outcome of cross-platform app development as well as platform development.

Today app developers generally write apps targeting several of the mobile platforms. If you look at number of “sockets” over the past couple of years there was an early dominance of iOS followed by a large growth of Android. Several other platforms currently compete for the next round of attention. Based on apps in respective app stores these are two leaders for the new platforms. App developers today seeking the most number of client sockets target at least iOS and Android, often simultaneously. It is too early to pick a winner.

Some would say that the role of the cloud services or the browser make app development less about the “client” socket. The data, however, suggests that customers prefer the interaction approach and integration capability of apps and certainly platform builders touting the size of app stores further evidences that perspective. Even the smallest amount of “dependency” (for customers or technical reasons) on the client’s unique capabilities can provide benefits or dramatically improve the quality of the overall experience.

In discussions with entrepreneurs I have had, it is clear the approach to cross-platform is shifting from “obviously we will do multiple platforms” to thinking about which platform comes first, second, or third and how many to do. Chris Dixon recently had some thoughts about this in the context of modern app development in general (tablets and/or phones). I would agree that tablets drive a different type of app over time simply because the scenarios can be quite different even with identically capable devices under the hood. The cross-platform question only gets more difficult if apps take on unique capabilities or user experiences for different sized screens, which is almost certainly the case.


The history of cross-platform development is fairly well-known by app developers.

The goal of an app developer is to acquire as many customers as possible or to have the highest quality engagement with a specific set of customers. In an environment where customers are all using one platform (by platform we mean set of APIs, tools, languages that are used to build an app) the choice for a developer is simple, which is to target the platform APIs in a fully exploitive manner.

The goal of being the “best” app for the platform is a goal shared by both app and platform developers. The reason for this is that nearly any app will have app competitors and one approach to differentiation will be to be the app that is best on the platform—at the very least this will garner the attention of the platform builder and result in amplification of the marketing and outreach of a given app (for example, given n different banking apps, the one that is used in demonstrations or platform evangelism will be the one that touts the platform advantages).

Once developers are faced with two or more platforms to target, the discussion typically starts with attempting to measure the size of the customer base for each platform (hence the debate today about whether market share or revenue define a more successful platform). New apps (at startups or established companies) will start with a dialog that depending on time or resources jumps through incredible hoops to attempt to model the platform dynamics. Questions such as which customers use which platforms, velocity of platform adoption, installed base, likelihood of reaching different customers on platforms, geography of usage, and pretty much every variable imaginable. The goal is to attempt to define the market impact of either support multiple platforms or betting on one platform. Of course none of these can be known. Observer bias is inherent in the process only because this is all about forecasting a dynamic system based on the behavior of people. But basing a product plan on a rapidly evolving and hard to define “market share” metric is fraught with problems.

During this market sizing debate, the development team is also looking at how challenging cross platform support can be. While mostly objective, just as with the market sizing studies, bias can sneak in. For example, if the developers’ skills align with one platform or a platform makes certain architectural assumptions that are viewed favorably then different approaches to platform choices become easy or difficult.

Developers that are fluent in HTML might suggest that things be done in a browser or use a mobile browser solution. Even the business might like this approach because it leverages an existing effort or business model (serving ads for example). Some view the choices Facebook made for their mobile apps as being influenced by these variables.

As the dialog continues, developers will tend to start to see the inherent engineering costs in trying to do a great job across multiple platforms. They will start to think about how hard it is to keep code bases in sync or where features will be easier/harder or appear first or even just sim-shipping across platforms. Very quickly developers will generally start to feel pulled in an impossible direction by having to be across multiple platforms and that it is just not viable to have a long-term cross-platform strategy.

The business view will generally continue to drive a view that the more sockets there are the better. Some apps are inherently going to drive the desire or need for cross-platform support. Anything that is about communications for example will generally argue for “going where the people are” or “our users don’t know the OS of their connected endpoints” and thus push for supporting multiple platforms. Apps that are offered as free front ends for services (online banking, buying tickets, or signing up for yoga class) will also feel pressures to be where the customers are and to be device agnostic. As you keep going through scenarios the business folks will become convinced that the only viable approach is to be on all the popular platforms.

That puts everyone in a very tense situation—everyone is feeling stressed about achieving success. Something has to give though.

We’ve all been there.


The industry has seen this cross-platform movie several times. It might not always be the same and each generation brings with it new challenges, new technologies, and potentially different approaches that could lead to different outcomes. Knowing the past is important.

Today’s cross-platform challenge can be viewed differently primarily because of a few factors when looking at the challenge from an app developer / ISV:

  • App Services. Much of the functionality for today’s apps resides on software as a service infrastructure. The apps themselves might be viewed as fairly lightweight front ends to these services, at least for some class of apps or some approaches to app building. This is especially true today as most apps are still fairly “first generation”.
  • Languages and tools. Today’s platforms are more self-contained in that the languages and tools are also part of the platform. In previous generations there were languages that could be used across different platforms (COBOL, C, C++) and standards for those languages even if there were platform-specific language extensions. While there are ample opportunities for shared libraries of “engine” code in many of today’s platforms, most modern platforms are designed around a heavy tilt in favor of one language, and those are different across platforms. Given the first point, it is fair to say that the bulk of the code (at least initially) on the device will be platform specific anyway.
  • Integration. Much of what goes on in apps today is about integration with the platform. Integration has been increasing in each generation of platform shifts. For example, in the earliest days there was no cross-application sharing, then came the basics through files, then came clipboard sharing. Today sharing is implicit in nearly every app in some way.

Even allowing for this new context, there is a cycle at work in how multiple, competing platforms evolve.

This is a cycle so you need to start somewhere.

Initially there is a critical mass around one platform. As far as modern platforms go when iOS was introduced it was (and remains) unique in platform and device attributes so mobile apps had one place to go and all the new activity was on that platform. This is a typical first-mover scenario in a new market.

Over time new platforms emerge (with slightly different characteristics) creating a period of time where cross-platform work is the norm. This period is supported by the fact that platforms are relatively new and are each building out the base infrastructure which tends to look similar across the new platforms.

There are solid technical reasons why cross-platform development seems to work in the early days of platform proliferation. When new platforms begin to emerge they are often taking similar approaches to “reinventing” what it means to be a platform. For example, when GUI interfaces first came about the basics of controls, menus, and windows were close enough that knowledge of one platform readily translated to other platforms. It was technically not too difficult to create mapping layers that allowed the same code to be used to target different platforms.

During this phase of platform evolution the platforms are all relatively immature compared to each other. Each is focused on putting in place the plumbing that approaches platform design in this new shared view. In essence the emerging platforms tend to look more similar that different. The early days of web browsers–which many believed were themselves platforms–followed this pattern. There was a degree of HTML that was readily shared and consistent across platforms. At least this was the case for a while.

During this time there is often a lot of re-learning that takes place. The problems solved in the previous generation of platforms become new again. New solutions to old problems arise, sometimes frustrating developers. But this “new growth” also brings with it a chance to revisit old assumptions and innovate in new ways, even if the problem space is the same.

Even with this early commonality, things can be a real challenge. For example, there is a real desire for applications to look and feel “native”. Sometimes this is about placement of functionality such as where settings are located. It could be about the look or style of graphical elements or the way visual aspects of the platform are reflected in your app. It could also be about highly marketed features and how well your app integrates as evidence for supporting the platform.

Along the way things begin to change and the platforms diverge because of two factors. First, once the plumbing common to multiple early platforms is in place, platform builders begin to express their unique point of view of how platform services experiences should evolve. For example, Android is likely to focus on unique services and how the client interacts with and uses those services. To most, iOS has shown substantially more innovation in client-side innovation and first-party experiences. The resulting APIs exposed to developers start to diverge in capabilities and new API surface areas no longer seem so common between platforms.

Second, competition begins to drive how innovation progresses. While the first mover might have one point of view, the second (or third) mover might take the same idea of a service or API but evolve it slightly differently. It might integrate with backends differently or it might have a very different architecture. The role of voice input/reco, maps, or cloud storage are examples of APIs that are appearing on platforms but the expression of those APIs and capabilities they support are evolving in different ways that there are no obvious mappings between them.


As the platforms diverge developers start to make choices about what APIs to support on each platform or even which platforms to target. With these choices come a few well known challenges.

  • Tools and languages.Initially the tools and languages might be different but things seem manageable. In particular, developers look to put as much code in common languages (“platform agnostic code”) or implement code as a web service (independent of the client device). This is a great strategy but does not allow for the reality that a good deal of code (and differentiation) will serve as platform-specific user experience or integration functionality. Early on tools are relatively immature and maybe even rudimentary which makes it easier to build infrastructure around managing a cross-platform project. Over time the tools themselves will become more sophisticated and diverge in capabilities. New IDEs or tools will be required for the platforms in order to be competitive and developers will gravitate to one toolset, resulting in developers themselves less able to context switch between platforms. At the very least, managing two diverging code bases using different tools becomes highly challenging–even if right now some devs think they have a handle on the situation.
  • User interaction and design (assets). Early in platform evolution the basics of human interaction tend to be common and the approaches to digital assets can be fairly straight forward. As device capabilities diverge (DPI, sensors, screen sizes) the ability for the user interaction to be common also diverges. What works on one platform doesn’t seem right on another. Tablet sized screens introduce a whole other level of divergence to this challenge. Alternate input mechanisms can really divide platform elements (voice, vision, sensors, touch metaphors).
  • Platform integration. Integrating with a platform early on is usually fairly “trivial”. Perhaps there are a few places you put preferences or settings, or connect to some platform services such as internationalization or accessibility. As platforms evolve, where and how to integrate poses challenges for app developers. Notifications, settings, printing, storage, and more are all places where finding what is “common” between platforms will become increasingly difficult to impossible. The platform services for identity, payment, and even integration with third party services will become increasingly part of the platform API as well. When those APIs are used other benefits will accrue to developers and/or end-users of apps—and these APIs will be substantially different across platforms.
  • More code in the service. The new platforms definitely emphasize code in services to provide a way to be insulated from platform changes. This is a perfect way to implement as much of your own domain as you can. Keep in mind that the platforms themselves are evolving and growing and so you can expect services provided by the platform to be part of the core app API as well. Storage is a great example of this challenge. You might choose to implement storage on your own to avoid a platform dependency. Such an approach puts you in the storage business though and probably not very competitively from a feature or cost perspective. Using a third party API can pose the same challenge as any cross-platform library. At the same time, the platforms evolve and likely will implement storage APIs and those APIs will be rich and integrate with other services as well.
  • Cross-platform libraries. One of the most common approaches developers attempt (and often provided by third parties as well) is to develop or use a library that abstracts away platform differences or claims to map a unique “meta API” to multiple platforms. These cross—platform libraries are conceptually attractive but practically unworkable over time. Again, early on this can work. Over time the platform divergence is real. There’s nothing you can do to make services that don’t exist on one platform magically appear on another or APIs that are architecturally very different morph into similar architectures. Worse, as an app developer you end up relying on essentially a “shadow” OS provided by a team that has a fraction of the resources for updates, tooling, documentation, etc. even if this team is your own dev team. As a counter example, games commonly use engines across platforms, but they rely on a very narrow set of platform APIs and little integration. Nevertheless, there are those that believe this can be a path (as it is for games). It is important to keep in mind that the platforms are evolving rapidly and the customer desire for well-integrated apps (not just apps that run).
  • Multiple teams. Absent the ability to share app client code (because of differing languages), keeping multiple teams in sync on the same app is extremely challenging. Equally challenging is having one team time slice – not only is that mentally inefficient, maintaining up to date skills and knowledge for multiple platforms is challenging. Even beyond the basics of keeping the feature set the same, there are problems to overcome. One example is just timing of releases. It might be hard enough to keep features in sync and sim ship, but imagine that the demand spike for a new release of your app when the platform changes (and maybe even requires a change to your app). You are then in a position to need a release for one platform. But if you are halfway done with new features for your app you have a very tricky disclosure and/or code management challenge. These challenges are compounded non-linearly as the number of platforms increases.

These are a few potential challenges. Not every app will run into these and some might not even be real challenges for a particularly app domain. By and large, these are the sorts of things that have dogged developers working cross-platform approaches across clients, servers, and more over many generations.

What’s next?

The obvious question will continue to be debated, which is if there is a single platform winner or not. Will developers be able to pick a platform and reach their own business and product goals by focusing on one platform as a way of avoiding the issues associated with supporting multiple platforms?

The only thing we know for sure is that the APIs, tools, and approaches of different platforms will continue to evolve and diverge. Working across platforms will only get more difficult, not easier.

The new platforms moved “up the stack” and make it more difficult for developers to isolate themselves from the platform changes. In the old days, developers could re-implement parts of the platform within the app and use that across platforms or even multiple apps. Developers could hook the system and customize the behavior as they saw fit. The more sealed nature of platforms (which delivers amazing benefits for end-users) makes it harder for developers to create their own experience and transport it across platforms. This isn’t new. In the DOS era, apps implemented their own printing subsystems and character-based user models all of which got replaced by GUI APIs all to the advantage of developers willing to embrace the richer platforms and to the advantage of customers that gained a new level of capabilities across apps.

The role of app stores and approval processes, the instant ability for the community to review apps, and the need to break through in the store will continue to drive the need to be great apps on the chosen platforms.

Some will undoubtedly call for standards or some homogonization of platforms. Posix in the OS world, Motif in the GUI world, or even HTML for browsers have all been attempts at this. It is a reasonable goal given we all want our software investments to be on as many devices as possible (and this desire is nothing new). But is it reasonable to expect vendors to pour billions into R&D to support an intentional strategy of commoditization or support for a committee design? Vendors believe we’re just getting started in delivering inovation and so slowing things down this way seems counter-intuitive at best.

Ultimately, the best apps are going to break through and I think the best apps are going to be the ones that work with the platform not in spite of it and the best apps won’t duplicate code in the platform but work with platform.

It means there some interesting choices ahead for many players in these ecosystems.

BY: Steven Sinofsky

Reference : Here


iConcept : Basic MVVM with Re-Active COCOA

Basic MVVM with Reactive Cocoa

MVC – One Pattern to Rule them all

The MVC design pattern has existed since the late 1970s and has been in use in the Foundation, AppKit & UIKit Frameworks for a long time now. At its heart is a very simple design and a good idea. The Design is this

As you can see we have 3 components

  • Model – The Data model our view is managing
  • View – The User Interface on screen consisting of things such as text fields, buttons, etc.
  • Controller – The Controller in MVC exists to decouple the view from the model.

In the MVC design pattern, the controller separates the model from the view so that each can change independently. If we didn’t have such a decoupling then every time the model changed, the view would need to change as well. In this design pattern interactions happen like this

  1. A view triggers an action to happen on the Controller
  2. The Controller executes said action and updates the model
  3. The controller may receive a notification from the model that it was updated.
  4. The Controller updates the view

This is the MVC waltz that we do when working with this design pattern, overall it works fairly well. The reason we use this is because this pattern decouples the view from the data model, letting the controller be an intermediary between the 2. This allows the controller to access the parts of the data model that need to be accessed and allows for the controller to do things like properly format the data for the view.

MVVM – For a Better World

MVVM stands for Model-View-ViewModel, and comes from Microsoft and is based off of the MVC design pattern. To be more precise, it is based off of Martin Fowlers Presentation Model. To some people at first it looks very similar to the MVC design pattern and people become confused as to how its different. So let me show you the pattern and then we’ll see how its different

In this pattern we still have 3 components, the same as MVC however there are differences. In MVVM I and others tend to group the View Controller in with the View so that those 2 things are treated as 1 component. The most important part is that we’ve introduced the View Model and that the view gets updates pushed at it from the view model through some sort of observer. In this article ReactiveCocoa will be that observer.

In the MVVM pattern the View Model encapsulates data/properties that the view can bind to, any validation logic and actions that can be performed. For Instance if you had a button that needs to change its title text you would have a property on the view model that the button can bind its title property to. The same goes if you need to change the color of a control or enable and disable the control. In this pattern we are essentially taking the state of our app and putting it into a view model. Its also good to note that as far as the View Model is concerned it doesn’t care where it gets this state from. It doesn’t matter if it gets it from its init method, a file on disk, Core Data, a database, etc.

Because we are encapsulating the state of our view in such a way this has several benefits.

We don’t need to test the UI

In terms of standard controls we don’t need to test our UI’s at all since the controls are just binding their state to the view model. Apple should be testing the controls that we are using, and you should be testing the custom controls you create. This means that as we bind our controls state to the view model we don’t need to query the controls for their state as we should be able to access it within the view model itself. This feature tends to lending itself well to the next feature…

We can easily Unit Test the View Model

The View model has access to all the properties the views are binding to, and because of this we can have validation logic on the view model. This also makes it extremely easy to unit test the model and unit test the various states our UI can get into. I think Justin actually phrased this excellently “A good litmus test for MVVM is whether you’re able to write automated tests for your UI behavior without actually having a live UI.” I completely agree with this and think it excellently encapsulates the core idea of MVVM.

Its easier to change the UI

Because the UI is just binding to the view model, this means you should be able to swap components out and just bind the apppropriate properties to the view model and your UI should work the same as before. This should also make it easier for UI designers to experiment around with different views in your app.

ReactiveCocoa: An introduction

As I mentioned ReactiveCocoa is an implementation of Reactive Extensions .NET for Cocoa. The API is not an exact mapping of the API from Rx to Cocoa as explained in the project docs. ReactiveCocoa is also built using the concept of Functional Reactive Programming.

Functional Reactive Programming (FRP) is a programming paradigm for writing software that reacts to change.

FRP is built on the abstraction of values over time. Rather than capturing a value at a particular time, FRP provides signals that capture the past, present, and future value. These signals can be reasoned about, chained, composed, and reacted to.

By combining signals, software can be written declaratively, without the need for code that continually observes and updates values. A text field can be directly set to always show the current timestamp, for example, instead of using additional code that watches the clock and updates the text field every second.

Signals can also represent asynchronous operations, much like futures and promises. This greatly simplifies asynchronous software, including networking code.

One of the major advantages of FRP is that it provides a single, unified approach to dealing with different types of reactive, asynchronous behaviors.

Lets jump right into ReactiveCocoa through a couple examples and explain what is going on.

[RACAble( subscribeNext:^(NSString *newName){
    NSLog(@"Name changed to %@",newName);
}]; = @"Hypnotoad"; = @"Nibbler";

When this runs it’ll give the output “Name changed to Hypnotoad” and then “Name changed to Nibbler”. What we did was create a signal around a key path in self, and then subscribed to that signal and received events on the stream from that signal. Think of it this way, once we create a signal around a key path in this manner anytime the value of that key path changes the signal will see this and send a -next signal with the updated value. We automatically subscribed to this signal when we called -subscribeNext on it.

Signals only send 3 types of messages

  • next : This is how we get updated values from the stream
  • error : This is sent anytime the signal could not complete
  • competed : Sent to let you know that there will be no more signals on the stream

Lets create a signal of our own so you can see what is going on here

-(RACSignal *)urlResults {
    return [RACSignal createSignal:^RACDisposable *(id<RACSubscriber> subscriber) {
    NSError *error;
    NSString *result = [NSString stringWithContentsOfURL:
                  [NSURL URLWithString:@""]
    if (!result) {
        [subscriber sendError:error];
    } else {
        [subscriber sendNext:result];
        [subscriber sendCompleted];
    return nil;

Although we could achieve this through other means, I wanted to create this manually. This method returns a signal which was created to get the string contents of a URL address and then return them to us. For this I used NSStrings built in method to retrieve a string from a URL. All we need to do is check to see if we have a result and if we don’t then we can send -next and then -completed because we don’t intend to send anymore messages.

Besides receiving updated values which we’ll likely use for assignment to variables, signals also can be used in validation.

NSCharacterSet *charSet = 
   [NSCharacterSet characterSetWithCharactersInString:@" "];
RACSignal *nameFieldValid = [RACSignal combineLatest:
 @[ self.usernameField.rac_textSignal, 
  self.passwordField.rac_textSignal ]
 reduce:^(NSString *username, NSString *password) {
    return @((username.length > 0) && (password.length > 0) &&
            ([username rangeOfCharacterFromSet:charSet].location 
              == NSNotFound));

This particular example would work on iOS if you had a Username field, password field and you wanted to know if it was filled out correctly. For the purposes of this example we will only concern ourselves with making sure the username & password has a length greater than 0 and doesn’t have any spaces in the user name. The combineLatest part of the method makes sure that we get the latest values from the textfield signal, then in the reduce section we are simply returning a number (0 or 1) to indicate if this is valid. When we hook this up to the enabled property of a control we get…

RAC(self.loginButton.enabled) = nameFieldValid;

and from there on out we get a button that is automatically enabled & disabled when the correct conditions arise from the signal we binded it to. Similarly we can bind controls to a view model like so…

RAC(self.textField.text) = RACAble(self.viewModel.title);

What is going on here is that ReactiveCocoa is implicitly setting up all the necessary infastructure to bind a field to a signal. If you expand the RAC fields you get something like…

[RACSubscriptingAssignmentTrampoline trampoline][ 
[[RACSubscriptingAssignmentObjectKeyPathPair alloc] initWithObject:self 
@(((void)(__objc_no && ((void)self.self.resultLabel.string, __objc_no)),
 "self.resultLabel.string"))] ] = 
 [self rac_signalForKeyPath:@(((void)(__objc_no && 
 ((void)self.self.aTitle, __objc_no)), 

Be thankfull you don’t have to write all that every time you wanted to bind properties in your code.

What is the ViewModel?

So i mentioned the View Model earlier as being the thing that our user interface binds its properties to as well as containing the actions that can be done to the view model and any validation logic. Lets show a simple example and get started figuring out how the VM in MVVM works. Here is a screenshot of the UI we’ll work with…

And here is the ViewModel interface…

#import <Foundation/Foundation.h>

@interface CDWPlayerViewModel : NSObject

@property(nonatomic, retain) NSString *playerName;

@property(nonatomic, assign) double points;
@property(nonatomic, assign) double stepAmount;
@property(nonatomic, assign) double maxPoints;
@property(nonatomic, assign) double minPoints;

@property(nonatomic, readonly) NSUInteger maxPointUpdates;



-(RACSignal *)forbiddenNameSignal;

-(RACSignal *)modelIsValidSignal;


and the implementation

#import "CDWPlayerViewModel.h"

@interface CDWPlayerViewModel ()
@property(nonatomic, retain) NSArray *forbiddenNames;
@property(nonatomic, readwrite) NSUInteger maxPointUpdates;

@implementation CDWPlayerViewModel

-(id)init {
    self = [super init];
    if(!self) return nil;

    _playerName = @"Colin";
    _points = 100.0;
    _stepAmount = 1.0;
    _maxPoints = 10000.0;
    _minPoints = 0.0;

    _maxPointUpdates = 10;

    //I guess we'll go with the ned flanders bad words
    //change this to whatever you want
    _forbiddenNames = @[ @"dag nabbit",

    return self;

-(IBAction)resetToDefaults:(id)sender {
    self.playerName = @"Colin";
    self.points = 100.0;
    self.stepAmount = 1.0;
    self.maxPoints = 10000.0;
    self.minPoints = 0.0;
    self.maxPointUpdates = 10;
    self.forbiddenNames = @[ @"dag nabbit",

-(IBAction)uploadData:(id)sender {
    [[RACScheduler scheduler] schedule:^{
        //pretend we are uploading to a server on a backround thread...
        //dont ever put sleep in your code
        //upload player & points...

        [[RACScheduler mainThreadScheduler] schedule:^{
            NSString *msg = [NSString stringWithFormat:
                @"Updated %@ with %.0f points",self.playerName,self.points];

            UIAlertView *alert = [[UIAlertView alloc]
                   initWithTitle:@"Upload Successfull" message:msg delegate:nil
                     cancelButtonTitle:@"ok" otherButtonTitles:nil];
            [alert show];

-(RACSignal *)forbiddenNameSignal {
    return [RACAble(self.playerName) filter:^BOOL(NSString *newName) {
        return [self.forbiddenNames containsObject:newName];

-(RACSignal *)modelIsValidSignal {
    return [RACSignal
            combineLatest:@[ RACAbleWithStart(self.playerName),
                            RACAbleWithStart(self.points) ]
            reduce:^id(NSString *name, NSNumber *playerPoints){
                return @((name.length > 0) &&
                (![self.forbiddenNames containsObject:name]) &&
                (playerPoints.doubleValue >= self.minPoints));


A short note about @weakify(self); and @strongify(self);, this is one of the things you can do in addition to using __weak id bself = self; in your apps to avoid retaining self. This particular bit of code is from libextobjc which is used by ReactiveCocoa and thus available to you. In particular this has the same effect of creating a weak reference to self. I like this approach because you just keep using self.[property]... in your code and you don’t have to constantly remember to create a bself variable. Check out EXTScope.h in libextobjc.

as you can see its relatively simple because we are only really concerned with a couple properties related to the player. The other properties are for controls to bind to and for some validation. We also have a single action method and a couple signals. The one thing you’ll notice is the View Model has no clue what the UI it’ll bind to is like at all. This is great because it means you have flexibility in what you bind things to and you can hook up to the view model in ways that make sense for the class thats binding to it.

Now lets look in our ViewController and how it is using these properties and signals…

__weak CDWViewController *bself = self;

To make sure we don’t retain self in our blocks we need to use a weak reference. The ReactiveCocoa Project also has @weakify and @strongify for doing this in blocks, but i’ll let you investigate that and see if you want to use it.

//Create the View Model
self.viewModel = [CDWPlayerViewModel new];

obviously start with creating a ViewModel instance

//Start Binding our properties
RAC(self.nameField.text) = 
[RACAbleWithStart(self.viewModel.playerName) distinctUntilChanged];

[[self.nameField.rac_textSignal distinctUntilChanged]
 subscribeNext:^(NSString *x) {
    bself.viewModel.playerName = x;

The first control is the UITextField for the player name, so we need to bind its text property to the view models playerName property. We also need to make sure we update the view model with updates from the text field. This ensures that the text field receives any updates from the view model and also makes sure that the view is updating the player name property on the view model.

//the score property is a double, RC gives us updates as NSNumber which we just call
//stringValue on and bind that to the scorefield text
RAC(self.scoreField.text) = [RACAbleWithStart(self.viewModel.points)
 map:^id(NSNumber *value) {
    return [value stringValue];

We need to bind the labels text property to the view models points property. The view models points property is a double, but ReactiveCocoa gives us updates to this as NSNumber’s so we need to map this to a NSString which the label can use.

//Setup bind the steppers values
self.scoreStepper.value = self.viewModel.points;
RAC(self.scoreStepper.stepValue) = RACAbleWithStart(self.viewModel.stepAmount);
RAC(self.scoreStepper.maximumValue) = RACAbleWithStart(self.viewModel.maxPoints);
RAC(self.scoreStepper.minimumValue) = RACAbleWithStart(self.viewModel.minPoints);

Simple binding and setup. Give the stepper the initial value from the view model and bind the properties (stepValue,min,max) to the view model.

//bind the hidden field to a signal keeping track if
//we've updated less than a certain number times as the view model specifies
RAC(self.scoreStepper.hidden) = [RACAble(self.scoreUpdates) 
map:^id(NSNumber *x) {
    return @(x.intValue >= bself.viewModel.maxPointUpdates);
}];//only take the maxPointUpdates number of score updates
[[RACAble(self.scoreStepper.value) take:self.viewModel.maxPointUpdates]
 subscribeNext:^(id newPoints) {
    bself.viewModel.points = [newPoints doubleValue];

We’ll enforce a rule from the view model that at any given time you can only update the points 10 times. To do this I created a NSUInteger property (in fact the only property we ever actually add to the view controller.) Then bind the hidden property to a signal which reduces to a 0 or 1 based on if the number of times we’ve updated is greater or equal to the number of times we’ve updated the points. So as soon as it hits the number we want this will return 1 and flip the hidden property to YES. To update the points we subscribe to the value property of the stepper and anytime it updates we update the view model and increment the player points.

//this signal should only trigger if we have "bad words" in our name
[self.viewModel.forbiddenNameSignal subscribeNext:^(NSString *name) {
    UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Forbidden Name!"
                           message:[NSString stringWithFormat:
                           @"The name %@ has been forbidden!",name]
    [alert show];
    bself.viewModel.playerName = @"";

If you remember the view model has a validation signal which indicates if any names given are forbidden. My list is really bad and not representative of what I personally think are bad words by any stretch of the imagination. The beauty of this is that we don’t need to know any of the details of what the view model thinks is a “bad word”, but it can just provide a signal to indicate that it thinks something should be forbidden. The view model can provide signals for many things like this that it thinks are important to let you know about it. In this case all we’ve decided to do is show an alert view and reset the player name.

//let the upload(save) button only be enabled when the view model says its valid
RAC(self.uploadButton.enabled) = self.viewModel.modelIsValidSignal;

Another signal that the view model provides to us is a signal letting us know if the view model as it exists it valid or not. In this case i’ve hooked this signal to the enabled property of the upload button. So we should not be able to upload the player stats if the state of the view model is bad. The signal here is simple

-(RACSignal *)modelIsValidSignal {
    return [RACSignal
            combineLatest:@[ RACAbleWithStart(self.playerName), 
                            RACAbleWithStart(self.points) ]
            reduce:^id(NSString *name, NSNumber *playerPoints){
                return @((name.length > 0) && 
                     (![self.forbiddenNames containsObject:name]) 
                  && (playerPoints.doubleValue >= self.minPoints));

So for the purposes of this simple demo, we are just concerned if the name length is greater than 0, the name isn’t in the forbidden names and the points are greater than the minimum. Really we should be concerned with more, but I won’t extend it further. We could even just put the forbiden names signal in if we changed it to use map and return a NSNumber with 0 or 1 and so we could use it here inside this signal.

//set the control action for our button to be the ViewModels action method
[self.uploadButton addTarget:self.viewModel

The button is set to trigger the View Mode’s upload data action. This method in the sample code simulates uploading something then presents an alert view letting you know about the success of uploading.

//we can subscribe to the same thing in multiple locations
//here we skip the first 4 signals and take only 1 update
//and then disable/hide certain UI elements as our app
//only allows 5 updates
[[[[self.uploadButton rac_signalForControlEvents:UIControlEventTouchUpInside]
   skip:(kMaxUploads - 1)] take:1] subscribeNext:^(id x) {
    bself.nameField.enabled = NO;
    bself.scoreStepper.hidden = YES;
    bself.uploadButton.hidden = YES;

Here since there is already signals enabling the button now the number of uploads need to be limited. This is subscribing to the signal for the UIControlEventTouchUpInside event and on the nth update where n is kMaxUploads. On the nth update the namefield is disabled, and the score stepper and upload buttons are hidden.

All of this results in a UI that just binds its properties to a view model, sets its actions to actions on the view model and receives signals from the view model indicating things of interest. I admit this particular example is a bit weird, but it demonstrates using a view model and using the basic aspects of ReactiveCocoa. There is a lot more to ReactiveCocoa in particular that I haven’t shown here for the sake of not introducing too many concepts all at once. Additionally we could build some better view models for dealing with networking code and could deal with child view controllers, but that will have to wait for another article.

So what have we seen here?

  • MVVM stands for Model-View-ViewModel
  • The View model contains things like properties to bind to, validation logic and actions to be done to the view model
  • The View Model should not know anything about the UI that will bind to it
  • ReactiveCocoa is an implementation of many of the API’s in Microsofts Reactive Extensions for .NET in Cocoa
  • We learned how to bind & subscribe to properties
  • We learned how to create signals

The biggest thing you can see with reactive cocoa is that all the code and signals are just reacting to events. When we chain these responses together and filter events properly we heavily reduce the need to create tons of variables and methods just to keep track of the events going on. This leads to more reliable code and with the view model we can easily test it and simulate a UI without actually having a live UI in our app.

The complete source code thats shown here is located here

So check out ReactiveCocoa on github, and I’ve provided some helpful links at the bottom to help understand these concepts. If people want i’ll dive deeper into ReactiveCocoa in later articles.

Update Since first publication this article has been updated to address a couple minor issues

  • Make sure we don’t retain self in blocks
  • Update a piece of code where -map could simply be used in place of -combineLatest:reduce:
  • The github sample code repo code has been updated

Reference Source : Here

Thanks 🙂 Keep Coding 🙂


iConcept : Cocoa Design Patterns

Cocoa Design Patterns

A Design Pattern is a reocurring solution to a common software engineering problem. The idea behind design patterns is to not continually reinvent the wheel.

Design Patterns differ from Templates in that they do not contain executable code.

An example of a Design Pattern is the Listener (Observer). A Listener is an object which waits for information from another object. Now, it is clear that this is a very useful basic idea. Listeners are used in all aspects of Mac OS X and Cocoa for many purposes, not the least of which is GUI management. However, rather than stumble over the same design issues whenever you need to implement a type of listener, the Listener is a documented design pattern that features prepared solutions to these issues. You don’t need to discover for yourself that all the Observers for an object can be stored in a single array, because this is included in the Design Pattern.

Question: Is there any place on the net to discuss advanced programming techniques, problems arising when trying to apply patterns and similar (preferably related to CeePlusPlus), just like this WikiWikiWeb is?

How about the Portland Pattern Repository? . It’s the first WikiWikiWeb.

Digest/Directory of standard Gang of Four design patterns in Cocoa

It is informative to note that many of the famous design patterns in “Design Patterns” were first recognized in NeXTstep, a precursor to Cocoa, and in fact “Design Patterns” provides many such citations. Many of the patterns exist within Cocoa with different names than the Gang of Four gave them for the “Design Patterns” book.

The following is a digest/directory of standard Gang of Four design patterns and their names, roles, and relationships within Cocoa. For each pattern, there are links to pages within this site including discussions, named Cocoa classes that participate in the patterns, and commentary about the patterns in the context of Cocoa.

The place to start is Apple�s own design patterns documentation”


*Abstract Factory

Creates an instance of several families of classes *

NSObject Objective-C class methods are sometimes call factory methods. This pattern is intrinsic to the Objective-C language. Every Objective C class is potentially an abstract factory. This pattern is also used to implement CocoaClassClustersSubClass“>ShouldClassClusterPlaceholderBeASubClass”


*Builder Separates object construction from its representation *

NSDocumentManager? � Builds NSDocument instances with NSWindowManager(s), handles recent documents menu, builds document related responder chain� NSApplication? � Builds main menu, initial responder chain, run loop�

*Factory Method Creates an instance of several derived classes *

Objective-C class methods are sometimes call factory methods. This pattern is intrinsic to the Objective-C language. NSObject ClassClustersSubClass“>ShouldClassClusterPlaceholderBeASubClass

*Prototype A fully initialized instance to be copied or cloned *

NSCell is a Prototype when used with NSMatrix.

*Singleton A class of which only a single instance can exist *

Structural Patterns

*Adapter Match interfaces of different classes *

*Bridge Separates an object�s interface from its implementation *

*Composite A tree structure of simple and composite objects *

*Decorator Add responsibilities to objects dynamically *

*Facade A single class that represents an entire subsystem *

NSImage – NSText and NSTextView encapsulate the functionality of complex text layout and editing which is internally implement with NSTextStorage, NSLayoutManager, and other classes.

*Flyweight A fine-grained instance used for efficient sharing * NSCell

*Proxy An object representing another object *

Behavioral Patterns

*Chain of Resp. A way of passing a request between a chain of objects *

*Command Encapsulate a command request as an object *

*Interpreter A way to include language elements in a program *

Value Transformers?

*Iterator Sequentially access the elements of a collection *

*Mediator Defines simplified communication between classes *

NSObjectController, NSArrayController, NSTreeController, and NSUserDefaultsController”


*Memento Capture and restore an object’s internal state *

NSCoder NSKeyedArchiver and NSKeyUnarchiver”


*Observer A way of notifying change to a number of classes *

*State Alter an object’s behavior when its state changes *

*Strategy Encapsulates an algorithm inside a class *

NSLayoutMananger NSFormatter?

*TemplateMethod Defer the exact steps of an algorithm to a subclass *

*Visitor Defines a new operation to a class without change *

Cocoa Unique Patterns

*Target/Action A variation/simplification of the Command pattern *

NSControl NSActionCell @selector Similar to Qt Signals & Slots

*Method Swizzling A technique for runtime modification of the relationship between message selectors and the implementation that will be called in response to a message *

*Delegation Enable one object to control, modify, or specialize the behavior of another object through a loosely coupled interface.

This is really an example of the Strategy design pattern. In fact if you look at the “Application” algorithm implemented as a Strategy in Rob Martin’s Agile Principles, Patterns, and Practices you see NSApplication + AppDelegatereproduced almost exactly.

Reference : Source Here

iConcepts: Design, Architecture ,OOD and SOLID Programming (Snap Shots)

 Design, Architecture ,OOD and SOLID Programming (Snap Shots)
Hi Friends :
In practice, you will often find it difficult to differentiate architecture from detailed design”. And also adds: “You will not be alone, since experts generally agree about the broad strokes of architecture but disagree about the fine details, such as where architecture stops and detailed design begins”. Others say that architecture refers to high level details, and Design to low level details.
Where is the line that clearly separates what is Architecture and what is Design? Where Architecture stops and where Design begins? If you are presented with any kind of software diagram, is that Architecture or Design? Also, I have read about Modular Design and Modular Architecture, same concept with a different title, which one is the most appropriate? I will try to answer these questions.
The rule that I think we should use is: If the elements of a software diagram can be mapped one to one to a programming language syntactical construction, then is Design, if not is Architecture.
So, for example, if you are seeing a class diagram or a sequence diagram, you are able to map a class and their relationships to an Object Oriented Programming language using the Class syntactical construction. This is clearly Design. In addition, this might bring to the table that this discussion has a relation with the programming language you will use to implement a software system. If you use Java, the previous example applies, as Java is an Object Oriented Programming Language. If you come up with a diagram that shows packages and its dependencies, that is Design too. You can map the element (a package in this case) to a Java syntactical construction.
Now, suppose your Java application is divided in modules, and each module is a set of packages(represented as a jar file deployment unit), and you are presented with a diagram containing modules and its dependencies, then, that is Architecture. There isn’t a way in Java (at least not until Java 7) to map a module (a set of packages) to a syntactical construction. You might notice that this diagram represents a step higher in the level of abstraction of your software model. Any diagram above (coarse grained than) a package diagram, represents an Architectural view when developing in the Java programming language. On the other hand, if you are developing in Modula-2, then a module diagram represents a Design.
As a final more obvious example, a diagram that represents a layered style system, it is clearlyArchitecture. There is no way to map the element (layer) to a syntactical construction in any programming language (at least that I’m aware of).
The rule above is applicable to the activity too. If you are creating a Class diagram, then you are working on the Design of your software. And if you are creating a layered picture, then you are working on the Architecture of your software.
Reference Here :Resources
 Books References :
1.Software Architecture. Foundations. Theory and Practice.Taylor, Medvidovic and Dashofy.
2. Just Enough Software Architecture. A Risk-Driver Approach. George Fairbanks.
 10 Ways to improve your Software Architecture Design (By : Patrick Kalkman) 
Reference Source : Read Here
You can improve the quality of your Software Architecture Design by using the following 10 tips. I use these 10 tips or guidelines daily and they have helped me creating high quality Software Architectures. Describing your software architecture design is useful for any type of project, it will share the design of the system among your stakeholder.
My 10 ways:
  1. Based on non functional requirements

  2. Rationale, rationale, rationale

  3. Don’t Repeat Yourself

  4. Slice the cake

  5. Prototype

  6. Quantify

  7. Get it working, Get it right, Get it optimized

  8. Focus on the boundaries and interfaces

  9. The Perfect is the enemy of the Good

  10. Align with your stakeholders

1. Based on requirements
You should base your software architecture design on the requirements of your stakeholders. An architecture focuses on the non-functional requirements. I see many software architecture designs based on purely technical motives. Each part of your design should be based on business requirements. You as an architect should translate these requirements into the right architectural design decisions. If the stakeholder valuesmaintainability, you could use the layer pattern to separate several parts of the application. If performance is important, maybe layering is not a good solution. An exhaustive list of non-functional requirements can be found at ISO 9126 and at QUINT. If you do not use Non-functional requirements in your organization but want to introduce them,  take a look at this post.
From the Non-functional requirements or quality attributes you have to create the right design. While you could create this from scratch there are many examples in the form of design patterns or architectural patterns. A design or architectural pattern expresses a relation between a problem and a solution. Although we often think that our problem is unique this is often not the case. If you take a step back you will see that many of our problems already have been solved using existing patterns. Two books that I can recommend are “Pattern-Oriented Software Architecture” and “Design Patterns”. Both books contain a catalog patterns. Each pattern describes the problem it solves and in which context it can be used. There are also many online pattern source on the web such as this one on Wikipedia and this from The OpenGROUP
2. Rationale, rationale, rationale
The most important aspect of your architecture description is the recording of your rationale behind yourdesign decisions. It is important for a reader of the architecture description to understand the reason why you made a specific decision. Make your assumptions explicit and add them to the description. Assumptions may be invalid now or later but at least it will be clear how you came to that decision. It make communicating with your team (you do communicate do you?) that much easier if you share you rationale.
Note that recording your rationale become much easier if your non-functional requirements are explicit. It will be much clearer if you describe that you created several components to increase the testability because testability is the most important requirements. Do describe the Why and How in your software architecture design!
3. Don’t Repeat Yourself (DRY)
Don’t Repeat Yourself (DRY) or Duplication Is Evil (DIE) come from software-engineering in general. The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”. You can apply this principle on many levels; Architecture, Design, Testing, Source Code and Data. For me this is one of the most difficult things to uphold. You have to fight the repetition because it will slow you and your project down. The difficult part of this Repetition Creep as I call it is that it is introduces very slowly. The first repetition won’t hurt you directly, it will even gain some time. You are able to release the first version of the application somewhat quicker, but as I found it always shows up later and makes something elsemore difficult. At that moment you regret the decision to introduce repetition.
If you absolutely must add another copy of information make sure that you automatically generate that copy of the information. It will make your live so much easier in the future. One thing that helps to fight repetition is to store the data where it belongs. This seems logical and is the basis of object oriented design but I often see thisviolated with regards to system architectures. For example take packaging an application for deployment. The process in which you filter the build of your software to include the components that are necessary in a package. Where would you store the information which component should be included in the package? You could create a list that includes the names of the components that should be packaged. That means you introduce your firstrepetition! You now have two places where component names are mentioned. A better solution would be to add that information to the component itself.
When the first list in any format shows up in or around an application, alarm bells should sound and you should be on the lookout for repetition!
4. Slice the cake
I struggled with naming this, but found Slicing the cake as it is called in Agile development the best description. By slicing the cake I mean that you design your architecture iterative in vertical slices. An architect implements or prototypes each vertical slice to confirm if it actually works. You should do this because architectures cannotbe created on paper. It does not mean that you cannot use horizontal layering or any other pattern in your architecture. In the case of layering the horizontal layers are smaller. The picture below shows the principle.
Say you use layering in your architecture design because your stakeholders expect that the components that you develop for this system will be used in other systems as well. During the first iteration you design a small part of the User Interface (UI), a small part of the Business Layer (BL) and a small part of the Data Layer (DL). You make sure that this works as expected by proving it with a prototype or by actually implementing it. In the second iteration you add new functionality and expand each layer horizontally with the needed functionality. The existing UI, BL and DL are combined with the new UI, BL and DL to form the new layers.
The difficulty with slicing is how to slice the cake so that the next slice will properly align with the previous.
5. Prototype
When creating a software architecture design make sure that you prototype your design. Validate your assumptions, do that performance test and make sure that the security architecture is valid. A prototype will give you the opportunity to fail fast which is a good thing.
6. Quantify
This principle extends the first principle “Based on Requirements”. To be able to create a proper software architecture design you need to quantify your Non-functional requirements. It should be “fast” cannot be a requirement neither is maintainable or testable. How will you know if you have met these requirements? You won’t.
ISO 9126 and QUINT both describe ways to quantify the non-functional requirements. For example testability specifies an indicator “number of test cases per unit volume”. QUINT also specifies how you can actually measure an indicator for example the indicator “Ratio Reused Parts” from the quality attribute Reusability which you can measure using the following protocol:
  1. Measure the size of each reused part;

  2. Measure the size of the entire software product;

  3. Calculate the ratio of reused parts, which is the sum of reused parts divided by (2).

7. Get it working, Get it right, Get it optimized
In many projects I have seen architects and developers design software architectures that focus on creatinggeneral purpose libraries, services or infrastructure. These are created without a direct reference to aconcrete application. Instead they are designing for tomorrow. This for me is like walking backwards, generality cannot be designed up-front. If you think, well… stop! you actually can’t. Today’s businesses changeway too fast to design for generality up-front.
You should always start with a concrete implementation for a specific problem. At the time you start working on the next application and find similarities, that’s the time to think about generalizing. This makes the first solution simpler, which should be your design goal.
8. Focus on the Boundaries and Interfaces
When creating your software architecture design you should focus on the boundaries of your system and components. When starting blank you should think about separation of concerns. What component or system has which responsibility? Between the components or system design explicit interfaces. Don’t separate a system of component when a lot of communication is necessary between these components or systems.
9. The Perfect is the enemy of the Good
The phrase “The perfect is the enemy of the good” from Voltaire is also valid for software architecture design. How many times have you started a new project and thought I want this project to be perfect? And how many times have you actually found out that the project wasn’t perfect. Well, guess what – a project will never be perfect. There will always be problems or forgotten requirements.
Perfection is never possible. However you are able to create a good software architecture design. Do not try to analyze everything during the start of the project it will slow you down. Watch out for Analysis Paralysis.
10. Align with your stakeholders
Before you can create any type of system you need to identify your stakeholders. Each stakeholder has different needs of your software architecture and may require a different view. Software developers may need descriptions using Unified Modeling Language (UML) while business sponsors need a description in natural language. Operations and support staff for example may need other view such as context diagrams.
There is a tension between creating all these views for stakeholders and principle 3. Don’t Repeat Yourself. Each view essentially describe the same system and adds repetition. Therefore you should only add those descriptions that adds value for a specific stakeholder.
I explained SOLID Software development. SOLID is an acronym that stand for five principles for object-oriented development. SOLID stands for Single ResponsibilityOpen ClosedLiskov SubstitutionInterface Segregation and the Dependency Inversion Principle.
These principles can help a software developer manage dependencies between software components. Bob Martin the author of the principles writes So dependency management, and therefore these principles, are at the foundation of the -ilities that software developers desire”. You can read the original article here.
References : 1) Principle of OOD’s 2) Architecture VS Design 3) ARCHITECTURE ROLES AND RESPONSIBILITIES Read Here
Well there you have it, my 10 tips to improve your Software Architecture Design, SOLID and OOD Programming. If you have another tip that you use to improve your architecture design and other topics which discussed here. Welcome to hear your comments.
Thanks 🙂 Keep Coding 🙂



iConcepts: IT Architects : Type and their Role

IT Architects : Type and their Role

In this blog we’re going to cover the type, layer and role of the IT architects by keeping about the various types of architecture that theIASA maintains and follows. IASA is the premier association focused on the architecture profession through the advancement of best practices and education while delivering programs and services to IT architects of all levels around the world. As we already know the role of architects, i.e., architect defines the architecture. It applies to various aspects of IT systems development and base platform designs methodology.
Consider the various types of architecture lists:
The term “technical architecture” is a common first attempt to describe architecture but without the need to be specific about what type of architecture you’re referring to. Therein lies a failing when using this term: it is too unspecific to be particularly meaningful when discussing a responsibility or project and business requirement.The technical architects are broadly divided into:
  • Enterprise Architect
  • Software Architect
  • Infrastructure Architect
  • Information Architect
  • Business Architect
In addition, we do have others architects in queue which plays important role into the IT operations.They are:
  • System/Product architect
  • Domain Architect
  • Solution Architect
  • Applied Architect
Based on the above architects list and their respective characteristics, the types of architects shall be divided broadly into the businessand technical architects (Please refer below diagram). But, before that we would discuss about the summary of above listed architects:
System Architect: “System architect” refers to the way in which desired functionality is met by hardware and software components as well as how these components relate to each other and the intended users of the system. The term “architecture” is often generically used to refer to the system architecture, at least within the context of software systems development. They have equal strength in the both technical and business area. Plays a vital role to bring all the stake holders together and ensure all the stake holders concern’s are captured methodologically, formally documented and validated. Assist the project manager to make the management decision and makes key technical decision for the project/system/product. Brings all the technical architects, development teams, system analyst, and support teams together to ensure the cohesive architecture is defined to meet the stake holders concern and ensures the defined architecture is implemented. The system architecture validation is done by using the user case scenarios. +1 view of the architecture. The architecture verification is done through reviews.
Domain Architect: “Domain architect” responsible for the architecture solution for that domain which comes under generic, organizational structure or design for software systems. The domain architecture contains the designs that are intended to satisfy requirements specified in the domain model. A domain architecture can be adapted to create designs for software systems within a domain and also provides a framework for configuring assets within individual software systems. The domain architect is an abstract  definition and there are various domain architects. The domain architects specific to the web
development projects are
  • Application architect
  • Data architect
  • Information architect
  • Integration architect
  • Security architect
  • IT Process architect
  • Infrastructure architect
    • Network architect
    • Server architect
    • Web run time architect
Solution Architect: A “Solutions architect” in Information Technology Enterprise Architecture is a practitioner in the field of Solution Architecture. Solution architecture team is the set of specialist working together to research and seek solutions for a specific problem.The role title has a wider meaning in relation to solving problems, but is more often used in the narrower domain of Technical architecture – the context for the remainder of this definition. In this context, the Solutions Architect is a very experienced architect with cross-domain, cross-functional and cross-industry expertise. He/she outlines solution architecture descriptions, then monitors and governs their implementation.The role of “Solutions Architect” requires the knowledge and skills that are both broad and deep. To be effective the Solutions Architect must have experience on multiple Hardware and Software Environments and be comfortable with complex heterogeneous systems environments.
Applied Architect: “Applied architect” provides practical guidelines and techniques for producing quality software designs. It gives an overview of software architecture basics and a detailed guide to architecture design tasks.The applied architects have the known set of problems, solution and context. The architectural patterns are applied to the system or product. The architectural patterns includes to the process solution or methodology for the implementation and its style.
Software Architect: “Software architect” mainly focused for developers is aimed at software developers that want to learn more about software architecture as well as those that are new to the role. It fills the gap between software development and high-level architecture that probably seems a little “enterprisingly” for most developers.
Information Architect: “Information architect (IA)” is the art and science of organizing and labelling websites, intranets, online communities and software to support usability. It is an emerging discipline and community of practice focused on bringing together principles of design and architecture to the digital landscape. Typically it involves a model or concept of information which is used and applied to activities that require explicit details of complex information systems. These activities include library systems and database development. Information architecture is a specialized skill set that interprets information and expresses distinctions between signs and systems of signs. More concretely, it involves the categorization of information into a coherent structure. Typically this is required in activities such as library systems, Content Management Systems, web development, user interactions, database development, programming, technical writing, enterprise architecture, and critical system software design. Information architecture originates, to some degree, in the library sciences.
Application Architect: “Application architect” is really a subset of the system architecture. The scope of the application architecture, as opposed to the system architecture, is often determined by business function. It is typical for the application architecture to be defined to a lower level than the system architecture, particularly as it needs to refine the system architecture to provide the design decisions that relate specifically to the business function rather than to the system as a whole.
Enterprise Architect: The term “Enterprise architecture (EA)” is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolutionEA are responsible for defining the holistic architecture solution for the entire enterprise. However, enterprise architecture is more concerned with mapping the business processes and needs to the technical capabilities of the organization, including personnel, strategy, distribution and how the business’ changing needs will be met. The enterprise architect role is therefore extremely wide-reaching, being enterprise-wide, and requires careful inspection of all the business’ functions and their strategic requirements. Many people may contribute to the enterprise architecture, but that doesn’t make them responsible for it and thus doesn’t make them enterprise architects.
Refrence Source : Here

Thanks 🙂 Keep Coding 🙂