CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 20: Line 20:
  interface IWorker extends Feedable, Workable {
  interface IWorker extends Feedable, Workable {
  }
  }
  interface IWorkable {
  interface IWorkable {
public void work();
public void work();

Revision as of 20:07, 17 November 2009

Interface Segregation Principle vs. Principle of Small Interfaces


Introduction

This page tries to review Integrated Development Environments for Ruby such as Aptana,Rubymine and Netbeans. Also the IDEs are compared with respect to certain dimensions such as facilities, ease of use, system requirements, and support for the Ruby way of thinking.

Interface Segregation Principle

  • “Many client specific interfaces are better than one general purpose interface“
  • “The dependency of one class to another one should depend on the smallest possible interface“
  • “Make fine grained interfaces that are client specific.“
  • “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of the Interface-Segregation Principle. Consider a User interface for ATM machine, where it may logically stand to reason you may have separate interfaces for a person conducting a 1) Deposit Transaction, 2) Withdrawal Transaction, and 3) Transfer Transaction. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

Clients Should not be forced to use Interface they don't use

To explain this consider the following Java Code

interface IWorker extends Feedable, Workable {
}
interface IWorkable {

public void work();

}
interface IFeedable{

public void eat();

}
class Worker implements IWorkable, IFeedable{

public void work() { // ....working }

public void eat() { //.... eating in launch break }

}
class Robot implements IWorkable{

public void work() { // ....working }

}
class SuperWorker implements IWorkable, IFeedable{

public void work() { //.... working much more }

public void eat() { //.... eating in launch break }

}
class Manager {

Workable worker;

public void setWorker(Workable w) { worker=w; }

public void manage() { worker.work(); }

}

Comparision of Aptana,Netbeans and Rubymine

Three IDEs namely Aptana's Radrails, Netbeans and Rubymine are compared in the following sections.

System Requirements

Features for Ruby

Other Features available in IDE's

Conclusion

References