As a followup on my Wednesday lecture on design patterns, I wanted to post some informative resources for learning more about design patterns outside the next lecture on the topic. Also, I wanted to say thanks for everyone who showed up to hear me rant about code structure (not the most exciting topic in the world mind you)!

Design Pattern Definition
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
- read more at WikiPedia

MVC Definition (the most common principle of Design Patterns)
mvc
“Model–View–Controller (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the model represents the information (the data) of the application; the view corresponds to elements of the user interface such as text, checkbox items, and so forth; and the controller manages the communication of data and the business rules used to manipulate the data to and from the model.”
- read more at WikiPedia

Books:

AS3 Design Pattern Informational Websites:

Flash Design Pattern Frameworks:
(for now, it’s best to avoid these until you understand the fundamentals of MVC)

Good Design Priniciples:

  • ALWAYS type your variables (not really design principle but I too often see people doing this still)
  • An object/MovieClip should contain the actions that it performs (as oppose to objects outside the class forcing it to perform actions)
  • A class should never be able to “break” if the user sets a property or calls a function on it when they are not suppose to. Keep preventive logic in the class that’s doing the work.
  • A good chosen design pattern for a problem will not take any longer to implement than not using it with spaghetti code.

Feel free to leave comments or email me about any further questions you have about Design Patterns or where to find additional materials on it. Have a great weekend everyone!


Author: Jonathan Dunlap
Jonathan is a veteran software architect, author of IsoHill, humanitarian, and has worked with Bigpoint Inc, CrowdStar, ePrize, and Microsoft.
Be Sociable, Share!

1 Comment
Android, Flash/Flex/AIR, Game Development, General Programming, Lifestyle, Showcase