First taste of Ruby

Googled and wrote a very simple Ruby program:


File.open("c:/model.ecore").each { |line|
puts line if line =~ /name="(\w+)" eSuperTypes=".*\1.*"/
}


Run Ruby in the command line, and... it just worked!

Although it's not a representative Ruby program, the fact that it just worked did impress me and give me more motivation to learn this buzzword.

Removing by not adding

When creating subclasses, there are chances that we want to remove some inherited operations/fields. This requirement appears more frequently when dealing with multiple inheritance. Why doesn't Java (or any other OO languages) provide a facility that does such removal? Because it is evil. This removal facility will rapidly create unmanageable code because no operation in a class is guaranteed to exist.

Then how do we deal with this case using OO paradigm? Well, if such requirement arises, it normally implies a bad design! We should decompose super-classes/interfaces (break into pieces), group those operations that we wanted to remove, and just not add corresponding classes/interfaces as super types.

Random Thoughts about API

API, Application Programming Interface, is meant to provide clients an easy and simple access to use a code package. (Although other stuff could have API too, I only talk about software here)

When designing an API, we should notice some of its additional benefits.

It helps you think clearly and explicitly what kind of work your code does. You can verify and be confident of the correctness (or should we say robustness?) of your code by testing the API. You can easily measure the performance of your code by profiling the API. A good designed API should hide as much as implementation details as possible. It is an abstraction of the entire code package. It tells about the essence of the entire code package. It helps you identify the boundary of your code package. By constructing an easy and simple API, we can avoid convoluted code logic and we have a clear purpose.

Test driven development is to design an API first in some sense: you design the "API" for the code unit, write the test for this "API" first, and then implement it.

So, when you design a code package, construct an API first. Should we call this API-driven development?