The Lanham Factor

Balancing the Technology-Business Equation
  Home  |   Contact  |   Syndication    |   Login
  127 Posts | 2 Stories | 116 Comments | 106 Trackbacks

News

Article Categories

Archives

Post Categories

Image Galleries

BLOGS

Companies

My Articles

What is your Object's IQ?

For years I have been against so-called "smart" objects.  (In fact, I thought I blogged on it at once time but can't seem to find it...guess I'm getting old.)  I have taught and mentored that objects shouldn't know how to perform certain operations.  Recently, however, I've started having a change of heart.  That is NOT to say that I am changing my position.  It is to say, however, that I am starting to see the other side of the coin.  However, I need your feedback. 

Object-Oriented Programming - In Theory

According to object-oriented lore, object-orientation is intended to allow programmers to model the "real world" (whatever that is) in their software systems.  There is an old joke to this effect:

How many C++ programmers does it take to screw in a light bulb?  If you answered with a number greater than zero, you're still thinking functionallity (imperatively).  C++ programmers have the socket object call the "replace" method on itself.

Of course this is ridiculous...light bulb sockets don't change the bulbs themselves.  But wait, an object is, by definition, "an entity which has state and behaviors that act on that state."  And that's where the fun begins.

My Perspective - Smart Objects BAD!

A hundred years or so ago, Visual Basic 6 utilized the Collection class.  Many VB6 programmers utilize(d) the "smart" object approach.  For example, the collections would sort themselves.  So here has been my argument for years.

Assumptions:

  1. You have a collection of magazines.  You can even imagine a stack of magazines sitting on a table.
  2. Object-Oriented Programming models the real world.

Coding:

You write a collection class for magazines (MagazineCollection).  The class has a "Sort" method.

Problem:

In the real world, magazine collections do NOT sort themselves.  Go ahead and try it.  Stack some magazines on your desk and ask the stack of magazines to sort itself.  Let me know when it happens.  (P.S.  If it happens, I'll print this post and eat the paper.)

Solution:

So, in the "real" world, what sorts magazines?  You do.  And what are you when you are doing this?  A magazine sorter.  So I would implement a class called "MagazineSorter". 

The same is true (in my not so humble opinion) for database operations as well.  Why should objects know about how they are persisted?  Of course with configuration files and such it is much easier to change the persistence mechanism and location.  However, it seems to me that having an object that understands the database schema violates about a bazillion abstraction best practices.

My Perspective Change

So my good friend Brian Johnston is a HUGE CSLA fan.  (I think he has "CSLA ROX" on his boxers.)  Rocky and I have (obviously) disagreed for years on the whole "smart" object thing.  Rocky has promoted smart objects since at least VB5 and the CSLA framework is no different.

Well, I'm trying to be open-minded about it so I gave Brian (and his cohort, Stephen Richards) props and listened as they extolled the benefits of smart-er objects and panned the downsides of "manager" classes.  (In one slide, Brian even writes "Kill Your Managers" but secretly I think this has a more Freudian meaning for him.) 

So I was trying to think about groups of things in the "real" world that sort themselves.  True that magazines still don't (are you still trying?).  However, collections of humans do.  In fact, humans do a lot on their own like respirate, defecate, procreate, and eat (tip-o--da-hat to Fox Mulder). 

Disclaimer:  I am NOT under any circumstances trying to imply that humans are smart.

Help Please

So now I'm having a change of heart.  It seems that some things in nature are smart about themselves while others are not.  So here are my questions:

  1. Where do you draw the line between smart objects and not-so-smart objects?  Are all of your objects "smart"? 
  2. How smart are your objects?  Do they know how to persist themselves in the database?
  3. How do you accomplish abstraction with smart objects?

Thanks in advance for any advice you have on this.  I may not agree with you but I appreciate your perspective.  Help an old dogg learn an old trick.

P.S. Rocky, if you're reading, I gots nuttin' but luv fo' ya.  CSLA framework is amazing. 

posted on Sunday, December 09, 2007 9:29 AM

Feedback

# re: What is your Object's IQ? 12/9/2007 11:45 AM Paul Kinlan
Hi,

I would stick with current thinking and not change it so much.

The reason I say this, and it partly goes back to your example of humans, if the object were to have "IQ" such that it knows how to sort itself with respect to other objects, then I would say these object would be best thought of as autonomous agents, or in other words independent systems that encapsulate the non IQ'ed objects and thus programmed differently.

I belive it is a kind of move to an SOA, with simple (low IQ objects) systems interacting to form "intelligent"/complex systems.

However it is all personal preference to the best way you can enpasulate your thought into an object model.

Regards,
Paul Kinlan.

# re: What is your Object's IQ? 12/9/2007 12:47 PM David Brown
In my opinion, the whole "software has to model real life" idea is ridiculous. I don't sit down to write a program and then think to myself "This makes absolutely no sense! Magazines don't sort themselves!" and then run off to design a MagazineSorter class. Computers aren't human beings and a string of 1s and 0s does not represent real life.

To me, object-oriented programming is a way to give freedom to developers. It allows them to structure objects however they please. It wasn't designed (or shouldn't have been, anyway) to force developers to stick to one idea. In the real world, dogs don't fly. But, if I had a Dog class and I wanted it to fly, then by-golly it's gonna get a Fly(int howHigh) method!

