Expert Business Objects with Rocky Lhotka
March 8, 2006
Click ARCast: Expert Business Objects with Rocky Lhotka to listen to this ARCast.
Ron Jacobs: Welcome! Welcome, friends, to ARCast. I am your host, Ron Jacobs, coming to you once again with architectural wisdom from the fount; that is, VS Live, San Francisco, where I had a great time talking to many of the speakers there, and on today's show, we are going to hear from, well, the guru of Business Objects, Rockford Lhotka, or Rocky, as we like to call him, as in Bullwinkle and Rocky. No, just kidding, just kidding. I am sure he's heard that a million times.
So, he is, Rocky is, the author of Expert Visual Basic.NET and C# business-object books, which are really just terrific stuff, speaks at many conferences around the world, and just an all-around good guy whose passionate about helping YOU to do the right thing with objects. "Stop putting all that code in your UI, that's a bad idea." Let's give it up for Rocky Lhotka.
Ron: Hi, this is Ron Jacobs, and I am here at VS Live with Rocky Lhotka, who is one of the amazing VS Live speakers, fresh in from the cold North of Minneapolis, or was it cold there?
Rocky: Oh, it was not cold there, we have had an unusually warm winter.
Ron: You are kidding me.
Rocky: No, 57 degrees a couple of days ago.
Ron: That is, that is so bizarre, means I am sure you like all the global-warming people are going, "See! I told you, I told you." [Laughter]
Rocky: And what's funny is, if I fly into San Francisco, its 55, so it's warmer in Minnesota than San Francisco in January.
Ron: That is freaky! Truly freaky.
Well, you know, it had to be like raining here, I have been, you know, it has rained, almost every day for the last six weeks in Seattle, so I am really getting annoyed. [Laughter] I come to sunny California and it's raining here, too. But what can you say? So, alright, but we are here at the most wonderful event in the world, of course, VS Live, and you do lot of the VS Live events, don't you?
Rocky: I do most of them. Really enjoy it. A lot of the people who have attended have come back many, many times even, fly here from all over the world and it's just a good conference and lot of fun people.
Ron: Yeah, I have done a bunch of these, I think, I did four or five of them in the last year and just a few, you know, I didn't go to Vegas. Did you go to Vegas?
Rocky: Umm… No, I did not.
Ron: See. We missed the fun one. [Laughter] 'Cause you know what they say about Vegas, right, well, anyway. We don't want to go there, because my wife might be listening. So, anyway, [laughs] really, I didn't go, really. [Laughter]
Alright, but what are you talking to the folks here at VS Live this week?
Rocky: Well, mostly I am talking about object-oriented design and building distributed systems using objects.
Ron: OK, and isn't that like ancient history now? Haven't we all figured this out? By now?
Rocky: Well, YOU would think so. Everybody wants to use objects and, in fact, if you are not using an object-oriented language like VB or C# in .NET or within… "Bad you," right?
Ron: Yeah, alright. "You are very late, man, you are way out."
Rocky: But yeah, as we said, I speak at a lot of these conferences around the world, and I will often ask the audience I am speaking to that how many people use object-oriented design in their daily work, now when they sit down to build a system, do they really use object-oriented design to design their system? And only about 30 percent typically said that they do. So, that means over half, well over half of the people in the audience are not using object-oriented design to build their applications.
Ron: Well, that's kind of scary because it makes me wonder, you know, if they are not using object-oriented design, what are they doing?
Rocky: Well, Microsoft has this really cool object called the dataset, and dataset lets you go to the database, get all of the data you want into a nice tabular container, and then you can write all of your code, well, behind the UI, actually. Because if you look at both Windows forms and Web forms, again Microsoft has done this really nice job of having a real rich eventing model and nice wrapped tools. So, you can just jump in, double-click on a button, and there comes a code window. Now, this used to be called VB3-style coding, but now you could do the same thing in C#, and most people do. [Laughter] I think, I suppose it's a RAD development, maybe.
Ron: So, so you look in that code behind file, behind, you know, open the button, click, and you find 10,000 lines of code that go off and do a bunch of stuff and connect the databases and deal with datasets and... So, you are using an object-oriented language and you have methods that you are doing, but really not getting into breaking down into the kind of business objects that you have become known for, being the business-objects guy. How did you get known as that, anyway?
Rocky: Um… Well, I guess over the last decade or so, I have been writing books and speaking largely on this topic. This is, this is what I get excited about, it's my area of passion and, and I really am driven, I think, because this model that we are talking about of writing all of this code behind the UI is a flawed model. And everybody seems to know that it's a flawed model, but it's not always clear how to do something else.
And, it's so easy to do… you know, put the code behind the UI and you say, "Well! You shouldn't do that," and people say, "Yes, I know I shouldn't do that and then… But how?" Right! And objects offer an answer, I think this is the real key.
Ron: Speaking of books, you know, I had this idea the other day that, you know, I saw in the news of how big controversy about this guy who wrote the book The Million Little Pieces and he was on Oprah and his book was featured in the Oprah Book Club and I thought, Well, if Oprah can have a book club, I should have a book club. [Laughter] I am going to have Ron's ARCast book club and, you know, so maybe on your next book, if it's good, then it might make my book club. We'll see about that. [Laughter]
Rocky: I hope it's good; it should be out at the end of March. So, you know, it will be coming up soon.
Ron: And, yeah, then maybe all of the ARCast listeners will go out and buy it and, you know, set sales records and make the top 10 lists, and whatever, right? So, that'll be cool.
Rocky: That's what happens with Oprah, right! [cough] And these guys transform their lives. If you can transform my life, I'll go for it.
Ron: OK, as long as you promise not to lie in your book, OK? [Laughter]
Alright. So, but I have never written a book. I have written some magazine articles. But I can't sit still long enough to write a book. That must be tough.
Rocky: It does require a lot of sitting, [laughs] yes.
Ron: Oh, I get an idea and I go and speak at a conference and write a blog post and make an article, and that's about as far as I get.
Rocky: Well, it is true, writing, writing an article can take about a week, two or three weeks, you know, in that range. So, it's a relatively achievable thing. Writing a book is more in a 6- to 10-month range and, yes, it's a pretty big commitment. And I think to write a book, there has to be something you have to be passionate about doing. Books don't make a whole lot of money either, unless you figured on Oprah. But, so it really is a labor of love, I think.
Ron: OK, that is just twisted. [Laughter] You love objects that much and you're just like, Oh, I totally love this.
Rocky: I do. [Laughter] I am sorry, but it's true.
Ron: You are a geek; you are a big-time geek. [Laughter]
Well, that's OK, people love all kinds of everything.
So, so. Well, you know, getting back to this object design idea, you know, I remember when I first learned C++, it was in the early 90s and I was working here in Silicon Valley with a bunch of hardcore C programmers, you know, and they brought in an instructor, we spent two weeks in a classroom and these hardcore C guys had a very tough time, I mean, they really! They can write some great C code, but, but we just start talking about classes and inheritance and polymorphism, and they are just, they couldn't get it.
But, I, now I have been doing it for couple of years and so I got it pretty easy, you know, came like to me naturally, but we have this idea that we wanted to take everything in our system and convert it into objects. And, you know, things like customers and invoices and purchase orders and sales and everything, just, you know.
So, first we made a customer object and then we thought, Well, you know, customers have invoices, so I have an invoices object when you go; I want my customer invoices, so I have customer dot invoices, you know, blah-blah-blah, and so pretty soon you had customer dot invoices dot line address dot this dot that dot the other thing, and then you find that you wanted to get a customer object just because you wanted to display their address and you don't care about the invoices. You got to get the customer object, it takes like three minutes and later you can practice huge object with everything you ever might, you ever want to know about a customer, and you are done. But, didn't work so well.
Rocky: No, it doesn't. [Laughter] I think everybody starts there. And I think it's natural, because all of us spend so much time working with data and understanding how databases work and ER diagrams, and then we start describing objects often in terms of entities. Well, you say customer object is customer entity and then the customer table in the database is a customer entity, and so maybe everything becomes defined by data, and I think that's fundamentally flawed. And I say this, I was where you were. I have been there; I have done all those things, too, right! And you run into one of these road blocks.
And the answer, I believe, is that objects are defined by behavior, and so when you sit down to create your object model, you should as much as possible ignore the data, as that's not the important part, and instead you should focus on what's the object, what's it supposed to do? So, your customer object has a mission in life, so to speak, right! And it should be a clearly defined mission.
And I say this, because if you think about, you or I, if we come into work in the morning, you have got 18 different things to do with conflicting priorities, that's stressful and it's not fun. And versus if you come into work in the morning and you have got 1 assignment very clear priorities is a lot less stress and a lot more focus. Now, in an object, that "stress" really translates into convoluted or complicated code.
So, if you look at the customer object that's designed to do 18 different things, that looks like lots of switch or select statements, that looks like a lot of if-then, your conditional branching code, and you can't just look at the object and say, "Uh, I know what it does." Right! You have to trace the code.
In order to figure out, well, in this case it does this and in this other case it does that. Well, shoot, at that point you could have just stuck with C. Right! A FORTRANer, yeah, regrets spaghetti code in any of those languages, just as well.
Ron: Well, so, if I am going to write some objects and I cannot start with data, how do I approach that? You know. I guess I am thinking about the customer object's mission in life, what is that? I mean, I suppose it wants to make sure that it's got correct and up-to-date data, so if the real customer that it represents down the world moves and a human needs to tell what the new address is, so probably wants to make sure that database that stores it's terrible state would be up to date and maybe, I don't know. What other things would a customer object live for?
Rocky: Well, that might be a use case.
Rocky: Really, all these… the… An object's mission in life should come from a use case.
Rocky: Or if you are Agile, could be a story.
Ron: Yeah, alright.
Rocky: So, you sit down with your business users, your stakeholders, the end users that understand the business itself, and you say, What do you need your system to do? And one of the things they might say is, well, is that we need to maintain our customer data. And you say, Oh, OK, so tell me, how you do that? What are the different stories or use cases when we sometimes need to add customer, sometimes customers move, so we need to update their address and so forth. And you go through this process of collecting their story and then you decompose it, every… Any form of object designed ends up going through this decomposition process, where you try to identify what are the… I suppose actors is a good word… actors in the system, and what do they do? And so customer might become actor, but then in this case the customer responsibility or mission in life, as you say, would presumably be to record valid customer data.
Ron: So, this is, well, you know, what they taught back in school, you know, you take the nouns those are the objects and the verbs are the methods, you know. [Laughter]
Rocky: Oh, that's a totally wonderful technique. As a starting point.
Rocky: But you kind of flow from there? And this kind of flowing with this customer thing, the next thing that you are going to find out is that you need to get the list of customers.
Rocky: Right! Because for the end users, before we go and edit a customer, we have to find the one we want to edit. So, now you need a list of customers and you might say, "Oh, I have got this customer object, I'll just create and now we have got generics. Right! So, create a list of customers and populate it, and there I go". Right! But how many fields of data are in your customer? Could be a 100 or 200, right?
Ron: Right, right.
Rocky: So, loading a list of customers could be really expensive.
Ron: Especially if all you need to do is put names in the combo box or something.
Rocky: That's exactly right! So, intuitively, all this is dangerous.
Rocky: But if you step back and think about it again behaviorally, the behavior of this customer object is to essentially collect valid customer data.
Ron: Hmm, hmm.
Rocky: Well, we are not collecting data, are we? We were displaying a list. So, we would be misusing this object. It's like you are coming in and asking an employee who is assigned to do one job and say," Oh, can you do this other job for a while?" "Like, I don't know how to do that other job." "Well, do it anyway!" OK?
Rocky: It's better if you hire another employee to do the other job, and in this case it's better to create a customer displayer or customer info object whose mission in life is to display a subset of customer data. Totally different mission, totally different behavior. Now, the interesting thing in this is, where things really get fun is, they both have the same data. Don't they?
Ron: Yeah. Yeah. See, that kind of rankled some object-oriented people. "Oh! That shouldn't happen."
Rocky: Well, this I think reflects how relational-data theory has infected the object-design world. I used the word infected.
Rocky: It's contagious. You know, I can tell where my bias lies.
Ron: Well, you know, that's a real interesting perspective. So, what you're saying is that sometimes our tendency is to begin with the database and kind of look at the database and see how it modeled the world and in even borrowing its normalization concepts and all of that and saying, "Well, that seems to work pretty well there, so we have to make our objects kind of similar," and it begins to break down.
Ron: It's kind of interesting how the inverse also happened and that people flooded with the idea of objects are so great, why don't we have object databases?
Rocky: Hmm… That's true.
Ron: Those kind of broke down, too, didn't they?
Rocky: Yes. Because the object concepts don't seem to map well into efficient storage and retrieval of data.
Rocky: I do think it's two different worlds. But, you know, what's kind of scary about this is most people use UML or at least the class diagrams scheme out of UML when they do their object design, and if you take your database design and print it out, hang it on the wall, you know, most people do this. Right! But then take your object-class diagram, print it out, hang it on the wall next to it, and take like two steps back. Can you tell the difference between?
Rocky: They look the same. And so, all of a sudden, it becomes crystal clear that our primary object-design tool leads us to think about objects the way we think about database tables. And I think this is a problem. So, I am a fan of CRC design instead and class responsibility and collaboration, which is a very old but unfortunately not very popular scheme for doing object analysis and design.
Ron: OK. So, since it's so old and arcane, probably many of our listener's won't know what that means. So, class responsibility collaboration, so the responsibility is that, like, the mission in life of this thing, what it has to do?
Rocky: That's how I portray it. I think in classic CRC design, it's a little different, but the way I think about it is you think it is a class so you give it a name, a customer or invoice or customer list or something, and then you say what is its mission in life, what's its responsibility, which I think should be a, say, six- to eight-word phrase. I mean, that keeps it focused. But, again, we want happy objects. [Laughter]
Ron: No stressful objects out there. [Laughter] OK.
Rocky: You got a very clear, focused mission. What are the things it's kind of hiding behind that mission is the behaviors. In order to fulfill the mission, it's going to do certain actions, you can kind of think of those maybe as methods or properties, but so it's got that aspect, but it also has collaborators, which are other objects that help it do its job.
And so you can think of something like an invoice, which is relatively complex or can be. And I've written an invoicing system years ago, and that was procedural. This is… predates object orientation, at least in my experience.
Ron: You don't look that old, though. [Laughter]
Rocky: Ah… You're doing this almost 20 years.
Ron: Wow, OK, I am with you in that case. We are about the same [experience], [laughs] I think it's about the same time for us. [Laughter] So, invoicing can be really, really complicated.
Rocky: Then you can write an invoicing object and put all that code in one place, and you could have an invoice object that's really, really complicated. And did you gain anything? No. Nothing at all, so it's… But if you instead decompose the invoice process itself, then you could have a lot of smaller objects that the invoice collaborates with to calculate prices, to calculate discounts, to update the customer sales, figures all of the things that go in doing invoicing. But when you look at invoice class, it ends up looking relatively simple.
Ron: You know, it's funny when you describe it that way, because it made me think about the whole reason why we went to object-oriented in the first place, is because as programs became larger and larger and more and more complex, it's like you get a buffer overflow when your brain tries to absorb what this thing does? You know, 'cause you only got so much brain workspace, right! [Laughter] And you can only understand so much of a problem at once.
And so the big three of object orientation were polymorphism, inheritance, and encapsulation. And encapsulation was key, because it helped you divide the problem up into mind-sized chunks.
Ron: So, if I could understand, I could look and focus on one aspect of the problem with a mind-sized chunk, because if the object was mind-sized, then I could do that. But once, you know, if I build an all-encompassing invoice object which could do every possible thing an invoice object needs to do, I am right back to buffer overflow of the brain, because I can't understand the whole object at one time.
Rocky: Yes, that's exactly right, and it's easy to lose sight of that. Because you think, I have got an object and it starts out small, seems mind-sized, but then it grows slowly over time and one day you wake up and your object has become a monster.
Ron: You have to kill it, it must be killed. [Laughter]
Rocky: Luckily, we have a trendy term to solve this, though. Because now you can refactor your object. So, now it's OK again, because you are refactoring.
Ron: Well, that's when they go, "I have this code that smells we need to... We need to refractor this, man." That reminds me of Peter Provost, I did a Web cast with him and Bryan Button. They are big tester and development type guys, and it's just amazing for me to watch them do this exercise about how they, how they say, basically their codes talk to them. And it's just a way of saying, you know, as you are building the thing you're kind of intuitively asking questions: Does this object makes sense, has it overstepped its bounds, is it getting too big, you know, then is it duplicating functionalities that really belong somewhere else? And refactoring is just saying, I am not afraid to change this, break that object apart, break it into 2 or 3 or 10 objects, if you need to.
Rocky: Yeah, that's absolutely right. These concepts are called dovetailed together. And what I think is happening at the moment is that there is a resurgence. I mention that CRC is quite old, but it has never been the big popular technique, but I think there is a resurgence. I think Agile and XP and test-driven development and the behavioral concepts of objects all fit together in a kind of little world that at the moment is on ascendancy. People are interested, and that's fun and hopefully will move the industry forward and help us build some cool software.
Ron: You know, it is interesting because when I think about, I have done the little exercise where, you know, writing out these yellow cards and stuff with other people and stick them all over the walls and, you know, checking everything out, but I actually even do that kind of mentally when I am designing something is... I imagine, you know, the little objects, like they have got names, like that's George and that's Sally, [laughs] and Sally does this and when she needs to do that she has to ask George to help with this part and, you know, and Sally knows what her name is, but George knows how to update the database. Whatever. I kind of mentally think about it that way, I know it's kind of scary.
Rocky: No, it's… it's… There's actually a word for that. It's actually anthropomorphisation, which is taking inanimate objects and giving them human attributes. Disney does this a lot of times, candelabras and they dance around and sing songs.
Rocky: It's a wonderful technique for doing behavioral object design. Because, you know, you can actually envision, Is this object happy, is it social, is it, you know, talking and playing well with others? Get some good laughs out of it. It's corny, but it's useful.
Ron: It also helps me to focus more on the behavior and collaborations, rather than just the data. The data that the state of the object holds becomes like a supporting detail.
Ron: An object holds whatever state it needs to do the behavior, but it shouldn't hold more than it needs to hold.
Rocky: That's right. That's absolutely right. And, similarly then, multiple objects might need some of the same data to do the job, but that's OK, too. That's really, like, the object-relational mapping is often characterized as a way of loading data out of the table into an object that pretty much looks like the table. And, if that's all it is, that's kind of boring, right? But if you start doing the object design we are talking about here, then object-relational mapping becomes truly interesting, because the shapes of your objects can be quite different than the shapes of your data in the database. You can have many objects using the same data or lots of interesting relationships that way.
Ron: OK, so the last burning question: Service-Oriented Architecture! People are going, "Ah! We are not building objects any more, we are building services!" And, you know, we are passing around XML on the wire; if we do have an object, it's just like a container for the data that we were pushing around. How do these concepts fit together?
Rocky: This is something I think about quite a bit. I mean, obviously, service orientation is also a very trendy popular thing. I've blogged about this a fair amount. I think that lot of the problem that we face is actually based around language or semantics. In that you mention, "Oh! We got this object, let's send it across the network to a service." But that's not what's happening. Objects never go across the wire between services; messages go across the wire between services.
And there is this illusion that they're an object, because when you are programming in VB or C#, we end up… You are given this proxy that's generated for us, but really what happened is that Visual Studio took the description of this message and created for us an "object" which I think may be better characterized as a structure. 'Cause inside an object, it has no behavior and it's just a container for data that's convenient for us to consume or create messages, and so services don't exchange objects.
And… now, on the other hand, you have to implement the service itself, and so if I am sitting here writing a service, I am going to accept a message from some outside source and then I am gonna do some hopefully useful work, and possibly produce a message in response. And the real question then is, How do I write the code that does that interesting work? And I might write that using Linear programming techniques, I might use procedural programming techniques we did in Pascal or C, or I might use object-oriented techniques in order to again create body of this service. But what comes and goes is just a message, it's just XML.
Ron: So, really, you know, we're still doing objects, but just gonna need objects on either side of the wire, because sometimes people will say to me, Well, OK lets use our... my favorite customer object. I have got the customer object on the server side, but maybe I have a smart client application on the client side. I might gonna have a customer object over there. Should I build one day customer object that lives on the server side and I also deploy it on the client side? Is that a good idea?
Rocky: Not if you are doing service orientation! No! I draw this line because I personally still think that client-server technologies, some of the client-server concepts that we've explored over the last 10 or so years are totally valid. And if you are creating a client-server system where the server is part of the same application as the client, the same application that's happened to have a network between them, then I will go with you and say, "Yes, you can have the same customer object on both sides." In fact, that's what I talk a lot in my business-objects book. But if you're doing service orientation, then the mindset is entirely different, because service orientation essentially says that any time there is a network boundary, there you, at that point, have two applications.
So, instead of one application with tiers, now with service orientation you have a server application, which could have many different consumers. One of which might be your client application, it's a smart client. Well, now they can't share the customer object, because they are not the same application. And so you don't want the dependency or coupling between the two. So, the server needs to have its own customer object, its own internal implementation, and it consumes and sends messages that are following a clearly defined schema, and the consuming application, which is your smart client, is an entirely separate thing, which just happens to be calling a service. But its implementation is really its own business.
Ron: Well, the other thing that it seems to me is that the behaviors that you want at the server side and the client side are going to be different. Because on the server side, you might have a behavior like, "Save yourself in the database." Right! But on the client side, that wouldn't be valid at all, because there is no database for the client side. All it has is, Call the service that saves you in database, or whatever. Right?
Rocky: Well, that's true, but it's a little dicey. Lots of people will tend to look at service orientation as being a way of getting code reuse. And I think that's a flawed way of thinking about it, because… You are right! On your "server-side customer," certainly there's going to be code dealing with persistence. But remember that the server-side application is a stand-alone application. So, it can't trust any consumer. So, it's got to validate all of the data that are coming in, because Customer is a trivial example, but if you take a sales order or something else, you might have to recalculate taxes, because you can't assume that any of that was done right?
Right! And then at the same time, your smart client that has this customer object. Well, if it's a smart client, it needs a rich user experience and instant validation and so forth. Well, it's going to have to do validation in a variety of the same logic. Of course, it's different because it's going to support data binding and a bunch of things the server one doesn't. But if you think about what I am describing here, there is a large chunk of overlapping functionality, in the other separate objects. And so, really, service orientation, if you look it that way, is going to cause you to write duplicate code. It's by definition.
Ron: Interesting. Well. That is fascinating stuff, and I look forward to your new book. And so, you know, now here's a problem. If I start a book club, I am going to actually have to read some books, [laughs] so I can recommend them or not. [Laughter] So, but, I am looking forward to reading it, so maybe you can send me a draft.
Rocky: We'll figure something out.
Ron: All right. Well, thanks, Rocky, for showing up.
Rocky: Thank you very much.
Ron: Rockford Lhotka, ladies and gentlemen, Business Object Guru, Expert Business Object guy. Thank you on ARCast. You know, there is so much to learn about this, and I am so glad that I have guys like Rocky around us to give us wisdom on this.
Here, I wanted to give quick thanks to Robby and Daniel from dt.com. Daniel says, "Hey Ron, I just wanted to say, Keep the ARCast coming. They make our standing-room commute everyday in the Central London actually productive." That's the point. Send me a note to firstname.lastname@example.org. Let me know what you think. See you next time on ARCast.