Article:		What Is Service-Oriented Architecture
Subject:		CD analogy
Date:		2004-12-20 08:26:22
From:		spamnomag
Response to: CD analogy
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.

Previous Message

Up

Next Message

• 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.)