Passing objects around is allowing me to write type checking code. It's a great way for me to immediately get errors when inputs are not what my methods are expecting. I am also playing with the idea of a common object language. It's something my colleague brought up in an architecture meeting. A common object language is a way of defining the data objects passing between functions, methods, and classes of a module of code. By using these two conventions I am more clearly defining the interactions between functionally separate code. This works great within an application or module.
However, it does not work well outside of that context, in implementations such as SOAP. I am calling out SOAP because it is vying to use a similar notion of defining a common object, but in between services, rather than functional blocks. SOAP is doing us a service by providing well defined data types and giving early warning signs of type mismatches and improper use of methods. However, I am finding that the benefits, of SOAP's strong *(moderately strong) typing, are getting in the way of efficient coding. They are cumbersome, because they need to be replicated on the client system. I am going to be responsible for providing the objects to fulfill the object language, for a language I don't fully understand. I feel as if I am writing the dictionary so I can speak a sentence. It feels very heavy.
For that reason I feel that a common object language is best suited within a controlled environment, and that simple more flexibly interpreted forms of data should be used between services: Thing JSON. This kind of data leaves the client to form it's own understanding of the data, which is good. JSON s working better for me because, I no longer have to meddle with parts of the data I don't care about. Since I can;t control the source of the data, I want to maintain control of how I consume it.