written by owen

There is a tendancy to write your use case directly into the low level design of the code. This pattern should be avoided as much as possible because it results in extensive "recoding" whenever high level design changes are made to the program. The highlevel design is not caved in stone and will most likely change as the system evolves but its core design rearly changes. It is important for the programmer to identify this core design.

For example an extreme case can be seen when the previous programmers wrote a screen for the 10 department types that are in the system - assuming that there would only be 10. As you can see hardcoding or hardwiring your use case rules into your code is not a good thing. The programmer wrote the code on the "business logic" instead of the "system layer".

It is important to notice that there is a system below the business logic. This system is what keeps the application simple and stable. The programer should seek to find the best way to rewrite the highlevel business logic into a stable sub system.

Take for instance the previous example: you can imagine that the programer got a use-case with 5 rows and 2 column of 10 items. The programmer looked at the first line of the use case and started coding right away (and in truth and in fact probably coded it in half the time that I would take to code it). The end result will work and will have the same output but the difference between the 2 approachs to the problem is night and day. Further down in the project the need MAY arise to add a new type of department. You should notice that the business logic in the use cases DOES NOT BREAK but the code that was written to implement the use case fails and the blame goes on the programmer even though the programmer did what the use case said should be done.

Another example: bank type. You notice that the use cases specify particular actions that occur on certain types of banks. And these types of banks are hard coded into the system. Business logic constants are bad design. This implementation is done like so:

BANK_TYPE1 = 1

SELECT * FROM BANKS, BANK_TYPE WHERE BANK.TYPE_ID = BANK_TYPE.ID AND TYPE = [BANK_TYPE1]

IF BANK.TYPE == BANK_TYPE1 THEN

        DO BUSNIESS LOGIC

END IF

The shortfall of this type of programming is the SAME as the 10 item example above. If for instance a new bank type is added that implements the same business logic as that of BANK_TYPE1 then the code will have to be CAREFULLY altered to facilitate the change to the design. Here is the new code:

BANK_TYPE1 = 1

BANK_TYPE_TWO = 3

SELECT * FROM BANKS, BANK_TYPE WHERE BANK.TYPE_ID = BANK_TYPE.ID AND TYPE = [BANK_TYPE1] or TYPE = [BANK_TWO]

IF BANK.TYPE == BANK_TYPE1 THEN

        RETURN (BANK_TYPE1) BUSNIESS_LOGIC1()

END IF

IF BANK.TYPE == BANK_TYPE_TWO THEN

        RETURN (BANK_TYPE_TWO) BUSNIESS_LOGIC1()

END IF

In the best case senario the same programmer will be able to remember how the program works and change all the places that need to be changed to fix the problem.

The solution to this problem requires a system level design change that will protect the code (the programmer) from changes/enhancements to the design. There are many ways that this can be done and the best way often takes more time and therefore the benefits of such an change must be evaluated during development by the programmer.

---

The point here is that it that the use cases are not low level designs. The progammer should ( whenever possible ) try to abstract the effects that changes have on the code which is written, by writing it in a way such that it is flexible enough to absorb business logic/design changes that may occur in the future.

permanent link, visited 120 times.