Case for a swicthable object

joriente posted on Friday, January 26, 2007

Hi All,

I'm starting to work with CSLA and in reading the book it says that in most cases the need for a switchable object is due to flawed design.  I think in my current project i have found one and just want to see if it is legit.  The site i am creating (it is based on the personal starter kit) has a picture on home page that is randomly retrieve (picture of the day).  Another page has a list of albums that the user can view, and all photos must be in a album.  So I am thinking a photo object should be a switchable object (it can exeist on its own for the home page and there is a child collection of them for each album).  Is this valid

Thanks in advanced,

John

jspurlin replied on Friday, January 26, 2007

I have had the same hopes as you and have tried to code switchable objects to accomodate complicated relationships between people and addresses for reporting, billing and donations.  Trying to use switchable objects has "always" resulted in convoluted code and oodles of documentation to alert others how to use the class depending on context:  is it a root or child?

I swear the convolution of code and the confusion it will cause others is a "significant" maintenance problem. So I forced my self to actually create more simple and rudimentary classes singular in their use: a Person class is "always" a single class.  It has child collections of attributes, addresses that may be fetched.

What will happen with a "switchable" object is you will run into scenarios where you will have to analyze the class you coded "yourself" time and time again to remember how to derive it for the desired effect.  I am not an academic "expert".  I can only say from my experience, my code has benefitted from rethinking my Use Cases and simplifying the object model and avoiding switchable objects.

What if your implementation changes?  Changes to a switchable object has really "significant ripple effects" through out your code.  You will become very surprise how this will complicate making changes and adapting them "even to the UI":  My experience has been that switchable objects have ripple effects even across "logical" boundaries: a tendency to easily break principles and rules of logical separation of tiers, because you will design a UI around this object and will have to unravel your design at levels beyond the business layer if you decide to make changes to it.

I strongly advise taking a closer look into the reasons you feel you need the switchable object:  to meet a UI requirement, perhaps?  To tie everything into a cool custom grid, for example?

The main reason I tried switchable objects was to accomodate a more fluid UI and to be able to keep everything tidey inside a single session object.  When you break things down, objects of different types get passed to Session["currentObject"] which means to complete the UI redundant calls would be made.

If this is the case, a strategy for managing multiple business objects in session has proven a more cogent approach for me.  I run the risk of "loosing track of Session["currentObjectTwo"], but I have worked out a mechanism via a custom BasePage classes to handle that complication:  still too convoluted for my tastes, but considerably less complicated and manageable than trying to build a One-Size-Fits-All scenarios business object.

pelinville replied on Friday, January 26, 2007

 

jspurlin:

I have had the same hopes as you and have tried to code switchable objects to accomodate complicated relationships between people and addresses for reporting, billing and donations.  Trying to use switchable objects has "always" resulted in convoluted code and oodles of documentation to alert others how to use the class depending on context:  is it a root or child?

I swear the convolution of code and the confusion it will cause others is a "significant" maintenance problem. So I forced my self to actually create more simple and rudimentary classes singular in their use: a Person class is "always" a single class.  It has child collections of attributes, addresses that may be fetched.

What will happen with a "switchable" object is you will run into scenarios where you will have to analyze the class you coded "yourself" time and time again to remember how to derive it for the desired effect.  I am not an academic "expert".  I can only say from my experience, my code has benefitted from rethinking my Use Cases and simplifying the object model and avoiding switchable objects.

 

You know, I believe every word you have said. I really do.  But I have to say that EVERY class I have is switchable.  Every single one. Even the collections. I have said in the past that I do all root objects due to using them in sessionless web sites. But really they are switchable. I just didn't want to anger everybody in the forum. :)

 

I have never really had a big problem with them.  To me it seems the natural way to do things.  Every object, and only that object, is responsible for it's data. And using them is a breeze. Oh, sometimes the web developer will do something wacky and an object won't get saved when they expected.  But those things are so easy to find and fix. But in about a week even that problem will be almost solved. All they will have to remember is one simple rule.

 

jspurlin:

What if your implementation changes?  Changes to a switchable object has really "significant ripple effects" through out your code.  You will become very surprise how this will complicate making changes and adapting them "even to the UI":  My experience has been that switchable objects have ripple effects even across "logical" boundaries: a tendency to easily break principles and rules of logical separation of tiers, because you will design a UI around this object and will have to unravel your design at levels beyond the business layer if you decide to make changes to it.

It really doesn't if all objects are self sufficient and strict encapsulation is maintainted.  If only the object knows how to get and save itself then there isn't a large impact when a part has to change. At least I haven't found this to be true.

 

Of course it could be that I have never understood what was meant by "switchable".  I thought it meant that

1 It could be a root object and thus be savable.

-OR-

2 It could be a child of a root and the root would save it. (Or at least the root would be responsible for calling the childs save method). 

 

Is this correct?

 

Ok, I am going to run away and hide because I know I have angered some coding deity or the other. :)

jspurlin replied on Saturday, January 27, 2007

I am sure you haven't angered anyone. My understanding of switchable objects is that it may act in the capacity of both a root and child object.  I think my key point is the caveat that "One-Size-Fits-All-Scenarios" business objects typically do not have well demarcated functional specifications to support them. I am only saying that the temptation to place coding ahead of functional specifications and use cases is strong and that you will some difficulties this way.

If coding or a technical specification takes precedence over a function specification, or a function specifcation takes precedence over "use casing", people tend to fall into a development pattern complicated by "Scope Creep": your functional specifications not being clearly demarcated or designed without overlap into other areas of functionality.

Placing emphasis on the technical specification ( and this is where the Switchable Object debate begins ) may indicate that those technical specifications are taking precedence over your functional specifications or more likely there is scope overlap in the functional spec. For example, I am working on code for managing addresses tied to billing and reporting and an address may belong to more than one person (who can be family, friend, or business), that can have more that one start and end date (mailings to donors with seasonal addressess and people who have moved during the billing cycle) and each address can be mailing, billing, physical or all three and each can have their own start and end date. 

This clearly needs well thought out use cases and a well demarcated functional specification and we are only talking about addresses (and the actors involved and their use cases)!

In my case, the temptation to use switchable objects inspired me to go back to basics: define my use cases and keep functional specifications simple ( complicated functional specifications easily result in scope creep and this will convolute the coding process ).

If you feel your encapsulation is good, then maybe this will not be the case for you.  Also consider, though, the "extensibility if not portability" of your code.  I have managed to build and use switchable objects myself.  The extra coding required and the extra complications involved gave me pause to consider the soundness of my approach.  You may have found a better way.  I know from experience that simplicity has never come back to haunt me!  Switchable objects did make coding for the UI more straightforward, but I made the choice to "code independently from the UI" and if extra code is needed at the UI level to make things happen, this is preferrable to code that is "potentially difficult to extend".