Re: Half user config and half client prog implemented

Responding to Visionset...

I have a Leave type that represents a kind of employee leave (eg holiday, sick etc)
The app I'm writing may end up at any company, so I need to have the leave types configurable throught the app. I'll do this for simple types that just require a unique labeling. But other types maybe more complex and require some bespoke algorithm on a per company basis. So I'll implement an interface for each of these special types.

Could you put some more words around the application problem? I am having a hard time envisioning any sort of "employee leave" abstraction that could not be fully configured by supplying values for a fixed set of knowledge attributes.



Yeah sorry about that, it was a little terse!

Okay so, the leave types are just a simple enumeration. But I need to know about them in the app code in order to do the right thing. Often this will just be to prevent clashes, if it is a company holiday then it can't also be sick leave. But when it comes to annual entitlement or some special kind of compulsory company leave, then special rules will apply such as imposing an 'overdraft limit' or allowing an administrator to configure the company holidays. So usually a generic leave processor class will just prevent clashes but sometimes it needs to do more. And these extra algortihms I'd like to be simply configurable after the main product is established. So I need some way to tie leave types to the code that regulates them.

OK, but aren't those sorts of things somebody else's responsibility? I kind of see Leave as a dumb data holder for parametric data that affects the results of what other objects do. For example, let's look at your examples individually...

detecting clashes. I would expect this is done by whoever creates a Leave object; it needs to understand a precedence between company holidays and sick leave. That could result in an error sent back to the UI if sick leave is being entered by the employee or it could simply be assigning the correct value of a leaveType attribute (or possibly splitting the UI leave into multiple [Leave] objects with different types).

annual entitlement. I'm not sure what this is, so I won't go there. But whatever rules and policies are involved, I would expect them to be encapsulated in some object behavior that would manipulate Leave objects.

compulsory leave. That seems like just creating a Leave object for the Employee and raising a flag for Employees whose current schedule is overdrawn when the compulsory is added in.

generic leave processor. Generic I like, but not the overall notion. B-) It sounds too much like a god object. If Leave is a parametric data holder, then all behaviors that use it should be fairly generic. In effect one is trading off dynamic complexity for static data complexity.

However, that gets trickier as the behaviors become more complex. So I would look for ways to distribute the various business rules and policies around leave taking to a bunch of small, narrowly focused behavior responsibilities sprinkled among various objects. One then just connects the behavior dots correctly to deal with the overall solution flow of control.

Thus detecting clashes is a nice, simple activity that one can envision being quite generic as it mucks with a couple of attribute values among various Leave objects. Similarly, compulsory leave seems like a pretty narrowly defined set of rules to enforce. But trying to do both at once could get complicated. That would be especially true if the contexts were different (e.g., vacation leave data is coming from the UI while compulsory leave is originating algorithmically). The more narrowly defined the encapsulation is, the easier it is to deal with context through simply connecting the dots properly.

Basically as I see the problem (unencumbered by real requirements) as:

[Employee]
| 1
| schedule for
|
| R1 <<ordered>>
|
| *
[Leave]

Somebody needs to create the [Leave] objects for a given Employee and there may be several ways to do that. Each way probably represents a different context and, consequently, a different client object employing a different suite of rules and policies for things like conflict detection.

Though somebody is eventually going to need to use the [Leave] objects by navigating the R1 relationship (e.g., year end vacation loss adjustments), I suspect that context will be relatively simple. That is, most the smarts (business rules and policies) will go into creating the [Leave] objects correctly. I just think things will work out better if you think of each context where a Leave object /might/ be created and isolate the relevant rules and policies for that context.

Among other things I think that will allow you to deal with sequencing issues more easily. For example, you probably don't want compulsory leave being done concurrently with Employees scheduling vacations from the UI. B-)


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: VACATION/SICK TIME ACCRUAL
    ... To deal with sick leave, you could calculate them in a similar fashion based ... So the employee starts to accrue vacation time at Start date +60 days. ... Each regular fulltime employee accrues 80 hours per year for the first ...
    (microsoft.public.excel.misc)
  • Re: please answer these questions as soon as possible. because i have exam
    ... can the clone be identical to the original? ... The concept of identity does not depend on the context. ... representation in one context of employee 123456, ... process space, some other client program may also have such objects, ...
    (comp.object)
  • Re: please answer these questions as soon as possible. because i have exam
    ... can the clone be identical to the original? ... If I have a client going against an RDBMS, the context is clear, it's ... representation in one context of employee 123456, ... process space, some other client program may also have such objects, ...
    (comp.object)
  • Re: Design problem and suggestions...
    ... A "context" table can hold person & role. ... > the both employee and customer. ... please post details of your proposed schema e.g. the new ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Eyes In The Sky
    ... Ian Erickson could probably fetch a photo of ... While price may be the prohibitive factor right ... You call in sick. ... except the sort of employee that can work for home ...
    (misc.survivalism)