Monday, May 09, 2005

Hansleman's List: Aspect/Interface/Object -Oriented Programming

More from Scott Hansleman's list of what great developers should know: "Describe the difference between Interface-oriented, Object-oriented and Aspect-oriented programming." Aspect-oriented programming looks at how many components or pieces of a system might need to interact. The intersections of these pieces are what are important in AOP. "Crosscutting" is a slice across several units, all of which interact during some operation. The article Discussing aspects of AOP in Communications of the ACM, Volume 44, Number 10 (2001) shows an example of a drawing editor with point and line elements. If the drawing is moved, both point and line elements need to update. A crosscut hits these elements for this event. Other examples might include logging or exception handling which hit several different layers in a system. (Viji Sarathy, Aspect Orienting .NET Components ) Sarathy's article shows using attributes to "dynamically alter the manner in which the code executes", thereby causing events to be fired during runtime when a particular method, field or property is accessed. Interface-oriented programming is a contract-based approach. Nether side of the interface cares how the other does its work, only that the two sides can communicate via an agreed-upon contract. WSDL-based web services are the prime example of this. Object-Oriented programming is based on abstraction, encapsulation (data hiding), polymorphism and inheritance. Classes implement these concepts to build objects controlling or implementing a system. Abstraction allows loose coupling between components by providing a layer between objects so that one object isn't concerned with how the other implements its business rules. (Interfaces, layers) Great stuff when you want to isolate parts of the system so they can be swapped out without killing the rest of the sytsem. Encapsulation allows abstraction to work by hiding details of a class's implementation from calling classes. (Public vs. private fields) Inheritance enables base (parent) classes to have common functionality defined in it and passed down to child classes. A Shape class might have a field for color which is inherited by child classes of Square or Circle type. Polymorphism enables implementation of same-named public fields, allowing different classes to perform different actions on the same call - rendering a Square or Circle object differently in a graphic program, even though they might both be subclassed from a base Shape class. (Overriding)


Paul said...

Thanks, Jim, for at least trying to answer a very complex question! AOP has me entirely lost, and as for the difference between Interface and OOP, I still cant see it. Your attempt, however (the first I've read) is very much appreciated.

Jim Holmes said...

You're welcome, Paul. I don't know that I did that great a job explaining these, but I gave it a shot.

The article I liked to did a fair job explaining AOP -- but it took me several re-reads to start to getting a feel for what was going on. The paint example I mentioned from that article seemed to make good sense.

Interface vs. Object programming takes a bit of noodling out, too. I'm not sure I can come up with a clearer explanation that interface programming's really like having a contract between two sides, and either side really doesn't know or care about the other.

If you have access to it, take a look at Bill Wagner's Effective C#. He's got a very good blurb in there on using interfaces.

aliya seen said...

His book, focused on the benefits of getting software into well-defined components, does a great job of hitting the details on tough implementation issues while clearly laying out fundamentals needed to understand the problems. scheme programming help

Subscribe (RSS)

The Leadership Journey