Representative line: The most involved of our calculations

configurator

We have a large number of complex calculations done in our software; for that, we have a business logic layer, which is chock-full of WTFs like passing method parameters as properties, etc., but let's not talk about that today.

Today, I have for you a representative line, which is the entirety of the Calculate() method for one of our most complicated calculations.

        public void Calculate()
        {
            this.Render();
        }

Render() does exactly what you'd expect - it starts like this

        private void Render()
        {
            BrushConverter bc = new BrushConverter();
            Brush brush = (Brush)bc.ConvertFrom("#193c9d");//007fe3");

            MainBorder.Visibility = System.Windows.Visibility.Visible;

and does the calculation while building the controls.

TGV

Ouch, that's bad form (tadabing!)

Lorne Kates

@configurator said:

Render() does exactly what you'd expect - it starts like this

        private void Render()
        {
            BrushConverter bc = new BrushConverter();
            Brush brush = (Brush)bc.ConvertFrom("#193c9d");//007fe3");
        MainBorder.Visibility = System.Windows.Visibility.Visible;

and does the calculation while building the controls.

[IMG]http://i.imgur.com/N8logyM.png[/IMG]

"Say, Tom, let me calculate a little."

configurator

For bonus points: every time any property is changed, the control, with its dozens of subcontrols, all have to be recreated to calculate the new values - which causes considerable lag when changing values.

Even if the property is something like "name" or "comment".

TGV

I had figured that bit out already. It's a wonderful design. Imagine the joys of porting it to another platform. Or changing the layout because some users have demanded to put a certain control in a separate tab. Spines tingle...

configurator

@TGV said:

Imagine the joys of porting it to another platform.

What I'm doing right now, you mean?

@TGV said:

Or changing the layout because some users have demanded to put a certain control in a separate tab.

They've already done that, twice, for two screens that used to be identical.

Now I have to port all three of those slightly different things.

Happily, I get to write an API, then use it in the stuff that already exists, so it won't be that bad when they next have to change something.
Unhappily, I can't find any way to represent all three almost identical data structures in a nice way, so there are still going to be multiple similar implementations. Makes me sad.

DrPepper

That's sad. There are some design patterns that can come in handy (if you don't know design patterns, do a google search).

Template Method pattern comes to mind.

DaveK1

@configurator said:

Unhappily, I can't find any way to represent all three almost identical data structures in a nice way, so there are still going to be multiple similar implementations. Makes me sad.

What stops you using a simple base class for the common stuff with three derived classes for the variants?