Black box programming
Black box programming is a commonly used term and it has been used with both good and bad meaning.
It is considered good, because for example a function should do what it is expected to do without any further side- effects and the developer using this function (inside the black box) should rely on it without knowing how it internally works. It is as if we are trying to step on a rock and we shouldn't worry about falling down or how the rock is "thinking" of handling our weight.
On the other hand, it has been used with a bad meaning because it doesn't let developers have full control of how something is achieved. An example is how ADO (simple ADO) handles applying updates. Some call it "automagically", some think it is black box programming (very... very black).
Where is the fine line that makes black box programming techniques useful and at the same time lets users have full control?
I believe an example that walks perfectly well on this thin line is Delphi itself. It is a RAD tool (automating a lot of procedures), but at the same time gives a developer full control of what is going on and how it is done. It performs things "automagically", but lets developers participate in magic (Aren't Delphi programmers magicians?!!).
On the other hand, let's consider ADO .NET. A lot of people complained about how ADO handles all applying updates logic in a black box not letting them intervene. MS with ADO .NET tried to balance on the thin line I am talking about and it is true that it gives developers full control (more than Datasnap I have to say). But on the other hand, a lot of code has to be manually written (even though wizards of various RAD tools including VS .NET and Delphi 2005 simplify things a lot). I believe MS overdid it.
I think if ADO is an example of a black box and Datasnap and ADO .NET are examples of boxes made of glass then ADO .Net box is more fragile than Datasnap is (you have to touch both to make them work, but more manipulations are necessary in case of ADO .NET and thus risk of breaking is bigger)
It is considered good, because for example a function should do what it is expected to do without any further side- effects and the developer using this function (inside the black box) should rely on it without knowing how it internally works. It is as if we are trying to step on a rock and we shouldn't worry about falling down or how the rock is "thinking" of handling our weight.
On the other hand, it has been used with a bad meaning because it doesn't let developers have full control of how something is achieved. An example is how ADO (simple ADO) handles applying updates. Some call it "automagically", some think it is black box programming (very... very black).
Where is the fine line that makes black box programming techniques useful and at the same time lets users have full control?
I believe an example that walks perfectly well on this thin line is Delphi itself. It is a RAD tool (automating a lot of procedures), but at the same time gives a developer full control of what is going on and how it is done. It performs things "automagically", but lets developers participate in magic (Aren't Delphi programmers magicians?!!).
On the other hand, let's consider ADO .NET. A lot of people complained about how ADO handles all applying updates logic in a black box not letting them intervene. MS with ADO .NET tried to balance on the thin line I am talking about and it is true that it gives developers full control (more than Datasnap I have to say). But on the other hand, a lot of code has to be manually written (even though wizards of various RAD tools including VS .NET and Delphi 2005 simplify things a lot). I believe MS overdid it.
I think if ADO is an example of a black box and Datasnap and ADO .NET are examples of boxes made of glass then ADO .Net box is more fragile than Datasnap is (you have to touch both to make them work, but more manipulations are necessary in case of ADO .NET and thus risk of breaking is bigger)
posted by Kostas Terzides at 12:26 μ.μ.
0 Comments:
Δημοσίευση σχολίου
<< Home