Content

Hardwiring: programming the design (tech)

Page is part of Articles in which you can submit an article

written by owen on 2008-Mar-24.

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 carved 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. Find similar posts in Articles.

comments

  1. So give us an example of how you would have done that with the bank_type_case nuh?

    by mad bull 2008-Mar-24 

  2. The objective of the article is not to identify a particular solution but to identify a particular problem which occurs when applications are being developed.

    by owen 2008-Mar-25 

  3. Owen, mi breddah, you sound like Motty Perkins. You like to fire up people with big talk about the problems, but you won't try to find the solutions. [confident]

    by mad bull 2008-Mar-25 

  4. [upset], one solution is to use a sub system of flags on the BANK.TYPE table that indicate which pieces of buisness logic to execute on each type of bank. Therefore when development is complete and additional bank types or business logic are required, they can be added to this "sub-system" without heavy hacking. Its a form of "future proofing". Should I add a solution code to the article?

    by owen 2008-Mar-26 

  5. No to the sollution code, I was just wanting to see the ideas. The one you've given could work. Any others?

    by mad bull 2008-Mar-27 

  6. the solution often hangs on the language, type of database, old code, new code and the amount of time avaliable. If the system is already built bad then you are looking at a whole other ball game. The aim is to always write a program that accepts change readily without headaches and retesting.

    by owen 2008-Mar-27 

  7. Dude, did I click the wrong link? I feel like a stumbled into a programming class.

    by Leon 2008-Mar-26 

  8. me and u both Leon :S

    by Irie Diva 2008-Mar-26 

  9. I was under the impression that putting (tech) in the title would be enough but I guess I'm going to have to spell it out. I would suggest you look at the recent updates page for less "technical" stuff.

    by owen 2008-Mar-26 

  10. Hey Owen, do you write C? I have a bredrin in Jam, he is looking to subcontract out a portion of his project which must be done in C. Let me know!

    by mad bull 2008-Mar-27 

  11. wow is it a game, or a operating system? give him my email addy, tell him to send me some info on it

    by owen 2008-Mar-27 

  12. how about a config file like

    bank_type_1
    processor: SomeProcessor

    bank_type_2
    processor: SomeProcessor

    bank_type_3
    processor: SomeOtherProcessor

    by alex 2008-Jul-31 

  13. how about a rules based engine when rules are complex and may include other variables and result in many kinds of outputs.

    code:

    // bank_type could be bank_type_1 or bank_type_2
    rules_engine.setFact(bank_type)
    rules_engine.fire_rules()

    rules file:
    rule "before March 8 2009"
    when
    bank_type == bank_type_1
    current_time < "March 8 2009"
    then
    run SomeProcessor
    end

    rule "after March 9 2009"
    when
    bank_type == bank_type_1
    current_time >- "March 9 2009"
    then
    run SomeOtherProcessor
    end

    by alex 2008-Jul-31 


comment