Modifica nel parametro del costruttore o modi per decomporre il costruttore? [duplicare]

-2
Class Book
{
  private int year;
  private String session;
  private int volume;
  private int number;
  private String khand;
  private Date proceeding_date;
  private int pageNo;
  Book(year,session,volume)
  {
    $this.year=year;
    $this.session=session;
    $this.volume=volume;
  }
 public getBookName()
 {
   return (year+session+volume)  //concatenation of three
 }   
}

Book b1=new Book(1952,abc,123);

Supponiamo che i miei requisiti cambino e che ora la creazione del libro includa anche proceeding_date nei parametri del costruttore, dopo che il codice è stato compilato, posso apportare modifiche alla classe o c'è un difetto di progettazione?

La classe dovrebbe essere progettata in modo tale che accetti qualsiasi cambiamento in futuro, come ho adattato il principio OOAD alla mia progettazione, la mia classe ha seguito SRP, principio aperto / chiuso.

Supponiamo che sia necessario aggiungere più variabili private in classe per rompere il principio aperto / chiuso? Vengono aggiunti nuovi membri [variabili / metodi] in una classe si interrompe l'OCP?

    
posta Narender Parmar 12.07.2017 - 09:16
fonte

2 risposte

2

suppose my requirement change and now the creation of book also include the proceeding_date in the constructor paramters, after code is compiled di i m allowed to make changes in the class or there is a design flaw, the class should be designed so that it will accept any changes in future,

Devi sempre modificare il codice per implementare nuovi requisiti.

Il principio aperto / chiuso mira a minimizzare l'impatto di questi cambiamenti. Ma una singola classe (DTO) è il posto sbagliato per parlarne.

Tuttavia: uno dei principi di programmazione più importanti (non solo in OOP) è Non ne avrai bisogno! . Ciò significa che non dovresti introdurre complessità o indirezione solo perché pensi potrebbe essere utile in futuro senza avere un bisogno effettivo giustificato dai requisiti correnti .

Quindi, tornando al tuo esempio, questo significa che non devi aggiungere proprietà "generiche" alla classe solo perché potresti averne bisogno in futuro. Aggiungi nuove proprietà quando necessario quando cambiano i requisiti.

    
risposta data 12.07.2017 - 09:58
fonte
0

Dipende dalla lingua. Se è tipicamente digitato e supporta il passaggio di strutture JSON-y (ad esempio JavaScript) o argomenti con valori-chiave (es. Python) sono un buon modo per passare argomenti aggiuntivi o "opzionali".

In qualsiasi lingua, specialmente in un linguaggio strongmente tipizzato come Java, puoi prendere in considerazione l'utilizzo di un Fluent Builder Pattern . Il tuo codice sarà simile a

Book b1=new Book(1952,abc,123).proceedingDate(1957)

Nota: è un miscuglio di un costruttore tradizionale e un costruttore fluente, normalmente sarebbe tutto l'uno o l'altro.

Book b1 = new BookBuilder()
  .date(1952)
  .session("abc")
  .volume(123)
  .proceedsDate(1951)
  .build();
    
risposta data 12.07.2017 - 17:57
fonte