“Keeping you up to date with everything software engineering!”

Ideas for a Better Architecture

Question of the Week | October 13, 2004 | 3 comments

Our applications are mainly built as a collection of “sub-units”. Each of these sub-units are composed of objects from our framework, built up from many smaller components, relying heavily on aggregation.

That is to say, Unit X contains objects A,B,and C. Object A contains Object D,E,F,G. Object D containes H,I,J and so forth…

As you can see…we have a deep heirarchy of classes, coneceptually a tree structiure) for each unit that makes up our application (applications range from 2 to 15 of such units on average).

The problem is… communication between units. Any given object in a Unit’s tree may need to communicate some aspect with any other units. In short, our units are tighly integrated and need to communicate heavily with each other.

The core issue is this: Occasionally, a vendor will want a standalone application of one unit without all the others. Traditionally, this is a project in of itself, with one programmer taking apart the code and writing communication “stubs” so to speak, so that communication between other units that now don’t exist are returning some acceptable default value.

So the design decision is: Lets not have any object in our application know anything about its parents. ever. Every object is self sufficient and can be removed from the application. In order to communicate between units, a higher level communication class is constructed, where listeners are then attached to the object in question and when fired, another method is called on the receiving unit that reacts to the event. Basically, we implement a COR (chain of responsibility) pattern… where the communication class registers a listener with the unit, the unit then passes that listener to a contained class (A for example), then object A passes the listener to Object D, and Object D passes it to H, where it is registered.

I hope you can see where my issues lie. Communication is UGLY. In order to do simple logic (such as “If Object D is activated), notify Unit Y and set a variable in Object Z that is inside Unit Y). the programmer must write listener methods in every class down the hierarchy to attach itself to Object D, and then must write reaction methods all the way down Unit Y to Object Z.

Classes get bloated with methods, one might think we’re still encapsulating logic, but methods related to one type of communication spread throughout 20-30 classes is not my idea of encapsulation.

Worse, we’re doing all this work to build 100% flexible applications, which in my opinion, is an awful idea. Standalone applications I would say, occur no more for 15-25% of our applications, if not much less… So we spend extra effort to add this capability to every sim and it is not used. We should spend the extra effort on projects that need them.

I say… have a way for any object to access a Unit, any unit. Not any other object…just provide an easy way to get to a Unit. After all, the company I work for is building sims that simulate real equipment that communicate with each other…why aren’t our classes not allowed to communicate with each other when the real equipment we simulate does?…why must each logic “event” move through so much classes to get to its destination?

Of course, when I have brought this up, it is regarded as encouraging “spaghetti code” and “breaking object encapsulation” by giving too much access to other units, and of course making it difficult to extract units later on.

I need perspectives from other engineers. Trouble is, my problem statement is long as you have no doubt experienced, I’m not really sure I adequately explained the problem, and I don’t need to tell my management why what we’re doing is wrong, but rather what I believe is the right way to do it…the specifics of which I have a hard time working out…

There should be a balance of flexibility and ease of development… and I’m sure any sane engineer would agree with me. I’ve written this because I am slightly biased - I don’t like this approach one bit - yet, I feel like I am a lone engineer in a department surrounded by people who swear by this method, so its either me who’s insane or the rest of the department. Does anyone have any ideas on how to solve my issues?

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

October 13, 2004 10:06 AM | Gili commented:

Hmm, interesting problem.

Would this would any better?

1) You have units and containers. Containers are units themselves. All units have unique IDs. 2) Containers have a link to their parent and children. These parents, children are not hard-coded but rather (like in Java) you have setParent(Container c), add(Component child) methods. 3) Upon being added to a container, the unit automatically fires an event up the parent hierarchy that informs them unit X lies somewhere below you. 4) When unit A wants to send a message to unit B it fires an event on all its children components or its parent component (depending upon where it thinks unit B lies) with the message. 5) These containers know whether unit B lies in that direction or not because in step 3 we established “soft paths” along containers. 6) If a container does not lead to unit B, it returns false. 7) If a container leads to or is unit B it returns true. 8) You now have a way to decouple all the units and their containers and still get a confirmation whether your messages were received by the destination units.

I think the above architecture will establish something similar to Chain of Responsibility but without the ugly code. All paths are dynamic so coupling is not an issue. Your sendMessage(), addUnit(), etc methods will be very generic and likely consist of 3-5 lines of code. No switch-statements all over the place.

What do you think? Gili

October 13, 2004 10:12 AM | Ness commented:

It seems to me you are trying to rediscover the Unix programming philosopy, but within an OO language. Check out what Doug McIlroy has to say in this link, I don’t know if it will clear anything up but it is how I try to write my programs: http://www.catb.org/~esr/writings/taoup/html/ch01s06.html

I always thought OO was by design meant to have objects dependant on other objects. But that might just be myself being nieve.

October 13, 2004 06:25 PM | ElvisIsGod commented:

I believe Apple had tried something similar many years ago - and failed miserably…

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)