• Complain

Alexander Shvets - Design Patterns Explained Simply

Here you can read online Alexander Shvets - Design Patterns Explained Simply full text of the book (entire story) in english for free. Download pdf and epub, get meaning, cover and reviews about this ebook. year: 2013, genre: Computer. Description of the work, (preface) as well as reviews are available. Best literature library LitArk.com created for fans of good reading and offers a wide selection of genres:

Romance novel Science fiction Adventure Detective Science History Home and family Prose Art Politics Computer Non-fiction Religion Business Children Humor

Choose a favorite category and find really read worthwhile books. Enjoy immersion in the world of imagination, feel the emotions of the characters or learn something new for yourself, make an fascinating discovery.

Alexander Shvets Design Patterns Explained Simply
  • Book:
    Design Patterns Explained Simply
  • Author:
  • Genre:
  • Year:
    2013
  • Rating:
    3 / 5
  • Favourites:
    Add to favourites
  • Your mark:
    • 60
    • 1
    • 2
    • 3
    • 4
    • 5

Design Patterns Explained Simply: summary, description and annotation

We offer to read an annotation, description, summary or preface (depends on what the author of the book "Design Patterns Explained Simply" wrote himself). If you haven't found the necessary information about the book — write in the comments, we will try to find it.

Alexander Shvets: author's other books


Who wrote Design Patterns Explained Simply? Find out the surname, the name of the author of the book and a list of all author's works by series.

Design Patterns Explained Simply — read online for free the complete book (whole text) full work

Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Design Patterns Explained Simply" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.

Light

Font size:

Reset

Interval:

Bookmark:

Make
Design Patterns
Explained Simply
Copyright 2013 by Alexander Shvets
SourceMaking, Inc.
http://sourcemaking.com
This ebook is licensed for your personal enjoyment only. This ebook may not be re-sold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each recipient. If youre reading this book and did not purchase it, or it was not purchased for your use only, then please return to SourceMaking.com and purchase your own copy. Thank you for respecting the hard work of this author.
All rights reserved.
Praise for Design Patterns

This book isn't an introduction to object-oriented technology or design. Many books already do a good job of that. This isn't an advanced treatise either. It's a book of design patterns that describe simple and elegant solutions to specific problems in object-oriented software design.

Once you understand the design patterns and have had an "Aha!" (and not just a "Huh?" experience with them, you won't ever think about object-oriented design in the same way. You'll have insights that can make your own designs more flexible, modular, reusable, and understandable - which is why you're interested in object-oriented technology in the first place, right?

Introduction to Design Patterns

Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.

Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.

In addition, patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.

This design patterns is all about class instantiation. This pattern can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done.


  • Creates an instance of several families of classes

  • Separates object construction from its representation

  • Creates an instance of several derived classes

  • Avoid expensive acquisition and release of resources by recycling objects that are no longer in use

  • A fully initialized instance to be copied or cloned

  • A class of which only a single instance can exist

This design patterns is all about Class and Object composition. Structural class-creation patterns use inheritance to compose interfaces. Structural object-patterns define ways to compose objects to obtain new functionality.


  • Match interfaces of different classes

  • Separates an objects interface from its implementation

  • A tree structure of simple and composite objects

  • Add responsibilities to objects dynamically

  • A single class that represents an entire subsystem

  • A fine-grained instance used for efficient sharing

  • Restricts accessor/mutator access

  • An object representing another object

This design patterns is all about Class's objects communication. Behavioral patterns are those patterns that are most specifically concerned with communication between objects.


  • A way of passing a request between a chain of objects

  • Encapsulate a command request as an object

  • A way to include language elements in a program

  • Sequentially access the elements of a collection

  • Defines simplified communication between classes

  • Capture and restore an object's internal state

  • Designed to act as a default value of an object

  • A way of notifying change to a number of classes

  • Alter an object's behavior when its state changes

  • Encapsulates an algorithm inside a class

  • Defer the exact steps of an algorithm to a subclass

  • Defines a new operation to a class without change
Visitor
Intent
  • Represent an operation to be performed on the elements of an objectstructure. Visitor lets you define a new operation without changingthe classes of the elements on which it operates.
  • The classic technique for recovering lost type information.
  • Do the right thing based on the type of two objects.
  • Double dispatch
Problem

Many distinct and unrelated operations need to be performed on nodeobjects in a heterogeneous aggregate structure. You want to avoid "polluting"the node classes with these operations. And, you don't want tohave to query the type of each node and cast the pointer to thecorrect type before performing the desired operation.

Discussion

Visitor's primary purpose is to abstract functionality that can beapplied to an aggregate hierarchy of "element" objects. Theapproach encourages designing lightweight Element classes - becauseprocessing functionality is removed from their list ofresponsibilities. New functionality can easily be added to theoriginal inheritance hierarchy by creating a new Visitor subclass.

Visitor implements "double dispatch". OO messages routinely manifest"single dispatch" - the operation that is executed depends on: the nameof the request, and the type of the receiver. In "double dispatch",the operation executed depends on: the name of the request, and thetype of TWO receivers (the type of the Visitor and the type of theelement it visits).

The implementation proceeds as follows. Create a Visitor classhierarchy that defines a pure virtual visit() method in the abstractbase class for each concrete derived class in the aggregate nodehierarchy. Each visit() method accepts a single argument - a pointeror reference to an original Element derived class.

Each operation to be supported is modelled with a concrete derivedclass of the Visitor hierarchy. The visit() methods declared in theVisitor base class are now defined in each derived subclass byallocating the "type query and cast" code in the originalimplementation to the appropriate overloaded visit() method.

Add a single pure virtual accept() method to the base class of theElement hierarchy. accept() is defined to receive a singleargument - a pointer or reference to the abstract base class of theVisitor hierarchy.

Each concrete derived class of the Element hierarchy implements theaccept() method by simply calling the visit() method on the concretederived instance of the Visitor hierarchy that it was passed, passingits "this" pointer as the sole argument.

Everything for "elements" and "visitors" is now set-up. When the clientneeds an operation to be performed, (s)he creates an instance of theVistor object, calls the accept() method on each Elementobject, and passes the Visitor object.

The accept() method causes flow of control to find the correct Elementsubclass. Then when the visit() method is invoked, flow of control isvectored to the correct Visitor subclass. accept() dispatch plus

Next page
Light

Font size:

Reset

Interval:

Bookmark:

Make

Similar books «Design Patterns Explained Simply»

Look at similar books to Design Patterns Explained Simply. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.


Reviews about «Design Patterns Explained Simply»

Discussion, reviews of the book Design Patterns Explained Simply and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.