Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My Selenium test structures goes as -

Data Object class -

public class RegistrationData {

  String firstName = "test first name";
  String lastName = "test last name";

  // Getter Setter Here 
}

Page Object class which carries out operations on a Web Page -

public class RegistrationPage {
   private RegistrationData regData;

   public void setRegistrationData(RegistrationData regData) {
   this.regData = regData();    

   public NewAccountPage fillRegForm() {
     enterFirstName("FirstNameTextBoxLocator", regData.getFirstName);
     enterLastName("LastNameTextBoxLocator", regData.getLastName);
     // Some more fields are filled here
     return NewAccountPage();
   }
}

And test class uses them as -

public class TestRegistration extends SelTestCase {

   @Test
   public void testRegNewUser() {
     RegistrationData regData = new RegistrationData();
     RegistrationPage regPage = New RegistrationPage();
     regPage.setRegistrationData(regData)
     regPage.fillRegForm();
     // Some assertion here
   }
}

Now since fillRegForm method does not take any argument, Can I assume that it is an example of loose coupling despite I need to set RegistrationData in RegistrationPage before being able to use fillRegForm method.

share|improve this question

2 Answers 2

up vote 6 down vote accepted

As far as I can tell, your example closely matches the strong coupling, as it is defined in Wikipedia:

Strong coupling occurs when a dependent class contains a pointer directly to a concrete class which provides the required behavior. The dependency cannot be substituted, or its "signature" changed, without requiring a change to the dependent class. Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes. The dependent class's dependency is to a "contract" specified by the interface; a defined list of methods and/or properties that implementing classes must provide. Any class that implements the interface can thus satisfy the dependency of a dependent class without having to change the class. This allows for extensibility in software design; a new class implementing an interface can be written to replace a current dependency in some or all situations, without requiring a change to the dependent class; the new and old classes can be interchanged freely. Strong coupling does not allow this...

Let's look at the code from the perspective of above definition:

  • check
    dependent class contains a pointer directly to a concrete class which provides the required behavior
    In your example, dependent class is RegistrationPage and direct pointer to a concrete class it contains is RegistrationData regData.
  • check
    dependency cannot be substituted, or its "signature" changed, without requiring a change to the dependent class
    In your example, one would have to change RegistrationPage in order to use some other source than RegistrationData class to pass the data to enterFirstName and other methods.

In layman terms, RegistrationPage "knows" quite a lot about RegistrationData - it knows that such a class exists and it knows essential members of this class. This kind coupling is anything but loose.


I assume that I need interface of RegistrationData class to be used in RegistrationPage class. Is not it?

Interface of RegistrationData would make it loosely coupled. As for whether you need it or not, it depends on the context and largely, also on your personal / team preferences. For example as explained in my other answer, I would likely try to avoid having such interface if RegistrationData was a single implementation.

I am indeed asking suggestion for redesign now and please let me know if I need to add more details to question.

This means your original question whether it's loose coupling is solved right? As for redesign, that would be a different question, consider posting it separately.

share|improve this answer
    
@ShivanDragon well labeling does not mean need to change. To me this case is one that is clearly strongly coupled (that's the only point I made in the answer) but without knowing more details I am not going to suggest redesigning it. In my own practice, I use coding to interfaces very judiciously –  gnat Sep 11 '12 at 14:16
    
So my assumption was right :) I see your comment about coding to interface and I assume (again assuming :-/) that I need interface of RegistrationData class to be used in RegistrationPage class. Is not it? I am indeed asking suggestion for redesign now and please let me know if I need to add more details to question. –  Tarun Sep 11 '12 at 17:00
    
@Tarun I updated the answer to clarify that –  gnat Sep 12 '12 at 6:24

Short answer:

The three classes are strongly coupled.

fillRegForm not taking any argument is a matter of cohesion, not loose coupling.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.