|
|
Friday, September 12, 2008
If you have ever had the need to isolate a task because it might bring down your applciation? You want to execute a task that needs a specific security context. You want isolate the task and its data. Well the AppDoamin is your new best friend.
Beginning at the beginning
To better understand .Net's AppDomain and how they affect the programs we create and work on, it'll be a good idea to start ground up. So let's start from the point we button click an application. Whenever we start an application, we're actually starting a Win32 process and running our application inside it. These processes use resource such as memory, objects, kernel so on and so forth. All processes process contains at the least one thread and if we are to run other tasks or open up other applications through our application, these tasks will belong to our particular Win32 process running on a collection of multiple threads. For WinForms applications the effect of this when executing on the UI thread can be seen when we make direct calls to long running processes. In that cause the screen to appears to lock up or become non responsive (enter the hourglass), this is also symptomatic of pre AJAX enanbled web applications. One of the cornerstones of a Win32 process is that it is very much like a closed room in your house. It's pretty easy to communicate within the room but the ability to communicate with those inthe room next to you or down the hall is problomatic. To interact with other Win32 processes, we would require some special mechanisms to work on as there are a couple of security contexts we would have to take into consideration and also the need to restrict what a Win32 process can and should given a particular set of circumstances.
Scenario
Consider the lowly desktop/ laptop in any given session at our workstations we are hosting 10's or hundreds of processes. Often we are not even aware of the wide array of processes that are working diligently on our behalf to keep the system running. Lets break down exactly what's happening in the scenario. Stepping away from the concerns of what variables are being used and how many may have the same name and who writes efficient software vs.... well enough said what are we really talking about to keep the engine running. At the crux of the issue what we're actually dealing with and what we would have to provide to these applications - Resources, resources and even more resources! The primary resource we are talking about is memory running a close second are security issues; therefore it is imperative that we force absolutely no communication of any sort between the processes of these applications. Wait what's the point of having a computer and all these applications if they can talk to each other. Ah the exception to the rule, there are frequent exceptions based on requirements, so many exceptions that perhaps that should be the RULE. Invoking these exceptional cases can and often does lead to frequent crashes. the instance where one process using up the memory allocated to another process can lead to unstable environments that eventually CRASH! I hate it! Everyone hates it! Especially customers. Anyway, our process dies,blows up, dies an unnatural death ect.. Nothing new it happens we are human after all not machines. These frequent crashes and run-time errors are usually caused due to inefficient use of memory leading to memory leaks, null object referencing, out of memory bounds you get the idea. From this example it becomes clear that running and maintaining processes are VERY expensive on a single workstation not to mention the effect this would have on oh say an App server or a Web server serving up several thousand web sites. Hence, It just isn't a good idea to use a large number of processes since they simply do not scale pretty well. So here's a pretty neat solution that was employed for the above situation. Running a host of multiple applications within a single process will enable us to use fewer resources enter the Web Server code name IIS. This would even result to faster execution. But here's another everyday scenario: in the case where one application crashes, every other application within this process goes down like a deck of cards! OUCH !! Who did that. And we wonder why system administrators are so protective of their servers?
A New Paradigm
Enter the .Net AppDomain. The main purpose of an Application Domain is to isolate our applications from other applications. Application domains run on a single Win32 process. The same solution that we just mentioned above can use an application domain and at the same time, limit the possibility of errors and crashes due to memory leaks while providing isolation, security context and protection of our application from other applications.
Hence we're running an application within an application domain and we further run multiple application domains within a single Win32 process. With the CLR's ability to run managed code, we're further cutting down on leaks and crashes. Objects in the same Application Domain communicate directly while Objects that exists in different Application Domains interact with each other by transporting copies of objects to each other or by using proxies for message exchange (by reference).
So that's the crux of an Application Domain.
Ah but theres more - It's actually a pretty neat light weight process that runs within a single Win32 process. Infact, as previously noted, we can run multiple Application Domains within a single Win32 process and much like Russian Nesstign Dolls  Domains inside of Domains.
Why would I want to do that? Another advantage of using an Application Domain is that we can destroy it through the parent without affecting other Application Domains that exist within that Win32 process. Therfore we can extrapolate that any work occuring in that Application Domain can be independent.
Bonus Features We can also use Application Domains to unload types by destroying the Application Domain that we have loaded it into- support for dynamicloading and unloading . The amazing .Net runtime enforces Application Domain isolation by ensuring control over memory use and therefore all the memory that is used by the Application Domains within a Win32 process is managed by the .Net runtime. (Read no heavy lifting on your part) We are avoiding almost all the problems that we mentioned initially such as one application accessing another application's memory and hence avoiding runtime errors followed by crashes. What we have actually done is provide a secure execution context that isolates current applications from talking to other applications. Practically speaking, Application Domains play a critical security and functional role especially when we're creating applications that do remoting like running web services.
Now how do we create a basic application domain?
A basic AppDomain issimplicity itself. The .Net framework provides a beautiful base class that exists within the System namespace so that we can explicitly create an AppDomain. Inheriting the System.MarshalByRefObject base class into our applications, we can create objects that communicate between and across different application domains.
Here is a simple application to create an AppDomain in C#.
The output the program creates is shown below
Better Known Framework
Sunday, June 29, 2008
A short post this time on a better known framework feature in .Net 2.0 +. A funny thing happened on the way to the demo today. I was preparing to demo some code to a group of developers and needed a function I had written back in the 10 .net days. This was a thin wrapper that allowed one to read configuration information out of the web or app config or a database. Being a careful programmer instead of just including the class and moving on to the demo even though I knew the code worked I thought I better compile this just to make sure.
Low and behold it compiled but I got some warnings well .... really one. You may have seen it before [ 'System.Configuration.ConfigurationSettings.AppSettings' is obsolete: 'This method is obsolete, it has been replaced by System.Configuration!System.Configuration.ConfigurationManager.AppSettings' ]. Not wanting to look dated or to have warnings or errors displayed in the demo I decided to get rid of the deprecated method and use the new ConfigurationManager. So off to the web I went Google -ConfigurationManager , MSDN - ConfigurationManager great documentation but still I could not get it to work. What was I doing wrong.... I had a reference to the system.dll assembly I could see the configuration namespace but no ConfigurationManager. Finally, just as I am about to give up and reinstall studio 2008 assuming I have a corrupt install I had not previously noticed the solution popped up in front of me. I searched msdn for the entire error message instead of just the new class I wanted to use.. There it was http://forums.msdn.microsoft.com/en-US/vblanguage/thread/d61a57ef-552d-45cc-8326-3ca3bc113699/ just add a reference to a new assembly System.Configuration. So there you have it; that's how you gain access to the ConfigurationManager class in the .Net 2.0 and above namespace.
Best Practice Better Known Framework
Monday, June 09, 2008
A friend of mine Denny Boynton and I were talking at TechEd last week about green computing and it started me thinking. He mentioned that he and some other architects were discussing green computing platforms (server vitalization, cloud computing,etc...). That started me talking about: What is the responsibility of the software developer in this emerging green computing grid? Many infrastructure groups over the last few years have been moving to virtual servers and environments initially to save on capital expenditures slow the ever growing demand for data center real estate.
Now after establishing the foundation for vitalization operations groups are seeing tertiary benefits form this process. Additional, justifications now include floor space reduction, reduced energy consumption, and energy savings from cooling requirements for data centers. Operational support teams are encouraging app dev teams to move their custom applications to these virtual instances and if necessary to modify applications that are not compatible to leverage this ROI for the company. The primary sales points given to App Dev teams are assurance that all servers are identical and the added speed that operations groups can scale out to support. Generally there are significant advantages to this trend towards vitalization, reduced surface space, reduced capital expense, lower maintenance cost, lower energy costs, higher reliability and scalability definitely a WIN WIN. That said how do we ensure that this continues to be a wining proposition.
What is the responsibility of the software developer in this new landscape? How can we ensure that this trend continues. I have developed and designed architecture for software for the last several decades. Over that time period I have increasingly heard comments like "we will just get more servers" and "memory is cheap" have become all to common. That along with approaches to application development that involve wide and deep data structures because "we don't want to go back to the server" for the data later, because we are lazy and don't want to make the extra call bloat our applications. Approaches and architectures like this will never preserve these new found savings we have found. We must change our approach to applications development. We should not avoid taking the extra steps necessary to ensure that we minimize our server footprint. Thoughtful design and architecture that ensures features are delivered to applications without excessive round trips to servers or the transmission of additional unnecessary data overhead are initial steps we can take. As developers should actively look to new technologies to improve user experience and reduce custom and non standard communications channels. In the .Net development space we should pursue WPF, WCF and Silverlight technologies to reduce the complexity of future applications. We should also actively review and seek opportunities to exit from legacy non mainstream Microsoft platforms. Finally, we need to proactively lobby vendors to include the features that support that enables developers to concentrate on productive business functionality and less of plumbing applications and injecting potentially faulty, difficult to maintain code that tightly ties applications to their deployment paths and infrastructure.
Architecture Best Practice Programming Design
Wednesday, June 04, 2008
I have spent the better part of the last three days in sessions at Microsoft TechEd listening to folks talk about: What is an architect? How do we identify them? Are they born or taught? Are there good architects and bad architects, what differentiates them? Why are architects seen as “a necessary evil” are they just overhead. What do they contribute? I apologize in advance for the lengthiness of this post but this is a core value point to me and I tend to get very wordy when an issue is near and dear to my heart.
The Why of it all - I don’t know, what are we really asking
Why are we asking this question? Are we trying to justify our existence? Are we trying to improve our profession? Is it a role or a title maybe both why do we care? Are we experiencing a midlife identity crisis? Or is it just growing pains? How many people in other positions do you know that are questioning: Who am I: What do I do? I have heard many definitions of an architect over the last few days ranging from software police to conductor and artist. If there was ever a career field in catatonic crisis this is it. Unfortunately I also feel compelled to offer up a definition of IT architect. While I could not come up with a single word analogy to describe or be synonymous with architect lets try a long winded definition. After all what we do is important aren’t we worth more than a single word. I suspect that few if anyone will like my definition but most will likely identify it as true.
Architect Defined in General
The architect defined - On a product development effort anyone who makes a decision that materially affects the financial cost, business value, technical infrastructure or technical implementation or direction is by default an architect making architecturally significant decisions and is acting in the architect role.
The Reality of it all – Often we just aren’t Empowered
This may or may not be “The Architect” who generally is the person anointed by someone, on high in a position of power, to be responsible for the architecture artifacts. In fact I would submit to you that in most cases the architect on projects is rarely The Architect and there in lies our problem. There is not a clear identification of roles and responsibilities along with the power to veto. Everyone is an architect because throughout the SDLC each individual contributor more likely falls within the scope defined above at some point. From the Customer, Project Manager, Sr. Developer to the developer and lets not forget management in general.
Civil/Architectural Architects vs. Software Architects (Case Study)
As a simple non scientific case study let’s compare the civil architect to the software architect. Perhaps in examining why civil architects are successful we can glean a perspective into where our real problem lies.
On software development efforts unlike construction projects the power of veto for how things get built almost always lies with the plurality of those with the money and those managing the money. It is the reverse on a construction project the final say as to how to build the bridge, road or house is ultimately in the hands of THE ARCHITECT. Does he work within constraints financial and time related sure. Scope budget and time are ever present in almost any undertaking that requires developing / building something. This is because it is understood and accepted that the civil architect is the expert in the rules, code and laws regarding construction and more likely than not specializes in the specific domain in question. He is the de-facto expert on form function design and codification for the project and all acknowledge that.
So why is the civil/architectural architect so much more powerful than the software architect? The answer is simple: it has little to do with power and more to do with empowerment. Civil and architectural architects have been sanctioned and empowered with the responsibility by others outside of the project. These people insist the architect take responsibility for the design and direction. Don’t think for a moment that there are not carpenters, concrete workers, brick layers and others out there saying, “this is crazy why do it this way I know how to do it better”. They are there but I can guarantee you that none of them are willing to deviate from the blueprints handed down from the ARCHITECT. That is because the customer, the financier and the state insist that they have empowered the architect to design and architect the appropriate and safe direction for the construction of the bridge, road or house.
An Architects view on Architects
A good friend of mine who works for Microsoft and fellow architect (Denny Boynton) recently wrote an interesting blog on The Role of the Architect. In this article he poses that there are many forces exerted on the software architect both internal and external to the project. In the face of these forces it is the fundamental role of the architect to blend technical capabilities, business needs and corporate cultural factors into a “Best Fit” solution for the circumstances. In short the job of the architect is to understand the customer needs, business value, technical and operational landscape and weight these factors appropriately against the corporate and IT strategy to determine the correct course of action. He also notes that t is not the role of the architect to become embroiled in the “religious wars” that erupt around technology.
While I concur that religious zeal around technology is not appropriate in the context of defining a project’s technical direction. I disagree that it is the role of the architect to avoid or shun those technology conflicts. Unwillingness on the architect’s part to wade into the fray and shout above the fray “Follow Me” is an abandonment of his responsibility to provide guidance and direction in his area of expertise and to make sound judgments for the technical direction of his organization.
The fact that “religious wars” are even taking place brings into question the abilities of the architect. At the core one of the fundamental duties of the architects’ is to provide the vision for the implementation, adopting and exit strategy for technologies within the corporate framework. Additionally, justification is needed identifying how they relate to the corporate business and IT strategy. It is also the responsibility of the architect to provide a clear and concise vision of how technologies are to be used for business value and how that also relates to the corporate bottom line. In this light the development and management community should no longer have a need or desire to engage in “religious wars” as everyone can clearly see how technology is to be leveraged for business benefit. At worst there should only be minor skirmishes around the overlapping areas of the capability models that can easily be resolved.
Types of Architects
From my comfortable armchair I look out on the domain that is information technology and see that we go to great lengths to differentiate the numerous types of architects as if therein lies the ability to rank them. There are no less that 12 types I can think of off the top of my head no doubt you can think of many more:
Enterprise Architect
Solution Architect
Application Architect
Data Architect
Integration Architect
Infrastructure Architect
SAP Architect
Microsoft Architect
Java Architect
Data Warehouse Architect
Domain Architect
Network Architect
As you look at these title/roles, daily hats you wear you may notice that they all have one thing in common the word ARCHITECT. The word architect in each of these roles is the noun the word(s) immediately prior is the adjective enhancing and adding specialization to describe the type of architect. In the end we are all architects and as such should be able to define a common set of activities, goals and actions that define us. I would submit that in the final analysis there are really three kinds of architects
Empowered Architects – Those who are given the power to effect change within the enterprise domain or problem space.
Consulting Architects – Those who provide recommendations and best practices direction only, but cannot effect change.
Ad Hoc Architects – Those who in the absence of empowered architects make decisions based on the problem presented to them irregardless of the enterprise domain or problem space.
Final Observations
In closing let me posit that the real issue that plagues our profession is not; what is an architect or even who should be an architect? No matter what criteria we place on the table as the hurdle to overcome there will always be good bad and indifferent architects just as there are good bad and indifferent teachers, doctors lawyers, CEO’s …. What we are missing are the certifications, standards, and characteristics that define what makes an architect and architect. You do not grow up to be an architect by putting in your time as a developer and graduate to architect by virtue of time in service or it’s the next promotion step. I contend that we can fairly easily identify common actions, traits and disciplines that are indicative of the people we what to give the title and role of Architect to. I provide those listings below for all to consider as my closing words on “What is an Architect”. I will leave the measurement and certification question to another day as it is much more politically charged even than this question.
Actions that indicate Someone is an Architect
- They consider the enterprise, business and technology landscape when crafting and directing the solution so that it adds business value while reducing impact to the core infrastructure.
- They refrain from engaging in the defeatist arguments of technology bigotry while striving to seek a middle ground and achieve a balance of technologies in the enterprise.
- They are the consummate politician employing all of the strategies of negotiation and influence to achieve goals that further the companies’ strategic objectives through the use and application of all technologies in their arsenal.
- There are above all scholars and teachers of the discipline of architecture exuding a desire to foster better understanding among their peers and others they council and provide guidance too. The hunger for knowledge and actively seek out opportunities to broaden their technical portfolio.
Traits that Identify Someone as an Architect
- They understand and support technology decisions based on a process that maintains a holistic view of the applications, solutions platforms, and business processes that enable the achievement of business goals. Planning the future technologies based on alignment to business strategic goals.
- The embrace Architecture as the discipline of thinking and planning how Information Technology implementations will support business strategies now and in the future with the least amount of friction
- They accept responsibility for developing, maintaining and envisioning the technology direction that best enables the priority business activities of their company and facilitates the adaptation of technology to the changing business needs.
- They work with business units, application development and IT Operations to ensure current, short and long term goals are being realized.
- They foster architectures that include the frameworks, networks, deployment configurations, domain architecture, and supporting infrastructure that form the technical architecture for the enterprise.
- While they specialize in one particular technical area, they must always maintain currency in each of the core disciplines. Without this broad general knowledge, they will be unable to design effectively, as problems and opportunities will not be evident.
Disciplines
- Business Strategy.The role of IT is to make businesses more successful in meeting their strategic goals. An Architect must be able to understand those goals as expressed by the client, and translate them into winning IT strategies. The role of the Architect is not to help the client develop their strategy, but to help the client execute it with technology, process and IT operations as leverage points to deliver strategic value.
- Financial Management.The Architect must be able to analyze, in more than a superficial way, the financial impact of current operations and of proposed changes. The Architect’s job is to show senior management how to evaluate the options presented from an investment point of view.
- Business Process Design.The Architect must carefully consider business processes as part of the design process; after all, the goal is to make the processes more effective and (usually) less costly. Without understanding how to think of business processes, and how to change them, the architect will be unable to go beyond the level of talented craftsman.
- Organizational Dynamics. Frequently technology deployments fail because of inadequate consideration of the effects of the change on organizations. Organizations tend to evolve, and at any given moment most organizations will reflect the hard-learned lessons of the last generation of technology. The challenge for the Architect is to help make the transition to new designs in such a way that the new design can be managed by the changed organization, and that the financial benefits predicted can indeed be obtained.
- Information Technology.Without a firm grasp of all areas of information technology, the Architect is doomed to mediocrity. The Architect must understand application design, the Internet technologies, database and data warehouse design, network design, and the many other aspects of information technology at a thorough, cross disciplinary level.
Architecture Design
Tuesday, June 03, 2008
An argument for Interface based design and programming
For software to survive in the ever-changing jungle of the production environment, it must have three distinct characteristics: reusability, maintainability, and extensibility.
Interface-based programming exists outside the world of COM. It is a programming discipline that is based on the separation of the public interface from implementation. It was pioneered in languages such as C++ and Smalltalk by software engineers who discovered that using distinct interfaces could make their software, especially large applications, easier to maintain and extend. The creators of Java saw the elegance of interface-based programming and consequently built support for it directly into their language.
Interfaces solve many problems associated with code reuse in object-oriented programming. This document will discuss what some of these problems are. In particular, when you program in a style consistent with classic OOP, a client can build inflexible dependencies on a class definition. These dependencies can make it difficult to maintain or extend the class without breaking the client. It becomes tedious or impossible to improve the code for an object over time. Certain problems are also associated with a popular OOP language feature known as implementation inheritance. This powerful but often misused feature is vulnerable to similar dependency problems, which compromise an application's maintainability and extensibility. Since most 3GL languages support implementation inheritance, this document will discuss its strengths and limitations in order to address some of the problems that interface-base programming was created to solve.
Separating the Interface from the Implementation
Object composition offers another way to achieve reuse without the tendency toward tight coupling. Object composition is based on black-box reuse, in which implementation details of a class are never revealed to the client. Clients know only about an available set of requests (the what). Objects never expose internal details of the response (the how).
Black-box reuse is based on formal separation of interface and implementation. This means the interface becomes a first-class citizen. An interface is an independent data type that is defined on its own. This is an evolution of classic OOP, in which a public interface is defined within the context of a class definition.
At this point, you are probably thinking that this is all pretty vague. You're asking yourself, "What exactly is an interface?" Unfortunately, it's hard to provide a concise definition that conveys the key concepts of an entirely new way to write software. An interface can be described in many ways. You can get up to speed pretty quickly on the syntax for defining, implementing, and using interfaces. However, the implications that interfaces have on software design are much harder for the average programmer to embrace. Learning how to design with interfaces usually takes months or years.
At its most basic level, an interface is a set of public method signatures. It defines the calling syntax for a set of logically related client requests. However, while an interface defines method signatures, it cannot include any implementation or data properties. By providing a layer of indirection, an interface decouples a class from the clients that use it. This means an interface must be implemented by one or more classes in order to be useful. Once an interface has been implemented by a class, a client can create an object from the class and communicate with it through an interface reference.
You can use an interface to create an object reference but not the object itself. This makes sense because an object requires data properties and method implementations that cannot be supplied by an interface. Because it is not a creatable entity, an interface is an abstract data type. Objects can be instantiated only from creatable classes known as a concrete data types.
From a design standpoint, an interface is a contract. A class that implements an interface guarantees the objects it serves up will support a certain type of behavior. More specifically, a class must supply an implementation for each method defined by the interface. When communicating with an object through an interface reference, a client can be sure the object will supply a reasonable response to each method defined in the interface.
More than one class can implement the same interface. An interface defines the exact calling syntax and the loose semantics for each method. These loose semantics give each class author some freedom in determining the appropriate object behavior for each method. For instance, if the IDatabase interface defines a method named ExecuteSql(string commandText), different class authors can supply different responses to the same request, as long as each somehow reinforces the concept of running a sql statement. The OracleDatabaseConnector class can implement ExecuteSql() in a different way than either MSSqlDatabaseConnector or SybaseDatabaseConnector. This means that interfaces provide the opportunity for polymorphism. Interfaces are like implementation inheritance in the sense that they let you build applications composed of plug-compatible objects. However, interfaces provide plug-compatibility without the risk of the tight coupling that can occur with implementation inheritance and white-box reuse.
Note that this is an example only I am not sure I could ever justify doing this or argue that this is a good thing unless your are forced into it. I felt compelled to implement this due to usage restrictions in a corporate environment. In an effort to foster reuse (topic for another time… How and when to write for reuse) and comply with some misinterpreted security policies a wrapper was written around .Net native Data Access to “Protect” developers from themselves and to hide database connection strings from developers at runtime in the IDE. DON’T ASK HOW… that’s a story for another day.
The Two Faces of Inheritance
Inheritance is an objected-oriented concept that models an "IS A" relationship between two entities. So far, this article has used the term implementation inheritance instead of the more generic term inheritance because extending a super class with a sub class is only one way to leverage an "IS A" relationship. When a class implements an interface, it also takes advantage of an "IS A" relationship. For instance, if a class OracleDatabaseConnector implements the interface IDatabase, it is correct to say that an OracleDatabaseConnector "IS A" Database. You can use an OracleDatabaseConnector object in any situation in which an IDatabase-compatible object is required.
Interface-based programming is founded on a second form of inheritance known as interface inheritance. This means that inheritance does not require the reuse of method implementations. Instead, the only true requirement for inheritance is that a sub class instance be compatible with the base type that is being inherited. The base type that is inherited can be either a class or a user-defined interface. In either situation, you can use the base-type references to communicate with objects of many different types. This allows both forms of inheritance to achieve polymorphism.
Both forms of inheritance offer polymorphism, yet they differ greatly when it comes to their use of encapsulation. Implementation inheritance is based on white-box reuse. It allows a sub class to know intimate details of the classes it extends. This allows a sub class to experience implicit reuse of a super class's method implementation and data properties. Implementation inheritance is far more powerful than interface inheritance in terms of reusing state and behavior. However, this reuse comes with a cost. The loss of encapsulation in white-box reuse limits its scalability in large designs.
As the term black-box reuse suggests, interface inheritance enforces the concepts of encapsulation. Strict adherence to the encapsulation of implementation details within classes allows for more scalable application designs. Interface-based programming solves many of the problems associated with white-box reuse. However, to appreciate this style of programming, you must accept the fact that the benefits are greater than the costs. This is a struggle for many programmers.
When a class implements an interface, it takes on the obligation to provide set methods. Sub class authors must write additional code whenever they decide to implement an interface. When you compare this to implementation inheritance, it seems like much more work. When you inherit from a class most of your work is already done, but when you inherit from an interface your work has just begun. At first glance, implementation inheritance looks and smells like a cheeseburger, while interface inheritance looks like a bowl of steamed broccoli. You have to get beyond the desire to have the cheeseburger to reach a higher level of interface awareness. The key advantage of interface inheritance over implementation inheritance is that it is not vulnerable to the tight coupling that compromises the extensibility of an application.
Why Use Interfaces?
When developers learn how to use interfaces in an application, they often wonder, "Why would I ever want to do that?" or "Why should I care?" Programming with class-based references seems far more natural compared to the additional complexity required with user-defined interfaces. The previous example would have been far easier if the client code programmed against public methods and properties of the OracleDatabaseConnector class instead of the IDatabase interface. User-defined interfaces seem like extra work without any tangible benefits.
There are several significant reasons why a programmer should care about interfaces. The first reason is that interfaces are the foundation of Services they define the contract. In a services environment clients can use class-based references but imagine the power contract based programming. Instead of class objects you access and program to their published interface the contract is immutable the objects are not. This provides a greater degree of isolation and protection from changes in the service and a high degree of flexibility through interface references. I know this sounds like the fundamentals of COM. Isn’t COM dead? Yes is died with a whimper and a cheer but the rules we lived with port directly to the WebServices and SOA enabled world. If you embrace interface-based programming, you will become a much stronger programmer.
Another reason why you should care about interfaces is that they can offer power and flexibility in software designs. Using interfaces in your programming becomes valuable when you don't have a one-to-one mapping between a class and a public interface. There are two common scenarios. In one scenario, you create an interface and implement it in multiple classes. In the other scenario, you implement multiple interfaces in a single class. Both techniques offer advantages over application designs in which clients are restricted to using references based on concrete classes. While interface-based designs often require more complexity, the sky is the limit when it comes to what you can do with them.
Consider a case in which many classes implement the same interface. For example, assume the classes CSecurityProvider, CSettingsProvider, and CNotificationsProvider all implement the interface IProvider.
An application can maintain a collection of IProvider-compatible objects using the following code:
Well thats neat but how is that of use? I can accomplish the same thing with a generic collection or an array of object type. Yes your right but where is the value add? How do you know what is in your generic collection or array of objects?
First lets assume that the interface defines a method/contract of GetData() and that an array of providers is provided in the constructor of the containing class. Lets also assume for this example that each Provider needs to call the GetData method in the constructor of the containing class. A simple for loop can be used to accomplish this for all the IProviders.
Another scenario could be that you only want to call the GetData method on the SecurityProvider and verify the user is authorized before continuing. Now our simple loop has become a bit more complex.There are two ways to accomplish this I would recommend the second for simplicity,elegance and clarity.
Example 1
Example 2
This has by no means been an exhaustive discussion of interfaces but I think you can begin to see the value and power that design by interface can bring to you applications.
Architecture
|