Re^5: Perl to protect database field name info

OK, we're getting to the nub of the matter. Sometimes, some fields are best abstracted, either so that the user interface can be optimized for users, or in case the use of the site changes.

That sounds very reasonable.

Thanks for the discussion.

Forget that fear of gravity,
Get a little savagery in your life.

Comment on Re^5: Perl to protect database field name info

Replies are listed 'Best First'.
Re^6: Perl to protect database field name info by dragonchild (Archbishop) on Feb 14, 2007 at 01:40 UTC
Close. The nub is that software is the only thing humans make that is going to change repeatedly and radically over its expected lifecycle. The only way to properly design software is to build into the very core a capability to change safely. Every change will always bring a risk that a bug has been introduced. (I once fixed a bug in an application and another bug appeared. After I traced down the second bug, it turned out that the first bug had been compensating for it and my correct fix for it broke the application.) So, the proper discussion to have about bug-minimization is minimizing the chance of introducing bugs when making the inevitable changes. When we discuss this in terms of structuring subroutines, we end up discussing the promotion of internal cohesion and avoidance of external coupling. Internal cohesion is summed up as "A subroutine should do one thing, one thing only, and that one thing well." External coupling is summed up as "A subroutine should only depend on the parameters it was passed in and the values that it and it alone controls." If you think about it in terms of your subroutines, those two things make perfect sense for improving maintainability. Now, take the external coupling concept and extend it to the components of your application. We have, at a minimum, the user interface (UI), data storage (DS), and the stuff in the middle (APP). Your proposal would couple the UI to the DS. That's about as large an external coupling as you can get. It's not something you would do with your subroutines. Why would you do it with the basic chunks of your application? That is only guaranteeing that you will run into maintainability issues, as ptum has already discovered. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]

Replies are listed 'Best First'.

Re^6: Perl to protect database field name info
by dragonchild (Archbishop) on Feb 14, 2007 at 01:40 UTC

going

Every change will always bring a risk that a bug has been introduced. (I once fixed a bug in an application and another bug appeared. After I traced down the second bug, it turned out that the first bug had been compensating for it and my correct fix for it broke the application.) So, the proper discussion to have about bug-minimization is minimizing the chance of introducing bugs when making the inevitable changes.

When we discuss this in terms of structuring subroutines, we end up discussing the promotion of internal cohesion and avoidance of external coupling. Internal cohesion is summed up as "A subroutine should do one thing, one thing only, and that one thing well." External coupling is summed up as "A subroutine should only depend on the parameters it was passed in and the values that it and it alone controls." If you think about it in terms of your subroutines, those two things make perfect sense for improving maintainability.

Now, take the external coupling concept and extend it to the components of your application. We have, at a minimum, the user interface (UI), data storage (DS), and the stuff in the middle (APP). Your proposal would couple the UI to the DS. That's about as large an external coupling as you can get. It's not something you would do with your subroutines. Why would you do it with the basic chunks of your application? That is only guaranteeing that you will run into maintainability issues, as ptum has already discovered.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

[reply]