That's just my opinion. Of course, some may find it easier to have a MagazineSorter class or an ICanFly interface. As I said, OOP is all about freedom, not conformity.

# re: What is your Object's IQ? 12/23/2007 9:39 PM Brian Johnston
I think David's comments say it best, and I agree with Paul, whatever works for you. I think software development has tried to structure itself into do's and don'ts - which like garlic, a little is a great touch, too much spoils the dish.

This pattern seems to revolve in everything we programmer's do. Patterns, for example is a huge one...it's either a pattern, or it's adhoc trash. Inheritance vs. Interface is another good example that is often taken to extremes. You see programs with nothing but interfaces, and you see programs with no interfaces at all. Requirements: most novice developers either consider a requirement a non-functional or a functional requirement. You see it in the way people program loops - you'll find that there a several people out there who gravitate everything to for and never do foreach, or while, or they'll only do foreach and never do for, etc.

I think this is because of our black and white mentality - it's natural to want a clear cut answer. You'll find Rocky himself doesn't promote using CSLA for all things in a program, only those things that encompass a business behavior. Meaning in my organization, a customer is a customer, no matter where in the company you are, the rules are the same.

So why should I have a Customer DTO (in a Common assembly), a CustomerManager (in a BLL assembly), a CustomerDAL (in DAL assembly), handle Security in yet another assembly that controls who can do what to a customer when I can have a single Customer business object than encapsulates all of the business rules, security, and persistence with in it? (Plus have it already built for n-tier physical architecture, N-level undo, and other built in features). I'm a programmer, and I'm lazy by nature; maintaining, configuring, and deploying one object in one assembly is far easier (and thus makes the lazy side of me happier) than maintaining, configuring, and deploying four.

If you take away physical n-tier deployment concerns (scalability), what reasons are there for the traditional 3/5 tier systems? Well that brings us back to OO, the object is suppose to model real life. So does a customer of my employer know how to save itself? No. But in reality can you tell a human 'Save yourself' (and not in the religious term)? Does a customer of my employer know that it must have 1 phone contact in order to be valid? No. But in reality if I told you that I would only consider you as a valid person if you had at least one phone number you'd ask me WTF was I talking about?

So it's like Dave said, this whole concept of modeling real life is ridiculous; you can't model real life - we're talking about modeling a business, not real life, and if we model a business, then it make since to do things however you must that makes a component based, scalable, logical architecture. So if for you, having an assembly that contains a DTO, an assembly that contains the business logic, an assembly than contains the security, and an assembly that contains the data persistence, and you write all the documentation so a developer knows how all those moving parts work together and are wired together, then do it; but if using one assembly that contains all of that makes sense, then use CSLA.

Oh, and besides all the other benefits of CSLA, I've found that it also helps developers protect themselves from themselves. Meaning, I don't have to worry if Joe Programmer has disregarded the documentation and skipped over calling BLL methods that ensure a DTO is valid before it's is saved by calling a different BLL method or going directly to the DAL (because he can't find the right method in the BLL [true story!]).

Post A Comment
Title:
Name:
Email:
Website:
Comment:
Verification: