Article:		What Is Service-Oriented Architecture
Subject:		CD analogy
Date:		2004-11-09 13:45:40
From:		_nyirenda
I dont agree with your object oriented example of a cd having to play itself. The way I have seen it done; and the way I have always done it is to seperate concerns. So I would pass my cd object to a cd player object and he does the business of playing the cd. SOA is an extension of this concept but done in a distributed and federated manner and across process boundaries. Joseph Nyirenda

Previous Message

Next Message

• CD analogy
  2004-12-20 08:26:22 spamnomag [Reply]
  
  I must agree. In OO objects are responsible for their own state. That does not imply that for each instance of data you wish to process, you need a dedicated instance of an object to process it. If there is some extra data the player needs to play the CD (like track number, position of read head, etc) the player is responsible for maintaining that data and it should not be directly manipulated by external objects. The CD itself, which is the payload of a "play" message to the player, could be considered transient state for the player, and (typically) should not be manipulated by external objects while it is being played by the player. So in a sense OO says objects "encapsulate data" as apposed to the data being permanently bound to the object.
  
  
  
  • CD analogy
    2005-11-22 03:00:10 MuhammedShakir [Reply]
    
    Excellent explanation defending OO approach. You have perfect knowledge of OO
    
    
  • CD analogy
    2005-02-23 16:19:06 idol [Reply]
    
    Maybe I'm missing the point here about OO but I thought there was a clear seperation between the Class (the code, the player) and the instance (the data or CD). There is only 1 class and 1 copy of the code, but there are many sets of data. You can serialize the data out (take the CD out of the player) and transfer it to another player that accepts the serialized stream (put the CD in a DVD player or another brand) I will agree that there has not been a lot of work on standardizing the serialized stream of objects but that is the same as the RPC argument around SOAP. The implementation of OO in Java and C++ is only very basic compared to the original OO architecture and languages like SmallTalk. History repeats itself and we are re-inventing some of the original principles of OO just using XML to serialize data. The fundamental problem that we don't understand the meaning of the data outside of the object is not solved by SOAP but hinted at with REST: include a description of the data in the message. However we will overlook that feature since we all now what the data means.... have another Tui (Which here in NZ means Yeah Right! See it does help to explain.)