One of the recurrent problems I see when teaching OO design is the “names” used by the programmers to name classes, methods, etc.
The problems are different depending if attendees are from the industry or the university. At the industry I see that names are wrongly selected, bias technology names, while at the university it is common to see the lack of ideas to name things (which makes sense because they have less experience). I will concentrate on the problem I see at the industry.

Basically the problem can be summarized as using names towards the technology model instead of the business model. I’ll show a few examples that will clarify the idea.
1) I usually use a problem when teaching the introductory OO design class, where attendees have to model a traffic light (“semáforo” in Spanish). This problem has many interesting edges like what really is a “traffic light”, is it just the one that control the traffic on a street or in a corner (or street intersection)?, but besides that and going to the problem of this post, it is interesting to see the names that are used to call the class that will model that concept. Usually those names are “LightContainer” or “TrafficController” instead of just “TrafficLight”. Clearly “TrafficLight” is a better name because it is the name used in the problem domain and therefore using it in our model will narrows the semantic gap, but why do attendees think on those names?
2) Another example I use, in this case on the TDD course, is to model a on-line shopping store. That problem is really interesting because there are many many concepts to model that usually are ignored or not seen by most attendees, like shopping cart, the cashier or the just the sale. Shopping carts are generally discovered and modeled, but sometimes attendees use names like “ProductContainer” or similar.
The cashier is a interesting case. I guide the solution using a metaphor on real supermarkets so they can see that when it is time to pay, it is the cashier responsibility to do the sum, debit that amount on your credit card and so. But it is funny to see that even when I use the word “cashier” sometimes the class that models it as “SaleTransaction” (not realizing that the sale is the result of what the cashier does) or “CreditCardService” or “PaymentManager” and the like.
The sale is an object that usually nobody see and therefore it is not modeled. After the attendees realize that concept has to be modeled I go to the next issue, that is where to “store” the sales. Sadly, and as much as I repeat during the course to think about the problem domain, I usually get names for that object like “SalesRepository”, “SaleDAO” or the like instead of “SalesBook” (in Spanish “LibroDeVentas”, a well know accounting term).

Why does this happen? Why the right names are not selected? I realized after given these courses that the pattern is the same: the selected names are thought from a “technology” point of view, as programmers; we do not use the words of the problem domain in our programs.
I mean, I don’t know any accountant that calls the sales book as “sale repository”, neither “sale dao”, and I never saw any supermarket employee call the shopping cart as “product container” and my wife never called a traffic light as “traffic controller”.... what is the problem?
The problem is that we continue programming (modeling) focusing on the technical side and not on the problem domain side. Of course, if we go to a supermarket we will not tell our companion “please, give me that product container” but “please, give me that shopping cart”. Why?, because we are not programming there, we “are” in the problem domain “for real”.

Ok, let’s assume that that is the problem, why do I see this problem on the industry and not at the university? I think this is due to some kind of “infection” that people at the industry get from models, frameworks, finally examples that students at the university has not been exposed yet. As humans we learned (a big deal) from examples, and sadly most examples we have are really bad at giving names, sometimes because “hey! it is just an example” and sometimes because the ones that wrote the framework, model or example has became part of this vicious circle and therefore the names they use are like those we later choose, that is “nnnContanier”, “nnnRepository”, “nnnController”, etc.

How can we avoid this mistake? First of all realizing that we have to make a change in the way we think, we have to start thinking on the domain problem and not on “programming issues”. Date is called Date and not “NumberContainer”, and String is called String and not “CharacterCollection”, those are good examples of names thought from a problem domain point of view. After that, we can use a smell to see if we are choosing incorrect names. The smell is basically to see if the name has words like container, repository, service, controller, manager or any of the design pattern’s name (again, Directory is called Directory and not FileComposite or the like). But please remember, this is a smell, not a rule!, sometimes we have to use names bias technology issues, and that is basically when modeling a technological problem domain.

So from now on, if a name you think for a class has those words, if it has that smell, try to think of a better one and if you can not come up with a good one (that for sure will happen) then choose a meaningless name but please, not a bad name. I will explain the difference between them in another post, this one has became larger that I expected :-)

