Monday, December 13, 2010

Design Patterns - An eye for similarities - Part 3

Decorator Pattern - Wrap me, my brother


WHAT IS DECORATOR PATTERN?

The decorator pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub-classing for extending functionality.
Typically, the decorator pattern essentially adds a wrapper around a class to add additional capability to it.

HOW DOES IT WORK?

This pattern works on the principle of "Open for extension, closed for modification".
So, when we need to add additional capability to the existing object we don't modify the parent class to do that, but make a new class and wrap the existing object in this new class that provides the necessary capability.
For eg. we have a class Mammal and we want to add functionalities to create a Human. We just create a new class HumanDecorator that takes in the Mammal as an object and adds the necessary intelligence into it, thus eliminating the need to change Mammal as a whole. The thing to note here is that both the Mammal and the HumanDecorator class should have the same type. This is done to maintain the extensibility.

Part 4 - Factory Pattern

Sunday, December 12, 2010

Design Patterns - An eye for similarities - Part 2

The Strategy Pattern - Divide and Rule

WHAT IS STRATEGY PATTERN?
The strategy pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. The strategy pattern lets the algorithms vary independently from clients that use them.[Taken from Wikipedia]

HOW DOES IT WORK?
In essence, all the strategy pattern says is to identify the things in the application that can change (verbs) in the application and separate it from the things that don't (nouns).
Generalize the verbs into a family of interfaces and create encapsulations for each of them which form the concrete classes.
E.g: [ From the book - Head First Design Patterns]



The Observer Pattern - Tell me, I'll let you know

WHAT IS OBSERVER PATTERN?
The observer pattern defines a one to many dependency between objects so that when one object changes state, all of it's dependents are notified and updated automatically.

HOW DOES IT WORK?
The Observer Pattern consists of a publisher that publishes events and subscribers that subscribe to that event. Thus, in effect, it helps makes the system loosely coupled by providing an interface for 2 objects to talk without actually having to maintain any relationship.
For example in a shopping application the stock manager and the sales manager would have subscribed to the event on the click of the "BUY" button on an inventory. Thus the cart might fire an event saying that a particular inventory has been bought. The sales and the stock manager having subscribed to the event get notifications to process the information furthur.

Related:
Part 3 [Decorator Pattern]
Part 4 [ Factory Pattern ]

Design Patterns - An eye for similarities - Part 1

Almost in every software that we built there are a lot of algorithms and rules that tend to beat around the same bush. Obviously a lot of people before us have found that out and have wondered on how some generic solutions could built for them so as to make life a bit simpler. The result of this was Design Patterns. In this multi-part series we'd be look at them patterns, how they help in finding bottlenecks and how to get around them.

So how do we find on where to use patterns?

This for most people is the toughest part. And true sometimes it is really confusing. But with careful thought and proper application I think we can definitely get to a point where we recognize them with ease.
- First and the foremost read through the requirements. Very important.
- Ask questions and lots of them. The more clear you are on the requirements, the better you can visualize the system.
- Find out all the "is-a", "as-a" and "has-a" relationships. This helps you in building up the hierarchy, interfaces and abstractions.
- Have a thorough knowledge of the existing design patterns and go through loads of examples to understand the nuances with each.
- Also a familiarity with anti design patterns does not hurt either.


Hope this gives a basic idea of what to do when getting ready to design applications. :)
Happy Designing.. :)

Related:
Part 2 [Strategy and Observer Patterns]
Part 3 [ Decorator Pattern ]
Part 4 [ Factory Pattern ]

Sunday, November 21, 2010

MySQL errno:121

If some one has come across this error, do not fret. It's really simple to fix this. This error just says that in the schema, there are 2 or more tables with the same index names. Just changing the index names to be unique fixes this. :)

Wednesday, November 10, 2010

Database Naming

Generally designing a DB can definitely be overwhelming and more so when there are a lot of tables that need to be created to put the work-flow in order.
At such a point of time naming your tables can be a bit hectic. Also when you tend to explain the design to an external person it can be bit problematic as to relate the tables to the business logic.
One method that I did learn recently was to associate your tables with the business elements. For example of you have a business element, say a User then started all the tables related to the user with a "U_" tag can be helpful in presenting the model.
e.g. U_User or U_Role etc.
Hope this helps someone.

Wednesday, June 30, 2010

Incompatible Override Error

A lot of times when I extend the UIComponent and override the createChildren method I get a compiler error "Incompatible Override".
As strange as it may seem the solution is very simple although one might struggle to find it..

SOLUTION

Very simply just clean your project and lo and behold... the errors gone..

Hope this helps someone..

Cheers..

Thursday, May 13, 2010

ReferenceError: Error #1065 in getDefinitionByName()

The Problem:

Getting a ReferenceError: Error #1065: variable {className} not found in the getDefinitionByName()

The Solution:

Define a variable of the class being referenced in your main application

The Explanation:

Flash Player when compiling does not compile all the classes. It leaves out some of them which are not referenced in the application. Even though this is useful in the removal of unnecessary code and the reduction of swf size, this becomes a problem when working with dynamic classes. So when we define an object of the class in the main application the compiler then compiles the class into the source, thus removing the error.

Wednesday, March 17, 2010

Enabling Drag Drop in a Chart

Recently I was looking out for some samples to get the drag and drop working in my chart. All the examples that I went through had drag and drop implemented that enabled dragging from one container to another. While it was useful I was not able to find a sample to get drag drop in the same chart. This is a direct result of that. Hope it is useful for someone.

Monday, March 8, 2010

Getting Image Width at Runtime

Recently I ran with some requirements and needed to get the size of an uploaded image in Flex, which led me to getting an insight of the size data that the image stores.

So what we have and usually use is the width/height property of the Image control. This is a property that is explicitly set by the developer. If not set, the property takes the value of the image’s width and height. To find the final size one has to listen to the updateComplete event.

The other property of the image is the contentWidth/contentHeight. This property gives the size of the scaled image based on the scale ratios. Again this can be found if one listens to the updateComplete event.

The final property [the one that I was looking for :)], can be found inside the content property in the image. The image.content contains the unscaled width and height of the original image data. We can access it using the image.content.width/image.content.height property. What's good is that this property is updated on the complete event of the image load.

-- Cheers.