Blackbox and whitebox.

-

White box –

A system whose internals are known to the outer world is called a white box system. User knows about all modules defined inside the box (or solution or system).

See in figure below –
Think a system X which has 6 module in it (A, B, C, D, E, and F), all are open.

Why white box is bad design?

I am sure you must have used some external library in your project or while practicing programming. The library will give you only its public interface so that developer can call it, but it will not show its internals (the core logic how they are doing it). 

 Now think if libraries’ modules are open to you. Now client/developer can call the core part of it. Sounds good but let me list out the drawback of it -
  1. You have to know all the internal modules and understand the flow. Before it was not our headache, we just called public interface.
  2. Any new changes in the library (introduced by third party), including new functionality or changes in behavior of core logic, will make us change our code accordingly and re-compile it (sometimes).
  3. It will become a highly coupled system, which is terrible.
  4. Client, as well as library provider, will not think to make changes and improve library functionality.

Black box –

A system whose public behaviors are open to the outer world and hide/abstract core logic of the system is called a black box system.
The funda is to take input from the outer world, process it, and give back the result, but how they handle it only they know. There would be N number of modules working to solve the problem, but those are not known to the client/user/outer world.

For external users, any system should be a black box system. The user should not have any ides about the inside logic of the system. He should know the only feature of the system (not the interior components of the system).
Thanks for reading it. To learn more about design patterns and basic design principles, please see my web page.

Comments

Post a Comment

Popular posts from this blog

Non-virtual interface idiom (NVI)

-
In almost every cases, it’s recommended to follow OOAD principles, but sometimes we should try to look some other alternatives, provided by programming languages, which could be a better options for certain situations. In C++, we can implement virtual function in private and we can redefine its behavior in derived class's private  and it will work in same way(did you try that?). When we define virtual function as private and expose a non-virtual public function to outer world, we call it “ non-virtual interface idiom ”. Non-virtual public function will internally call virtual function, in other words you are not exposing your virtual function to client. You will achieve high encapsulation, plus we can add pre and post execution/condition in the body of non-virtual public function. Call some set of functions, as prerequisite of calling virtual function, and after call returns from virtual function, again call some set of function as part of post cleanups/conditions,
Read more

Architectural patterns => Mud to structure => layers.

-
Image
Background - We apply mud to structure when a large system requires decomposition. If you notice, your application/requirement has verity of logical units which can be decomposed into a group of sub-tasks, first,  group them into different levels of abstraction. One abstract unit perform a totally different task(s) from other units, but any unit alone is not enough to give meaningful service to customer. Actually, different issues/solutions are splinted into different abstract units. Second,  after you divide them into different units, if you see a mix of low and high-level dependencies, where high-level operations depend on low-level operations, then assume those logical units as layers, third draw a dependency diagram between layers.  If control flows from high to low layer (or dependency diagram forms a stack, one layer on top of other), you can think of implementing it through layer pattern. Layer architecture - We can have many components in one layer. Layer
Read more

Architectural style -> Adoptable system -> Reflection.

-
Image
Background - We have discussed very less about reflection, especially if you are C, C++, mainframe, LSI developer and working on server side implementation or in low level hardware-interaction development team.  But it is very popular among high level languages like JAVA, Scala, C#, Python etc, many languages have implemented reflection in it.  It gives you flexibility to do things dynamically (at run-time). After working closely with different clients, you will get a clear understanding that no one is as confusing as a software client, not even your girlfriend! So we should have a flexible architecture in place who can absorb shocks of client’s last moment changes. Not only that, sometimes we have N number of different behaviors and structure in place, and we want our application to behave differently depending upon run-time situations. Let’s build understanding step by step through an example. Think you have got an assignment where you have to build an application
Read more