Skip to Content.
Sympa Menu

patterns-discussion - [patterns-discussion] Live or Animated Object Design Pattern

patterns-discussion AT lists.cs.illinois.edu

Subject: General talk about software patterns

List archive

[patterns-discussion] Live or Animated Object Design Pattern


Chronological Thread 
  • From: Messaging Design Pattern <dsheppard2k AT yahoo.com>
  • To: gang-of-4-patterns AT cs.uiuc.edu, patterns-discussion AT cs.uiuc.edu, telecom-patterns AT cs.uiuc.edu, ipc-patterns AT cs.uiuc.edu
  • Subject: [patterns-discussion] Live or Animated Object Design Pattern
  • Date: Sat, 16 Apr 2011 20:05:18 -0700 (PDT)
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/patterns-discussion>
  • List-id: General talk about software patterns <patterns-discussion.cs.uiuc.edu>


Dear List members,

Please find enclosed a link to a draft discussing the Live or Animated object design pattern:

http://java.net/projects/jt/downloads/download/Papers/MDPAnimated.pdf

Any feedback would be appreciated. This draft also includes additional information about asynchronous concerns, best practices and implementation considerations.

Regards,
Al

Live or Animated object design pattern

Intent: This design pattern encapsulates component functionality, processing (threading) mechanism and the messaging functionality required to provide the component with independent behavior (a “live of its own” so to speak). This also means that the component uses its own independent processing mechanism or thread of execution. This design pattern improves decoupling, encapsulation and scalability while at the same time reducing complexity and overall implementation cost. Component functionality, processing/treading mechanism and messaging mechanism are decoupled entities, independent of one another. MDP messaging [2] allows the interchange of information (i.e. messages) between the animated component and other components or applications. Although decoupled and independent of one another, processing/threading mechanism and component functionality are completely encapsulated within a single entity: live or animated object.

 

Motivation: The implementation of traditional multithreaded applications is a complex undertaking which usually becomes costly, time consuming and prone to error. Defects related to are often encountered (thread management, synchronization, race conditions, deadlocks, etc). These software defects are difficult to avoid, reproduce and isolate.  Large multithreaded applications complicate the problem even further. The degree of complexity and risk considerably worsens as the number of threads and their interactions increases. Object oriented applications consist of a collection of components that interact with each other. In reality, some of these components should be modeled as live or animated components: They exhibit independent behavior, a “life of their own”......




Archive powered by MHonArc 2.6.16.

Top of Page