The post "C" era surely changed the way a software analyst approaches a problem - the Object-Oriented way. Object-oriented paradigm came as a big reprieve to the then ever-growing C community and a much awaited shift and focus on maintainability of code. And then the software industry started its ever-lasting bond with the words "design" and "architecture", which by then were more popular in other engineer streams including electronics/computer hardware.
The essence of good designs being Information-hiding, it has been advocated as the most popular and compulsory tool to build good designs. Therefore, nobody may even imagine to counter the obvious information-hiding paradigm.
Undoubtedly, information-hiding is a wonderful way to create software that are maintainable and encourage concurrent developments in large teams, off-late the thrust on information hiding has been so much so that it creates an impression of negativitism, restrictive world - an overuse of a wonderful design tool. And, as many(not most) modern architectures adapting the hyper-hiding techniques, the poor programmer might end-up either violating the architecture by silent tinkering or come up with a side-design that doesn't seem to violate the architecture and looks like a parallel to the original one but honestly a work around to the hiding-problem.
The benefits and wonderful usages of information-hiding has been cited in thousands of published papers and books and it's clearly a revolutionary tool that has benefited the industry. At the same time, it's the overuse that is the villain and leads to deliberate architecture tinkering and spoiling whole concept of software design - contrary to original intention. But why one has to tinker with a supposedly good design? Possible reasons can be-
1. Performance
This should be the single largest factor to influence tight-designs. The problem begins when the architecture doesn't provide a faster way of interaction among software components while there does exist one.
Undoubtedly, information-hiding is a wonderful way to create software that are maintainable and encourage concurrent developments in large teams, off-late the thrust on information hiding has been so much so that it creates an impression of negativitism, restrictive world - an overuse of a wonderful design tool. And, as many(not most) modern architectures adapting the hyper-hiding techniques, the poor programmer might end-up either violating the architecture by silent tinkering or come up with a side-design that doesn't seem to violate the architecture and looks like a parallel to the original one but honestly a work around to the hiding-problem.
The benefits and wonderful usages of information-hiding has been cited in thousands of published papers and books and it's clearly a revolutionary tool that has benefited the industry. At the same time, it's the overuse that is the villain and leads to deliberate architecture tinkering and spoiling whole concept of software design - contrary to original intention. But why one has to tinker with a supposedly good design? Possible reasons can be-
1. Performance
This should be the single largest factor to influence tight-designs. The problem begins when the architecture doesn't provide a faster way of interaction among software components while there does exist one.
For example, if an architecture doesn't allow interaction other than in XML format while the use of binary media at the same time doesn't pose any security threat (if, say, components are physically on the same machine. This kind of adventures are though more common in the performance intensive Online Transaction Systems.
The solution lies in designing interactions carefully and not getting carried away by a particular industry trend (afterall industry is what is competing with you!). Second, keep your options open for interface changes in your design. (Unfortunately, most modern frameworks are taking XML as de-facto without giving a second thought).
2. Too-tied-up
If a system is designed in too much of over-enthusiasm about information hiding and providing strict interfaces, it's more often than not that either it will lead to large design-violations or the coding team will invest sufficient amount of effort in struggling with finding an workaround to access hidden information by hopping up the interfaces - upcasting, downcasting, RTTI and what not!
The solution lies in identifying the information to be hidden carefully and not negatively. Most designs are based on fundamental "hide whatever is not required". Well, it should be "make accessible if it doesn't harm".
A good design is not necessarily restrictive and it shouldn't be. One of the by-products of restrictive design is that the programmers doesn't grow by time becoming true programmers and then architects but may end-up being just the developers. It would then be much more difficult to explain or justify a good design/architecture and possibly to sell the idea of architecture in software - forward to the past!
So, let it be a free world - and not so free that it becomes a crime!
The solution lies in designing interactions carefully and not getting carried away by a particular industry trend (afterall industry is what is competing with you!). Second, keep your options open for interface changes in your design. (Unfortunately, most modern frameworks are taking XML as de-facto without giving a second thought).
2. Too-tied-up
If a system is designed in too much of over-enthusiasm about information hiding and providing strict interfaces, it's more often than not that either it will lead to large design-violations or the coding team will invest sufficient amount of effort in struggling with finding an workaround to access hidden information by hopping up the interfaces - upcasting, downcasting, RTTI and what not!
The solution lies in identifying the information to be hidden carefully and not negatively. Most designs are based on fundamental "hide whatever is not required". Well, it should be "make accessible if it doesn't harm".
A good design is not necessarily restrictive and it shouldn't be. One of the by-products of restrictive design is that the programmers doesn't grow by time becoming true programmers and then architects but may end-up being just the developers. It would then be much more difficult to explain or justify a good design/architecture and possibly to sell the idea of architecture in software - forward to the past!
So, let it be a free world - and not so free that it becomes a crime!