Hernan.

Deploying Ruby On Rails in a Windows environment can be very painful. I couldn't find any blog which really helped me, so I decided to summarize all the necessary steps I followed to successfully deploy a Rails application in a Windows 2008 server from scratch. I won't give much explanation on each step, so if you like to know more about it, at the end of this post you'll find a list of articles I found useful.

The environment:

• Windows 2008 SP2 x64
• SQL Server 2005
• IIS 7.0
• Ruby 1.8.7
• Ruby on Rails 2.3.5
• Mongrel 1.1.5

Steps:

1. Install Ruby VM
2. Install Rails
   gem install rails -v '= 2.3.5' --include-dependencies
3. Install any other dependencies your application requires
4. Install Sql Server adapter
   gem install activerecord-sqlserver-adapter --version 2.3.5
5. Install ruby-odbc
   
   1. Download ruby-odbc
   2. Copy the zip's content to ${RUBY_INSTALLATION_DIR}\lib\ruby\site_ruby\1.8\i386-msvcrt
6. Open the ODBC Data Source Administrator with the command
   C:\Windows>SysWOW64\odbcad32.exe
   (make sure you use this command instead of using the regular access from the control panel)
7. Create a System DSN using your specific database connection properties
8. Open the command prompt and go to the Rails application root folder
9. Create and initialize your database
   
   • rake db:create RAILS_ENV=production
   • rake db:migrate RAILS_ENV=production
   • rake db:seed RAILS_ENV=production
