Alternative to Brittle Code? - Adding New Properties to Class Over Time

  • Thread starter Thread starter Franklin
  • Start date Start date
F

Franklin

The user interface of a Windows Forms application needs to show/hide various
UI widgets based on the current user's privileges. The mapping of [user
capabilities] to [ui widgets] is stored in a SQL Server database and is
retrieved by the application via stored procedure during application
startup. So on application startup, the application has a list of ui widgets
the current user is allowed to see. Over time, the list of possible widgets
will grow.

I was initially thinking that, upon application startup, I could instantiate
a class ("UserCapabilities") that exposes a bunch of read-only boolean
properties - each property corresponding to a UI widget the user can see.
The application would then look to this class to determine if a given widget
should be enabled/visible.

e.g,.
widgetX.Visible = UserCapabilities.WidgetXVisible;
widgetY.Visible = UserCapabilities.WidgetYVisible;
widgetZ.Visible = UserCapabilities.WidgetZVisible;

While this would work, it is brittle in that every time the application is
expanded to offer a new capability (exposed by a new widget), a new property
would have to be added to the class.

Rather than adding new properties and having to recompile, I'm looking for a
way to accomplish the objective without having to modify the
UserCapabilities class and recompile every time the class needs to take on
an additional property. The database is already flexible enough that it's
structure would not have to change. We just add new rows to the requisite
tables and the application would then pick up the new widget and associted
permissions per user. It would be good to not have to modify [add a new
property to] the UserCapabilities class whenever we add such a new
capability to the database.

Suggestions?

Thanks.
 
Franklin said:
The user interface of a Windows Forms application needs to show/hide
various UI widgets based on the current user's privileges. The mapping of
[user capabilities] to [ui widgets] is stored in a SQL Server database and
is retrieved by the application via stored procedure during application
startup. So on application startup, the application has a list of ui
widgets the current user is allowed to see. Over time, the list of
possible widgets will grow.

I was initially thinking that, upon application startup, I could
instantiate a class ("UserCapabilities") that exposes a bunch of read-only
boolean properties - each property corresponding to a UI widget the user
can see. The application would then look to this class to determine if a
given widget should be enabled/visible.

e.g,.
widgetX.Visible = UserCapabilities.WidgetXVisible;
widgetY.Visible = UserCapabilities.WidgetYVisible;
widgetZ.Visible = UserCapabilities.WidgetZVisible;

While this would work, it is brittle in that every time the application is
expanded to offer a new capability (exposed by a new widget), a new
property would have to be added to the class.

Rather than adding new properties and having to recompile, I'm looking for
a way to accomplish the objective without having to modify the
UserCapabilities class and recompile every time the class needs to take on
an additional property. The database is already flexible enough that it's
structure would not have to change. We just add new rows to the requisite
tables and the application would then pick up the new widget and associted
permissions per user. It would be good to not have to modify [add a new
property to] the UserCapabilities class whenever we add such a new
capability to the database.

Suggestions?

Thanks.
Click to expand...

Franklin, expose the capabilities as a collection, containing an object for
each user capability. It might be a dictionary, keyed by the capability
name. The value object could then be an instance of a class that describes
the capability.

As you add new capabilities, you merely add more objects to the collection,
based on what's in the database. The application queries the dictionary by
capability name and gets back the capability object and inspects its Visible
property.

Maybe the collection class is named UserCapabilities, and a capability class
is named UserCapability. The collection could be, for instance, a
Dictionary(of String, UserCapability). The UserCapability class, per your
requirements above, exposes a Visible property, but once you got this going
you might find that other useful properties come to mind.

Tom Dacon
Dacon Software Consulting
 
Back
Top