Recently, on comp.object, there's been a pretty interesting conversation on operating systems written in object-oriented languages. (The previous sentence should give you all the clues you need as to how happenin' of a dude I am.) Several examples were named: the AS400 OS, Jaluna, and Alan Kay's Dynabook OS. While there are examples, you'll notice that none of these are prominent; I can't imagine that any of them has more than .01% of the total OS market. I think the question then is not why aren't there operating systems written using OO technology, but why aren't they more widely used? I came up with three reasons.
First, abstraction wouldn't work with an OS. When you're writing an OS (which I've never done), you're writing at a very low, hardware oriented level. At that level, an abstraction like an object probably wouldn't be helpful; if you're writing a driver, it's easy to just interface with the device directly than it is to inherit from some monolithic driver class, override its virtual methods, and then implement the object. Also, I think if the abstraction were helpful, it'd be too slow for the user, due to the necessary overhead of creating and manipulating objects.
Second, almost all successful OSes (those with more than 1% of the market) are based on old code bases: either Unix (30+ years old)or Windows (~20). In both cases, object oriented design wasn't around when development initiated and hasn't been included in any of the refinements since, due to how large of a change it'd be. So, to write an object oriented OS, you'd either have to refactor one of these enormous code bases to support objects (yowch) or start from scratch (double yowch).
Third, no one has given Linus Torvalds a copy of Visio yet. Ha ha ha, I kill me.
I lurk on a couple of newsgroups, one of which being comp.object. Usually, I don't post much, simply because the collective IQ of that group frightens me. There'll be an 80 thread post on the intricacies of the Observer pattern in Smalltalk, and all I'll be able to say is, "Yeah, protected members rule." Anyway, I happened to check the group this afternoon right after an interesting question was posted. Someone posted the following question:
Hi All,I have a question on what should be a class and what should not be a class.
I have customer class, employee class [Employee who provides service to customer]. In this both the class has address in it. Do you think it is correct to create a address class and use the address class in both customer and employee class?Is this concept correct?
Thanks.
Simple question, but not a simple answer!Remember, a class is something with responsibilities. It's just an abstraction that allows you to say, "This object here is obligated to know/do something." Are there enough responsibilities for an Address to justify its own class?
The answer there depends on your needs. Taking it to an extreme, Address could know the street number, street name, city, state, zip, country, etc. It could also perform a certain number of validations, to see whether the information is populated, whether the specified zip code falls under the specified state, etc. That's a lot of responsibilities; you'd want an object there.
But maybe your idea of an Address is the polar opposite, just a string like "123 Main St." In that case, an Address object wouldn't be responsible for much of anything. Why have it then?
The answer to your question depends on the responsibilities that fall under Address in your application. It's an abstract answer and I'm sorry for that, but if you think it over a little bit, you should get a good idea of whether or not the class is needed.
Best of luck,
Recently, I got into a conversation with a colleague at work about the benefits of designing in UML. I was in favor of using the modelling language, to the point where I thought all we needed in our design documents was a couple of UML diagrams (class and sequence). He took the other extreme, saying that UML was unnecessary complexity and that we'd all be better served by simply describing our design in paragraphs of text or flowcharts. The debate raged on for days, and to make sure I actually knew what I was talking about (a rare occurrence), I made a list of pro's and con's for extensive use of UML.
PRO
1. There's no room for interpretation on a diagram. Five people could write five different textual descriptions or draw five different flowcharts of a class, but with a diagramming standard, all of their diagrams will be consistent.
2. It's the industry-standard method of describing a design. If a company were to bring in a consultant or experienced employee to implement a design later on, it'd be much easier for this individual to process standard UML than several pages worth of text/inconsistent charts.
3. The diagram minimizes complexity. It may take several hundred words to fully describe a class in text, but all of that can be summarized with a single picture. A picture is worth a thousand words, as the kids say.
4. It's a lot easier to see and apply design patterns through UML. I'm a big fan of design patterns, largely because whenever I try to design something, it takes me several tries to get it right. With patterns, I can start much closer to that right position than I normally do. It's much easier to see where these patterns apply when you can easily view the structure of an object or object relationship.
CON
1. UML is daunting at first glance. If you're handed a class diagram without any knowledge of UML, it'll take a long time to parse the diamonds and arrows.
2. UML is expensive. It takes both time and money to learn it. For me, it wasn't a whole lot of either, but that may not be the case for everyone.
3. It's easy to go UML overboard, and find yourself creating dozens of diagrams.
Having created that list, I don't really think that con's #1 and #2 are true disadvantages; after all, it's our job to learn what's new and apply it accordingly. If you operate like that, those two disappear faster than an unguarded cheesecake at Bruce Vilanch's house. That leaves numero tres, which to me, isn't as much a disadvantage as it is a potential pitfall. That is to say, there's nothing about UML that forces you to use it all over the place; that's just one way people can apply it. If you know that, you can apply your modelling with some discipline so that you only diagram exactly what's needed.
Of course, I've consumed the UML kool-aid, so this list may not apply for everyone. Maybe it's a good starting point for discussion, however. And if it's not even that, well, I offer no apologies.
Question for the unit testers out there: how do you test an abstract class? Do you have to inherit it and then test an instance of the inherited class? That doesn't seem like it'd do the job to me, simply because you'd be testing too much. If a test fails, is it because of the base class or is it because I screwed something up with inheritance? It seems too confusing.
Anyone out there got an answer? I promise absolutely nothing in exchange, although you'd definitely have dibs when the highly-anticipated CodyPowell.com IPO occurs.
As you may've noticed, I think a lot about object oriented design lately. It's gotten so bad, I now cover my walls with pictures of Martin Fowler, like a 10 year old girl in 1988 with her Corey Haim posters. Not really. Well, just a little bit, but I promise he's wearing a shirt in all of the pictures.
In musing over OO, I'm beginning to see how aspects of object oriented design are all around us every day. For proof of this, go a grocery store. Once there, you'll see a lot of people, all focusing on different things. Some are working cash registers, others are pushing the carts around the parking lot, while others still are stacking up rudabegas in the produce section. Imagine if you went up to one the cart guys in the lot with a can of vienna sausages and a dollar, and told him you'd like to make a purchase. Would he commit the transaction? Of course not. He'd tell you to go back inside to see the cashiers, and then he'd whisper into his walkie talkie, "Security, we've got a Vienna Sausage incident in the making."
The same would happen with any of these workers if you went up to them and asked for help in an area that isn't their duty; rather than help you directly, they'd direct you to the right person. From a personal standpoint, I've never been into a supermarket and seen a bunch of employees, each carrying a mop, a cash register, and a big cart full of products to shelve. No sir, they separate those tasks so each person can devote their energies to one main task. As a result, the work force is decentralized, segmented, and hyperfocused, a lot like we expect our objects to be when programming. In economics, we call this division of labor.
In all of the pictures I've seen of Adam Smith, the grandaddy of microeconomics, I've never seen him wearing a shirt that said, "There are only 10 kinds of people on earth: those that understand binary and those that don't." That's a shame, because Adam Smith thought like a programmer. Take a look at this passage from his seminal work, the Wealth of Nations, where he first introduces the concept of division of labor.
"To take an example, therefore, from a very trifling manufacture; but one in which the division of labour has been very often taken notice of, the trade of the pin-maker; a workman not educated to this business ... could scarce ... make one pin in a day, and certainly could not make twenty. But in the way in which this business is now carried on, ... it is divided into a number of branches, of which the greater part are likewise peculiar trades. One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head; to make the head requires two or three distinct operations; to put it on, is a peculiar business, to whiten the pins is another; it is even a trade by itself to put them into the paper; and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which, in some manufactories, are all performed by distinct hands, though in others the same man will sometimes perform two or three of them."
"I have seen a small manufactory of this kind where ten men only were employed, ... they could, when they exerted themselves, make among them ... forty-eight thousand pins in a day. Each person, therefore, making a tenth part of forty-eight thousand pins, might be considered as making four thousand eight hundred pins in a day. But if they had all wrought separately and independently, and without any of them having been educated to this peculiar business, they certainly could not each of them have made twenty, perhaps not one pin in a day."
What's that? The Internet clamors for more on how learning UML has caused me to reconsider my object oriented designs? Fine, if I must!
Like I said, I'm reading Martin Fowler's book on UML, UML Distilled. In it, I found a fascinating paragraph related to OO design.
"In general, the OO style is to use a lot of little objects with a lot of little methods that give us a lot of plug points for overriding and variation. This style is very confusing to people used to long procedures; indeed this change is the heart of the paradigm shift of object orientation. It's something that's very difficult to teach. It seems that the only way to really understand it is to work in an OO environment with strongly distributed control for a while. Many people then say they get a sudden 'aha' when the style makes sense. At this point, their brains have been rewired, and they start thinking that decentralized control is actually easier." Fowler, page 56 of UML Distilled.
Does that contribute anything to my understanding of OO? I think so, because "procedure disoriented" explains what the objects allow you to do. With objects, you design as if the sequence of your code doesn't matter. Rather than a bunch of steps that must be performed linearly in a monolithic procedure, you divide the work into as many autonomous entities as possible. With this idea, lengthy procedures fly out the window entirely, at least until you start utilizing your objects.
Also, "procedure disoriented" helps to enforce a good way of using objects. It's not a real "Stop the presses!" admission, but I've certainly been guilty of using objects as glorified procedures. In these instances, I would have a central object that shuttled between all of the other objects, getting data and doing most of the algorithmic work. Fetch me my dunce cap, because that's not what objects are for! Good OO is about distribution, not centralization! Parts, not procedures! (If we ever have a developer sit-in to protest something, I nominate the preceding statement for what we chant when they turn the hoses on us. It's just catchy.)
So, will we go through all of the textbooks now and change OO to OOPD? Hell no, it doesn't sound nearly as cool. But maybe one day you'll hear someone talking about objects and procedures, and a tear will come to your eye as you think, "I remember when some jack ass on the internet was talking about that."
Right now, I'm reading Martin Fowler's book, UML Distilled, as we begin to gear up at work for the design phase for a new product. (As a corollary, any computer book that's only 150 pages long gets the Powell seal of approval. The 1,200 page tomes force those of us with time constraints to read like Johnny 5 in Short Circuit!) For the unaware, UML is a standard for graphically modelling an application's design. You analyze your design, annotate it up with UML, and the end result is something that looks like a Pac-Man level. Pretty cool stuff, but a lot of the coolness factor has nothing to do with UML itself.
One thing that interests me with software development is the consequences of learning a new skill. It seems that often, learning how to utilize a new process can cause me to look at my entire development methodology in a new way. UML is a good example of this. All I've done is learn a new way to graph things, but learning this new method has caused me to reevaluate every object-oriented design I've ever devised. Why? I have a new method of visualizing all of those designs, and this new method happens to show me some things I never considered previously.
Trust me, this discovery has rocked the world of one Cody Wayne Maxwell Powell. In some of the more harrowing moments, tears were shed and insults were hurled at my cat. (Octopussy, I apologize!) Nevertheless, I view this as a good thing. The only way to verify you're thinking correctly is to subject that line of thought to as many forms of analysis as possible. Luckily, the arena of software development moves so quickly, these new skills and methods pop up regularly. All we have to do is pay attention to these new methods and give them a shot. In essence, that is the point of this site: ruminating on new ideas, often to embarrassing results.
Leave it to Ferris Bueller to summarize in a sentence what it took me three paragraphs to get across: "Life moves pretty fast; if you don't stop and take a look around once in a while, you could miss it." If I accomplish nothing else, let us hope this site will plant a seed for a sequel, featuring Ferris and Cameron's zany UML hijinks.