10. Install IIS Application Request Routing and URL Rewrite extensions
11. Edit the hosts file located at C:\Windows\System32\drivers\etc\hosts and add the following line
    127.0.0.1 localhost localhost-1 localhost-2
    (add as many localhost-x hostnames as mongrel services you're planning to setup)
12. Open IIS Manager and create a new farm. Add one server for each of the mongrel services you're planning to setup
    For each server use a different address (i.e. localhost-1, localhost-2, etc.) and a different port number (i.e. 3000, 3001, etc.)
13. Edit URL Rewrite rules and add the following rules
    
    1. Rule 1
       • Pattern: ^$
       • Action: Route to Server Farm
       • Path: /main/index
       • Check stop processing subsequent rules
    2. Rule 2
       • Pattern:^([^.]+)$
       • Action: Route to Server Farm
       • Path: /{R:1}
       • Do not check stop processing subsequent rules
14. In the IIS Manager create a new Web Site and in the Path box, type or browse to the directory that contains your Rails public folder.
15. Download this win32 services gem and install it.
16. Download this mongrel-service gem and install it.
17. Setup as many mongrel services as you need
    mongrel_rails service::install -N my-app-node-1 -e production -p 3000
    mongrel_rails service::install -N my-app-node-2 -e production -p 3001
    etc..
18. Launch the Window Services console from Control Panel. Change the startup type of your mongrel services to Automatic and start each of them.
19. Open a browser and test your application

Finally, some articles you might find useful:

• ODBC binding for Ruby
• Create a 32bit DSN on a 64bit operating system
• Ruby on Rails in IIS70 with url rewriter
• Define and configure an application request routing server farm
• Creating rewrite rules for the url rewrite module
• 10 steps to get Ruby on Rails running on Windows with IIS FastCGI

During the 70s, mutation testing emerged as a technique to assess the fault-finding effectiveness of a test suite. It works mutating objects behavior and looking for tests to “kill” those mutants. The surviving mutants are the starting point to write better tests. Thus, this technique is an interesting alternative to code coverage regarding test quality.

However, so far it is a “brute force” technique that takes too long to provide useful results. This characteristic has forbidden its widespread and practical use regardless new techniques, such as schema-based mutation and selective mutation. Additionally, there are no mutation testing tools (to our knowledge) that work on a meta-circular and dynamic environments, such as Smalltalk, so the compile and link time are the current technique's bottleneck.

This presentation will introduce the notion of mutation testing, analyzing its advantages and disadvantages with a Smalltalk-based tool. The tool uses the Smalltalk's dynamic and meta-programming facilities to notably reduce the time to get valuable output and help to understand and implement new tests due to its integration with the rest of the environment.

This presentation was presented at ESUG 2009. You can see the handouts here:

When talking about Smalltalk, there is definitively an over use on the possibility to add messages to Object class. It is so easy to do it, that people usually do it just to get something working fast, even if the coding is poor. There are a lot of messages (mainly #isXXX messages) that do not belong to Object and represent a bad design decision. Most of them are implemented there because they are "handy" and easily "reused". For example #-> or #assert: implemented in Squeak. Definitively not all objects should respond to them. Many of these messages are only used from "inside" the object, like the #assert: message.I would never write something like this: 1 assert: xxxx. Instead I would write: self assert: xxx witch clearly shows that #assert: is not a message that should be respond by every object, but only for those that represent assertions.

From my point of view, this issue is not an inheritance's problem per se, it is a miss-used of inheritance. If I try to use a hammer as a screwdriver, it is not the hammer's fault, but mine.
How is inheritance related with reuse? Well, that is an important question. Inheritance from the "pure theory" point of view, should not be use as a means of reuse. Reuse comes from good models, not from inheritance. Inheritance should be used as a tool to organize the knowledge that as a programmer, you are acquiring from the business domain. Classes should be use to represent the concepts and ideas you see in the business domain and inheritance should be used to organize how this concepts are related in an ontological way. So for example, an abstract class should represent an abstract concept wich defines the essential behavior that all the objects instances of its concrete subclasses should respond. Due to this relationship reuse comes aside, but reuse is not the means of inheritance. Subclassing just to reuse the implementation of a superclass is not a good design decision; it will bring problems sooner or later.

There has been an attempt to minimize the methods implemented in the Object class. For example on the Squeak distribution the class ProtoObject has been created. ProtoObject has only 35 methods whereas Object has 436! (on the basic image of Squeak version 3.10.x). Although ProtoObject has fewer methods, I do not agree with some of them. For example #ifNil: (and the like) and #tryNamedPrimitive: (and the like). Clearly these two messages (and their mutations) are implemented in ProtoObject as a means of reuse and not because every object should understand them. For example, why an account should respond #tryNamedPrimitive:? What does it mean to an account? A better design should have an object that represents the VM (for example) to which I can send the message #tryNamedPrimitive:. Of course the problem with this is how to access to this object and that is why that message is implemented in ProtoObject, because every object will inherit that method! And it will be so easy to use it as to write self tryNamedPrimitive: xxx. But thinking a little bit we can see that it is very easy to solve this problem. For example declaring this VM object in a global scope, so any object could send the message #tryNamedPrimitive: (and therefore reuse it), but not understand it. This brings me to the "rule" that says composition is a better tool to reuse.
The problem of using inheritance to reuse is that inheritance generates a strong coupling between the classes, its subclasses and its instances, where composition does not.

Inheritance generates an implementation and structural coupling between the classes and its subclasses (affecting directly their instances) where composition only couples an object with the composed one through the messages the former sends to the later. No implementation coupling, no structural coupling, just coupled by the message names one object send to the other, therefore a better design (the lower the coupling the better). This is the reason why good frameworks, black-box frameworks use composition over inheritance, where white-box frameworks being more immature, use inheritance to configure them.
This brings me to the idea of how hard should we stick to this, should we never "break" this rule? Well, I would not called it a rule but an heuristic, therefore it should be follow as much as possible, but we should also be pragmatic too. Sometimes subclassing to reuse while we are still learning about the problem is ok, is like making a white-box framework at the beginning. But we should never forget that our goal is a "black-box framework".
Other languages like Java do not suffer this problem and good designs can be implemented with it (although not so easily :-)). Java does not have this problem because Object class cannot be modified. This clearly shows that having too many methods in Object is not a problem of inheritance, but on how use it.

To summarize:

• Inheritance should not be used to reuse, therefore having a lot of methods in Object class just because it is "handy" is a clear example of inheritance being used incorrectly. It generates unnecessary coupling which will make the system harder to change or refactor later.
• Inheritance is just a tool; you can use it right or wrong.
• There are other tools like composition and design techniques which solve the same problems and generate less coupling.
• Reuse comes from good models, not from inheritance.