Four Tenets of OOP

The following are the core tenets of OOP.

 

• Abstraction
• Encapsulation
• Inheritance
• Polymorphism

Let us see each of these in detail

 

Abstraction: Abstraction is the concept which enables you to model an otherwise complex real life entity in a simpler way that our limited brains can understand. Abstraction is core to modeling sofware systems. It means to concentrate on the necessary things and highlight the ones which are crucial to solving the problem at hand, without worrying about the details which are not relevant to the problem hand.

 

What does that mean?
Assume you have to model Prakash, Sendhil and Manu for a payroll processing system. Prakash, Sendhil and Manu can be modeled as objects. These can be classified under the Employee class. This Employee class is an abstraction representing the real world entities Prakash, Manu and Sendhil in the context of a Payroll processing system. Their basic pay, joining date, bonus pay, incentive, hours worked or each of the months will be attributes of the Employee class.

 

But what about the other details about Prakash, Sendhil and Manu like what languages they know, what frameworks they have worked on, what is their experience level in each of these skills etc. These completely irrelevent with respect to the Payroll system. But these might be completely relevant in a Skill management system.

 

Abstraction also in modeling context could mean leaving out / hiding the implementation details in the early stages of the model lifecycle or in the high level arhcitecture of the system so that one can get the big picture. But we are just hiding these implementation details, these have to be there in some other view of the model. This is especially crucial if dont want to throw the model away after understanding the system. This makes sense if you want to do model driven development.

 

As a non software example, consider the braking system of your car. As a driver of the car you just need to know that pressing the brake pedal, applies the brake and stops your vehicle. That’s the details you should know about the brake to use it. On the other hand a mechanic needs to work with the braking system at a different level of abstraction. He needs to know how it works. Is it a disk brake, or is it a drum brake. How do the hydraulics work etc. In other words he works at a different level of abstraction.

 

Encapsulation: Encapsulation is what the name says, grouping together data and the operations on the data into a single capsule. As capsule protects its content inside, an object will protect the data which it manipulates. So to an object purist all data will private and he’ll provide operations which can manipulate the data. This ensures that the object is used in the way it was intended and to and ensures that the client cannot corrupt its internal state. This also ensures that the object developer can vary the internal implementation details without the client being affected by it. Encapsulation allows the client to be insulated from the internals of an object.

 

As an example consider the multicast delegate class in .NET. A multicast delegate maintains a list of (single) delegates to be invoked in the delegate chain. This list is an internal data structure which is private. U can manipulate the list of delegates maintained in the multicast delegate object using the method provided by .NET, "Combine". Since this data structure (its actually a linked list) is private to the multicast delegate object, the .NET framework developers can change this to a sorted list tomorrow if needed. But none of the clients have to be changed because they do not rely on the internals of the object.

 

Property procedures are also considered as violation of encapsulation in a pure OO sense. It is because they externalize the state of an application. But such a view is probably too puristic, use your judgement to decide. For examples your DTOs(Data Transfer Objects) have only property procedures. But its ok to have them, even if they violate encapsulation in true sense.

 

Inheritance: This is probably the most popular tenet. This is probably the most abused one too. Inheritance is the concept by which you generalize in the base class and specialize in the derived class. Inheritance models an ‘is a’ / ‘kind of’ relationship. For example a FileStream is a stream, MemoryStream is a stream, NetworkStream is a stream and so on. How can we generalize in the base class and specialize in the derived class? Welcome to the next tenet polymorphism.

 

Polymorphism: Polymorphism means one name, many forms. So how does it help us?

 

Let us consider the same example given in the inheritance example. Let us say that you are writing a serialization component. It can either write the ouput to MemoryStream or NetworkStream or FileStream. If there is no inheritance you’ll end up writing this Serialization component for all the three cases. That’ll by quite some duplication. Since you have a base class Stream, you can use the base class variable to open, write data and close the stream after the serialization. Your method can take a prameter of type Base class Stream. If you call Open or Write or Close it is dispatched to the actual dervied type passed to the serialize method. The class to dispatch is not decided at compile time based on the variable type (The call has to be dispatched to the Stream class then). Instead the method to which the call is dispatched is decided based on what is the type of the instance passed to the method at runtime. The same open call is dispatched to the NetworkStream if the Stream parameter holds a NetworkStream instance or a FileStream if the Stream parameter holds a FileStream instance.

 

Polymorphism provides an opportunity tremendous amount of reuse and extensibility. How does it help in extensibility? Assume you add an EncryptedStream tomorrow you still need not change the Serialize methods as long as your EncryptedStream class inherits from the Stream class. Thus polymorphism allows your code to work with classes that you do not know at the time of writing your piece of code. This is what which provides extensibility.

 

