Refactored Definition for an Interface
| Refactored definition | This definition divides the responsibilities into a) user data entry and b) user access, c) the security system, and d) the database behind the security system. This approach allows the user interface to change without disturbing or even touching the logic behind it. The interface is completely ignorant of how it is being used. It merely provided fields to receive and display information. In fact the same interface could be used at many different levels through the system, e.g. application security, system security, and function level security. |
| Security Client Application | The client application knows nothing about presentation or the actual validation. Its sole responsibility is to obtain valid input for the security system "Validate User" interface. |
| Security System | The security system knows how to interpret security information about a user, but not how its knowledge will be presented to the user. It does not even know where the security data is physically stored. |
| Security System Database Interface | The security system database knows the current database and how to format the validation request in to the SQL or other language needed to get an answer from the current database. This separation of the database from the security system using an interface allows for the replacement or upgrade of the database without changes to the applications that use it as long as the interfaces remain the same. |
Domain Driven Design
Decomposing and Redistributing the Statement Method
The obvious first target of my attention is the overly long statement method. When I look at a long method,
I am looking to decompose the method into smaller pieces. Smaller pieces of code tend to make things more manageable.
They are easier to work with and move around. The first phase of the refactorings in this module show how I split up the long method and move the pieces to better classes. My aim is to make it easier to write an HTML statement method with much less duplication of code. My first step is to find a logical clump of code and use Extract Method. An obvious piece here is the switch statement.
This looks like it would make a good chunk to extract into its own method. When I extract a method, as in any refactoring,
I need to know what can go wrong. If I do the extraction badly, I could introduce a bug into the program. So before I do the refactoring I need to figure out how to do it safely. I've done this refactoring a few times before, so I have written down the safe steps in the catalog.
First I need to look in the fragment for any variables that are local in scope to the method we are looking at, the local variables and parameters.
This segment of code uses two: 1) each and 2)
thisAmount. Of these each is not modified by the code but thisAmount is modified. Any nonmodified variable I can pass in as a parameter. Modified variables need more care. If there is only
one, I can return it.
The temp is initialized to 0 each time around the loop and is not altered until the switch gets to it. So I can just assign the result.