Ho erroneamente supposto che le mie routine siano accoppiate liberamente?

Question

Ho erroneamente supposto che le mie routine siano accoppiate liberamente?

#1 da (6 voti)
#2 da (0 voti)

6

Le mie strutture di test del selenio vanno come -

Classe oggetto dati -

public class RegistrationData {

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

  // Getter Setter Here 
}

Pagina Classe oggetto che esegue operazioni su una pagina Web -

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();
   }
}

E la classe di test li usa come -

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
   }
}

Da quando il metodo fillRegForm non accetta argomenti, posso supporre che si tratti di un esempio di accoppiamento lento nonostante sia necessario impostare RegistrationData in RegistrationPage prima di poter utilizzare il metodo fillRegForm.

object-oriented java coupling selenium

posta Tarun 11.09.2012 - 09:15

fonte

2 risposte

0

Risposta breve:

Le tre classi sono strongmente accoppiate.

fillRegForm non prendere argomenti è questione di coesione, non di accoppiamento lento.

risposta data 03.10.2012 - 15:42

fonte

Leggi altre domande sui tag object-oriented java coupling selenium

Come nominereste le funzioni di importazione ed esportazione in Java? [chiuso] Come funziona la cache nei servizi Web di ServiceStack

score 6 · Accepted Answer

Per quanto posso dire, il tuo esempio corrisponde strettamente all'accoppiamento strong, così come è definito 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...}

Diamo un'occhiata al codice dal punto di vista della definizione precedente:

controlla
^{la classe dipendente contiene un puntatore direttamente su una classe concreta che fornisce il comportamento richiesto}
Nell'esempio, la classe dipendente è RegistrationPage e il puntatore diretto a una classe concreta che contiene è RegistrationData regData .
La dipendenza check
^{non può essere sostituita, oppure la sua "firma" è cambiata, senza richiedere una modifica alla classe dipendente}
Nel tuo esempio, dovresti modificare RegistrationPage per utilizzare un'altra sorgente diversa da RegistrationData class per passare i dati a enterFirstName e altri metodi.

Nei termini profani, RegistrationPage "sa" parecchio su RegistrationData - sa che tale classe esiste e conosce membri essenziali di questa classe. Questo tipo di accoppiamento è tutt'altro che sciolto.

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

L'interfaccia di RegistrationData lo renderebbe liberamente accoppiato. Per quanto riguarda se ne hai bisogno o meno, dipende dal contesto e in gran parte, anche dalle tue preferenze personali / di squadra. Ad esempio come spiegato nella mia altra risposta , probabilmente proverei ad evitare di avere tale interfaccia se RegistrationData fosse una singola implementazione .

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

Questo significa che la tua domanda iniziale se si tratta di accoppiamento libero viene risolta correttamente? Per quanto riguarda la riprogettazione, sarebbe una domanda diversa , prendi in considerazione la possibilità di postarla separatamente.