CSC/ECE 517 Fall 2012/ch2b 2w69 as: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
(Undo revision 69797 by Aasokna (talk))
Line 31: Line 31:
== References ==
== References ==
<references>
<references>
<ref name = rubytool> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = openclosed_wiki> http://en.wikipedia.org/wiki/Open/closed_principle Open/closed principle </ref>
<ref name = TDD> http://ruby.about.com/od/testdrivendevelopment/a/teststdd.htm </ref>
<ref name = pdf> http://www.objectmentor.com/resources/articles/ocp.pdf "The Open-Closed Principle", C++ Report, January 1996" </ref>
<ref name = BDD> http://www.oreillynet.com/pub/a/ruby/2007/08/09/behavior-driven-development-using-ruby-part-1.html
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx "Patterns in Practice: The Open Closed Principle" </ref>
</ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = Riot-info> http://thumblemonks.github.com/riot</ref>
<ref name = Capybara-README> https://github.com/jnicklas/capybara/blob/master/README.md </ref>
<ref name = MiniTest-Info> http://bfts.rubyforge.org/minitest/ </ref>
<ref name = MiniSpec-example> http://rubysource.com/test-driven-to-distraction/ </ref>
<ref name = testing> E. F. Miller, “Introduction to Software Testing Technology,” Tutorial: Software Testing & Validation Techniques, Second Edition, IEEE Catalog No. EHO 180-0, pp. 4-16 </ref>
<ref name = system-testing> http://en.wikipedia.org/wiki/System_testing#cite_note-ieee-0 </ref>
<ref name = Rspec> http://en.wikipedia.org/wiki/RSpec </ref>
<ref name = Shoulda> http://en.wikipedia.org/wiki/Unit-testing_frameworks_for_Ruby_(programming_language)#Shoulda </ref>
<ref name = capybara-example> http://rubydoc.info/github/jnicklas/capybara/ </ref>
<ref name = previous> http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2e_kt </ref>
<ref name = jasmine-example> http://net.tutsplus.com/tutorials/javascript-ajax/testing-your-javascript-with-jasmine/ </ref>
 
</references>
</references>

Revision as of 06:19, 17 November 2012

The Open/Closed principle

Introduction

In object-oriented programming the Open/Closed principle states,

Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written.

Open/Closed principle is one of the five principles basic of object-oriented design(OOD) which are defined as the S.O.L.I.D.. The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with test-driven development, and is part of an overall strategy of agile and adaptive programming.

Motivation

All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad” design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

Description

Examples

Conclusion

See Also

References

<references> <ref name = openclosed_wiki> http://en.wikipedia.org/wiki/Open/closed_principle Open/closed principle </ref> <ref name = pdf> http://www.objectmentor.com/resources/articles/ocp.pdf "The Open-Closed Principle", C++ Report, January 1996" </ref> <ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx "Patterns in Practice: The Open Closed Principle" </ref> <ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref> </references>

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2012/ch2b_2w69_as&oldid=69798"