<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Query7 &#187; Design Patterns</title>
	<atom:link href="http://query7.com/tag/design-patterns/feed" rel="self" type="application/rss+xml" />
	<link>http://query7.com</link>
	<description>PHP, Javascript, Python and Web Development</description>
	<lastBuildDate>Sat, 25 Jun 2011 21:29:51 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
		<item>
		<title>Yes, I&#039;m an OOP developer! But Design Patterns?!?</title>
		<link>http://query7.com/yes-im-an-oop-developer-but-design-patterns</link>
		<comments>http://query7.com/yes-im-an-oop-developer-but-design-patterns#comments</comments>
		<pubDate>Wed, 22 Oct 2008 13:16:34 +0000</pubDate>
		<dc:creator>Ramses Paiva</dc:creator>
				<category><![CDATA[Programming]]></category>
		<category><![CDATA[Design Patterns]]></category>
		<category><![CDATA[Design Principles]]></category>
		<category><![CDATA[Object-Oriented Programming]]></category>

		<guid isPermaLink="false">http://www.webdevelopmentbits.com/?p=39</guid>
		<description><![CDATA[<p><em>&#8220;Well, I went pretty fine on my Object-Oriented experience. I&#8217;ve learned something about polymorphism, inheritance, encapsulation and now I really know how to extend a class! I&#8217;m ready for developing cool object-oriented applications.&#8221;</em></p>
<p>But what about the design? No, no&#8230; I don&#8217;t mean that design where you place the squares and circles in their places, draw lines, beautiful backgrounds and all those kind of stuff. I&#8217;m talking about Software Design. Design in terms of objects. Which objects to use, how and when to use, how the hierarchy would look like, which object should extend which object, when to encapsulate, when not.</p>
<p>It&#8217;s very common for developers to misunderstand Object-Oriented Programming with its basis concept (abstraction, inheritance, encapsulation, polymorphism, interfaces). Only because you know how to extend a class doesn&#8217;t mean that you really understand Object-Oriented Programming. It&#8217;s quite more than this.</p>
<p>First, let&#8217;s start with Design Patterns. Design Patterns are proven reusable solutions to solve a software design problem that other developers already faced before you. It&#8217;s not a kind of pre-cooked cake, where you just need to put in your heater for some time to get it done, but a description or template for how to solve a problem&#8230;</p>]]></description>
			<content:encoded><![CDATA[<p><em>&#8220;Well, I went pretty fine on my Object-Oriented experience. I&#8217;ve learned something about polymorphism, inheritance, encapsulation and now I really know how to extend a class! I&#8217;m ready for developing cool object-oriented applications.&#8221;</em></p>
<p>But what about the design? No, no&#8230; I don&#8217;t mean that design where you place the squares and circles in their places, draw lines, beautiful backgrounds and all those kind of stuff. I&#8217;m talking about Software Design. Design in terms of objects. Which objects to use, how and when to use, how the hierarchy would look like, which object should extend which object, when to encapsulate, when not.</p>
<p>It&#8217;s very common for developers to misunderstand Object-Oriented Programming with its basis concept (abstraction, inheritance, encapsulation, polymorphism, interfaces). Only because you know how to extend a class doesn&#8217;t mean that you really understand Object-Oriented Programming. It&#8217;s quite more than this.</p>
<p>First, let&#8217;s start with Design Patterns. Design Patterns are proven reusable solutions to solve a software design problem that other developers already faced before you. It&#8217;s not a kind of pre-cooked cake, where you just need to put in your heater for some time to get it done, but a description or template for how to solve a problem that can be used in many different situations (Yeah! Now, we&#8217;re starting talking about OOP).</p>
<p>To be a great OOP developer, this is the prior thing to know: Design Patterns will take you in another level of development principles, well designed applications and the truly implementation of Object-Oriented Programming. You&#8217;ll be able to understand each property of the OOP concept and how to correctly apply it in a way to improve the quality of your application design and, consequently, of your software. More than that, you&#8217;ll be able to use most of your objects in your future projects, saving time of development.</p>
<p>Once you went through the Design Patterns and you already know all about Design Principles, it&#8217;s time to understand the needs of your customer. What?! Did You think it was just plan a good design, put objects in place and write some code?? No way! How are you going to do that if you don&#8217;t even know what your customer expects from your software? Talking about that, do you even have a customer? Here is where the Object-Oriented Analysis and Design (OOA&amp;D) comes in place! The first thing you need to start developing a software is the customer, even if the customer is yourself! The software starts with your customer&#8217;s great idea! Before getting into design and code, you need to collect their idea and try to deeply comprehend it to make it to become a great software that does exactly what your customer expects it does. To accomplish this, you need to apply some OOA&amp;D techniques.</p>
<p>Ohh! You already have a customer! So, start collecting requirements! A requirements list is one of the most important artifacts on software development. It represents all the expectation of what the software should do and all the requirements are provided by not anybody else than your customer (that person that is going to afford your hours of development). A requirement is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user <sup>[<a href="#Requirements">1</a>]</sup>.</p>
<p>With your requirements in hands, you can develop all other artifacts to develop your software, like Use Cases, Sequence Diagrams, Class Diagrams, Database Diagrams, define estimates and costs and divide the requirements in tasks to be assigned to everybody involved in the software development.</p>
<p>After having your well-designed software and your code written it&#8217;s time to test! Yes, test it before your customer does it and realizes that some functionality is not working properly (Hmm&#8230; a bug! Or a few of them??). There are some test techniques that can avoid these situations and provide reliable reports that prove that a particular functionality is working fine. One and the most known of them is the Unit Testing. Unit Testing&nbsp;is a method of testing that verifies if individual units of your source code are working properly. The most popular programming languages have Unit Testing frameworks to help you testing your software, standardized by the ANSI/IEEE Std 1008-1987 <sup>[<a href="#UnitTesting">2</a>]</sup>.</p>
<p>Now you have all this powerful knowledge in hands, you can say loud to everyone hears you: &#8220;Yes, I&#8217;m a GREAT OOP Developer!&#8221;</p>
<p>After going through the principles of OOP, Design Patterns and OOA&amp;D, you&#8217;re ready to design, develop and deliver really GREAT software and make your customers happy, providing exactly what they want at the time they want and with a budget that they can afford.</p>
<p>Very good books that can help you to acquire this knowledge are the <em>Head First</em> series <sup>[<a href="#HeadFirst">3</a>]</sup> (<em>Head First Software Development, Head First Object-Oriented Analysis &amp; Design</em> and <em>Head First Design Patterns</em>), the famous <em>Design Patterns &#8211; Elements of Reusable Object-Oriented Software</em> <sup>[<a href="#DesignPatterns">4</a>]</sup> and <em>Effective Requirements Practices</em> <sup>[<a href="#Requirements">1</a>]</sup>.</p>
<div id="Requirements" style="font-size:9px">1. Young, Ralph R. <em>Effective Requirements Practices</em>. Boston: Addison-Wesley, 2001. See also <a class="external text" title="http://www.ralphyoung.net" rel="nofollow" href="http://www.ralphyoung.net/">RalphYoung.net</a>, a website devoted to requirements-related topics.</div>
<div id="UnitTesting" style="font-size:9px">2. IEEE Standards Board, &#8220;<a href="http://iteso.mx/~pgutierrez/calidad/Estandares/IEEE%201008.pdf">IEEE Standard for Software Unit Testing: An American National Standard, ANSI/IEEE Std 1008-1987</a>&#8221; in IEEE Standards: Software Engineering, Volume Two: Process Standards; 1999 Edition; published by The Institute of Electrical and Electronics Engineers, Inc. Software Engineering Technical Committee of the IEEE Computer Society.</div>
<div id="HeadFirst" style="font-size:9px">3. <a href="http://www.headfirstlabs.com/">Head First Labs from O&#8217;Reilly Media, Inc.</a></div>
<div id="DesignPatterns" style="font-size:9px">4. Gamma, Erich; Helm, Richard; Johnson, Ralph; and Vlissides, John (or simply the Gang of Four &#8211; GoF). <em>Design Patterns &#8211; Elements of Reusable Object-Oriented Software</em>. Boston: Addison-Wesley, 1994. See also <a href="http://hillside.net/patterns/DPBook/DPBook.html">Hillside.net</a></div>
]]></content:encoded>
			<wfw:commentRss>http://query7.com/yes-im-an-oop-developer-but-design-patterns/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