What we discussed is runtime polymorphism. Method overloading / operator overloading is an example of Compile time polymorhism where the dispatch to the method is decided at compile time. Another classification is interface based polymorphic dispatch versus inheritance based polymorphic dispatch.

 

It is absolutely essential for any OO developer to understand all these four concepts and apply them. But in reality it is not the case. Out of the 100 odd guys who I would have interviewed so far only 2 or 3 were able to explain all of these four tenets thoroughly. So when Manu is saying that Programming as a profession has not matured in India, He is probably right.

 

PS: Manu, Prakash and Sendhil are a reincarnation of the three musketeers ;-). Manu and Prakash are my pals. Prakash is an Agile PM. Sendhil is your truly and Manu is the reluctant citizen who doesn’t want to be a netizen.
 

Blogmark: Roadmap to high performance XML

http://clariusconsulting.net/blogs/kzu/archive/2004/07/09/HiPerfXML.aspx

Powered by Qumana

Applying Design Patterns

Nice case study, A must read if you are applying design patterns
http://junit.sourceforge.net/doc/cookstour/cookstour.htm

Powered by Qumana

ASP.NET 2.0 VirtualPathProviders

One cool thing in ASP.NET 2.0 is the concept of VirtualPathProviders. You need not have to serve your pages from a filesystem always. For example you can serve your pages from the database. The VirtualPathProvider supports CacheDependency based invalidation of your content. One quirk though is what if your web server is on a DMZ and cannot access the database? I wrote a provider for such a scenario. I wrote a WebServiceVirtualPathProvider. So far so elegant. But to provide invalidation you have to write some kludge code which I don’t like. Has someone faced a scenario like this?

Powered by Qumana

Blah.Blah.Blog: How redundant is your manager?

Nice entry from a thoughtworker. 

Link to Blah.Blah.Blog: How redundant is your manager?

Good SQL Links

Dynamic Search Conditions in T-SQL

http://www.sommarskog.se/dyn-search.html

The Curse and Blessings of Dynamic SQL

http://www.sommarskog.se/dynamic_sql.html

Powered by Qumana

Software Factories / Guidance Packages from Microsoft

Web Service Guidance
Web Client Guidance
Smart Client Guidance
Mobile Client Guidance

Powered by Qumana

Testing 123 from Qumana

Test Post

Powered by Qumana

Web Services and Financial Services industry (Trading)

I was having a discussion with Manu the other day usage of services in the real-time trading systems. I decided to google for some information regading this. This post is a book(blog)mark of all the results for reference. This is what I understood after glancing through these stuff. Trading involves mutiple parties and hence multiple systems. The use cases for web services is integration. Either Technology Integration / Application Integration. Even if we are not there today with respect to performance, Eventually Web Services will get into this domain primarily because of the Integration involved in the life of a Trade.

A Web Services Architecture for Straight Through Processing (STP):

http://www.edgewater.com/NR/rdonlyres/3E74677C-65E5-449F-A58D-8211ACEC0168/0/EdgewaterTechnologyWebServices_STPWhite Paper.pdf – compares the existing architecture with an Web Service based proposed solution.

Evaluating SOAP for High Performance Business Applications: Real-Time Trading Systems:

http://www2003.org/cdrom/papers/alternate/P872/p872-kohlhoff.html -compares the performance of your traditional Fix based solutions with Web Services. Still Web Services have a long way to go in terms of performance 😉

A B2B Architecture for accessing real-time Financial Trade Data

http://www.financeit.unsw.edu.au/docs/SidsThesisReport.pdf

A Case Study in Developing Web Services for Capital Markets

http://citeseer.ist.psu.edu/706996.html

Performance Issues in Integrating a Capital Market Surveillance System using Web Services

http://citeseer.ist.psu.edu/dabous03performance.html

Using Software Architectures and Design Patterns for Developing Distributed Applications

http://citeseer.ist.psu.edu/705822.html

Using straight-through processing to successfully ride the equity derivatives wave

http://www-03.ibm.com/industries/financialservices/doc/content/resource/thought/1618642103.html

Collections in .NET

Strongly typed

• Array
  Predefined size, used for passing data around.

• ArrayList
  Easy to work with, provides basic collection functionality and can easily be converted to an Array.

• CollectionBase
  Abstract base for building your own collection classes.

Weakly typed

• Hashtable
  Provides high performance access to items in the key-value pair collection, by a specific key.

• DictionaryBase
  Abstract base for building your own collection classes using a key-value pair.

• Queue
  Implements the FIFO mechanism.

• Stack
  Implements the LIFO mechanism.

• SortedList
  Provides access to items in the collection by a specific key or an index.

More info can be read here. A simple, to the point article. If I have some time I’ll update it for 2.0 considering Generics in the equation.