Change in constructor parameter or ways to decompose the constructor?

Question

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

Suppose my requirements change and now the creation of book also include the proceeding_date in the constructor parameters, after code is compiled I am 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, how I fit the OOAD principle in my design, did my class follow SRP, open/closed principle.

Suppose there is requirement to add more private variable in class will it break the open/closed principle? Is added new members [variables/methods] in a class breaks the OCP?

This answer should helop you https://softwareengineering.stackexchange.com/a/170568/61852 — Tulains Córdova, Jul 12 '17 at 08:29
Thanks for the replies, sorry it was " i m allowed to make changes"? it was mistyped. as of now i m targeting no programming lanaguage. — Narender Parmar, Jul 12 '17 at 09:25
"after code is compiled I am allowed to make changes in the class or there is a design flaw?" Why would you not be allowed to make changes? You're *always* allowed to make changes, as long as you can fix any problems that your changes create. — Tanner Swett, Jul 12 '17 at 13:33

score 2 · Accepted Answer · answered Jul 12 '17 at 07:58

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,

You always have to change your code to implement new requirements.

The open/closed principle aims to minimize the impact of this changes. But a single (DTO) class is the wrong place to talk about that.

However: One of the more important programming principles (not only in OOP) is You ain't gonna need it!. This means you should not introduce complexity or indirection just because you think it could be useful in future without having an actual need justified by you current requirements.

So back to your example this means you should not add "generic" properties to the class just because you might need some more in future. Add new properties as needed when requirements change.

answered Jul 12 '17 at 07:58

Timothy Truckle

2,336
9
12

1

DTOs are classes nonetheless. – Tulains Córdova Jul 12 '17 at 08:23
Cool !! Thanks for the reply. :) sorry for this silly question actually i m little confused with the OOP principles and how to implement the same in my design simultaneously. – Narender Parmar Jul 12 '17 at 09:29
@TulainsCórdova *"DTOs are classes nonetheless"* No doubt! But their design should rather follow principles of [Database normalization](https://en.wikipedia.org/wiki/Database_normalization) – Timothy Truckle Jul 12 '17 at 10:58
Could you please cite a reference that DTOs should be normalized? That sounds interesting but is new to me. For the record, the Book class could eventually be more than a DTO, it's hard to know from a simple example question. – user949300 Jul 12 '17 at 17:24
@user949300 *"Could you please cite a reference that DTOs should be normalized?"* That is my own reasoning. *"the Book class could eventually be more than a DTO, it's hard to know from a simple example question."* as shown in the example it is. I agree that it *could* develop to a "business class" in some uncertain future, but it *should* not (following the MVC pattern). – Timothy Truckle Jul 12 '17 at 17:43

score 0 · Answer 2 · answered Jul 12 '17 at 15:57

Depends on the language. If it is loosely typed and supports passing JSON-y stuctures (e.g. JavaScript) or key-value args (e.g. Python) they are a good way to pass additional or "optional" arguments.

In any language, especially a strongly typed language like Java, you can consider using a Fluent Builder Pattern. Your code would look something like

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

Note: that's a mishmash of a traditional constructor and a fluent builder, normally it would be all one or the other.

Book b1 = new BookBuilder()
  .date(1952)
  .session("abc")
  .volume(123)
  .proceedsDate(1951)
  .build();

This is actually the Builder Pattern? – Narender Parmar Jul 20 '17 at 09:48 — Narender Parmar, Jul 20 '17 at 09:48

Change in constructor parameter or ways to decompose the constructor?

2 Answers2