Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Black Box Theory 1
- Thread starter BKtechie
- Start date
I think they means Information Hiding. Only display information i.e. Variables where they need to be displayed.
Black Box is actually a term to do with testing. It's about not seeing inside the objects and creating your test data only in terms of inputs and outputs.
Craig
Black Box is actually a term to do with testing. It's about not seeing inside the objects and creating your test data only in terms of inputs and outputs.
Craig
- Thread starter
- #3
-
1
- #4
CajunCenturion
Programmer
This "black box" theory, or modular programming, has been around a lot longer than ActiveX.
In essense, you break a process down into its individual component parts, then write a module/function/subroutine (depending on complexitiy of the part) to handle each component part. You then develop and test that module to insure that its functioning properly. Once its working, you can then consider that module to be a fully functional black box, and can plug it into the entire process.
There are several advantages to using this rather standard software engineering approach. By breaking the process down into smaller pieces, its much easier to allow for team development, you remove the over-whelming aspect of large projects, testing can be done systematically, and from a maintenance standpoint, if the logic with a module needs to change, you pull out that "black box", do the updates, and plug it back in.
Now, that being said, there are very legitimate uses for public variables, and in some cases, it may be more efficient, and practical, to use a public variable, especially in event-driven processes, for those items which are by their very nature, global in scope. But I would only use global variables where they are required. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
In essense, you break a process down into its individual component parts, then write a module/function/subroutine (depending on complexitiy of the part) to handle each component part. You then develop and test that module to insure that its functioning properly. Once its working, you can then consider that module to be a fully functional black box, and can plug it into the entire process.
There are several advantages to using this rather standard software engineering approach. By breaking the process down into smaller pieces, its much easier to allow for team development, you remove the over-whelming aspect of large projects, testing can be done systematically, and from a maintenance standpoint, if the logic with a module needs to change, you pull out that "black box", do the updates, and plug it back in.
Now, that being said, there are very legitimate uses for public variables, and in some cases, it may be more efficient, and practical, to use a public variable, especially in event-driven processes, for those items which are by their very nature, global in scope. But I would only use global variables where they are required. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
- Thread starter
- #5
Thanks Cajun,
I'm familiar with modular programming, but had never heard it called by the name "black box" before. I suppose its an old buzzword. I still don't quite get why she thinks it would be philosophically wrong to use public variables as long as they were not used in any moduales that were to be called by other applications, but that's just my opinion.
BKtechie
I'm familiar with modular programming, but had never heard it called by the name "black box" before. I suppose its an old buzzword. I still don't quite get why she thinks it would be philosophically wrong to use public variables as long as they were not used in any moduales that were to be called by other applications, but that's just my opinion.
BKtechie
DonQuichote
Programmer
- Nov 9, 2001
- 980
... I still don't quite get why she thinks it would be philosophically wrong to use public variables as long as they were not used in any moduales that were to be called by other applications
If making them public allows them to be called from other applications, this would be wrong, as you state that that is not the intention. A few languages give you the option of making a variable "public only within the project". This is usually called "Friend" or "Protected".
One of the drawbacks of global variables is that you can call them from anywhere in your code. This creates a dependency on that variable (you cannot use the module in another program without declaring the global variable there as well). As CajunCenturion pointed out, this is not always bad, but you should use it only when necessary.
To overcome the dependency, you can build an initializer in your module and pass anything it uses through the initializer (and store it locally in your module). Then the initializer is a part of the "plug" of your module. You could then plug it into your program or into a little test program (this is called a "unit test"
.
Best regards
If making them public allows them to be called from other applications, this would be wrong, as you state that that is not the intention. A few languages give you the option of making a variable "public only within the project". This is usually called "Friend" or "Protected".
One of the drawbacks of global variables is that you can call them from anywhere in your code. This creates a dependency on that variable (you cannot use the module in another program without declaring the global variable there as well). As CajunCenturion pointed out, this is not always bad, but you should use it only when necessary.
To overcome the dependency, you can build an initializer in your module and pass anything it uses through the initializer (and store it locally in your module). Then the initializer is a part of the "plug" of your module. You could then plug it into your program or into a little test program (this is called a "unit test"
.Best regards
- Status