in reply to A novice's thoughts on applying Demeter to extension code

If I understand your example, your saying that when you are dealing with some employee, you need to charge some of their expenses or costs to a cost centre. But the cost centre of a given employee, is that of the this employee's manager. Therefore, to fill in the cost centre, you have to first query the employee's manager, and then query that manager's cost centre, and then fill in that value wherever it is required.

Where that falls down is that you are filling in the cost centre in relation to the employee. You should not be doing this.

If the Managers own (have responsibility for) the cost centres, then all his employee's costs, are his costs. He should have oversight of them. Once he approves them, they become a part of his costs. Only at this point should the cost centre be filled in.

In other words, if you find yourself in the position of needing to aquire information from a a remote source, to complete a task at a given level, you are doing the task at the wrong level.

When the Employee's complete their costs/expense forms, they should not be attributing them to a cost centre at all. Indeed, their forms should not be fed into the Costing system directly. Their forms should be assign back to their managers, where they should be consolidated and rolled up into a summary screen against which the manager will attribute costs centre numbers. This allocation to a cost centre then becomes his explicit approval of the costs.

In this way, the employees (flesh & blood) do not have to bypass the online system, by seeking verbal approvals (and getting a nudge and a wink on the correct costs centre number to allocate stuff against). It is these ad hoc arrangements, often as not done whilst standing around the coffee machine or water cooler than break the audit trail, and create huge problems down line.

Ex.1 ) An employee seeks approval for an expense item, and is given a cost centre number. A few weeks later, he has obtain another expense item. The manager is not around, and it seems similar to the other one, so he fills in the same cost centre number. Audit problems ensure.

Ex. 2) Three managers up the line, a re-structuring occurs that move this employee's, manager's, manager from one cost group to another. As a consequence, all the costs centre numbers down stream change. Because of the ad hoc "standing approval" arrangements, all the usual expenses continue to be billed to the old cost centres and audit problem's ensue.

This was all very common in the bad old days before MIS systems where set up properly.

Any arrangement whereby every employee assigns their own costs to cost centres, effectively invalidates the cost centre mechanism, and that you are encountering this problem within the software design, is direct evidence of that problem.

That's one of the strengths of OOD. If you find that you are having trouble correctly modelling reality, within your class structure, it can often be because you've hit upon a flaw in the existing system.


Examine what is said, not who speaks.
"But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
"Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
  • Comment on Re: A novice's thoughts on applying Demeter to extension code

Replies are listed 'Best First'.
Re^2: A novice's thoughts on applying Demeter to extension code
by diotalevi (Canon) on Nov 22, 2004 at 22:28 UTC

    BrowserUK,
    Whether it is valid or not to talk about an employee's manager's cost center isn't the point here. I could have use the employee's manager's email address as an example and it wouldn't have changed anything about my concerns regarding the Rule of Demeter. Could you re-read the question and consider in that light?

      Whether it is valid or not to talk about an employee's manager's cost center isn't the point here

      Actually, it is exactly the point. At least as I see it.

      You are in a piece of code where you find yourself needing to access an attribute of an attribute.

      You are aware that by doing so, you are breaking the LoD.

      The question you asked is: How can you legitimise the need to break the LoD, by wrapping it into a method that conceals the fact that you are accessing the attribute of an attribute.

      But, if you re-read your post, you'll see that all of the methods you outlined, still access the attribute of an attribute; and so, still break the Law of Demeter.

      The problem lies not in the implementation that allows you to do it, but in the design that requires you to do it.

      My extended example was an attempt to show how such bad designs come about and why they are wrong.

      An attempt to show that any of the solutions you presented, or any solution thatcould be presented, that continued to allow you to apply the value of a Manager attribute, in the context of an Employee, would continue to break the Law of Demeter.


      Examine what is said, not who speaks.
      "But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
      "Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon