How to decide when to abstract common properties?

Question

Imagine we have two types of requests, an InvoiceRequest and a QuoteRequest. How would you prefer the object model (classes) be and the database model ? Which one of the following two make more sense ?

InvoiceRequest: 
 - id
 - amount
 - discount
 - date
 - invoiceSpecificFieldHere

QuoteRequest:
 - id
 - amount
 - discount
 - date
 - quoteSpecificFieldHere. 

Or does this one make more sense?

RequestData:
 - amount
 - discount
 - date

InvoiceRequest: 
 - id
 - requestData: <RequestData>
 - invoiceSpecificProperty

QuoteRequest:
 - id
 - requestData: <RequestData>
 - quoteSpecificProperty. 

I'm not representing a third option using inheritance in purpose.

The question behind this question, is the following; if we go with design 2, we reduce redundancy, however there is something about it that doesn't feel right. I think discount should be at the same level as quoteSpecificProperty. And putting it inside the requestData object doesn't model this correctly.

Answer 1

My impression is that you are mixing concepts from object-oriented modeling and relational data modeling. This is since your second solution is not correct from a relational data modeling point of view.

Since I do not know your exact needs in term of implementation of the model, I'll try to propose a solution for different situations.

If you want to use a pure Object-Oriented Model, implemented with an object-oriented language, you should obviously define a superclass Request, with two subclasses InvoiceRequest and QuoteRequest, both of them with the specific properties.

If you want to implement your situation in a pure relational model, with a relational database, you should define three tables:

Requests:
 - id (Primary Key)
 - amount
 - discount
 - date

InvoiceRequests: 
 - id (Primary Key) (Foreign Key for Requests)
 - invoiceSpecificProperty

QuoteRequests:
 - id (Primary Key) (Foreign Key for Requests)
 - quoteSpecificProperty. 

Finally, if you want to use an Object-Relational Mapping, you should design a superclass Request, with two subclasses InvoiceRequest and QuoteRequest, both of them with the specific properties, and then you can map it onto a relational database with a model like the previous one.

Of course there is another possibility in the relational modeling, i.e. to have a single table Requests, with all the attributes, includind quote specific and invoice specific, as well as an attribute to distinguish which kind of request is the current one.

Answer 2

The second one has a lot more sense, because when you design your objects, and the fields they have, you are making and abstraction of the real word, and how it see and what behavior has in it. You are dealing here with something called normalization,

Database Normalization, or simply normalization, is the process of organizing the columns (attributes) and tables (relations) of a relational database to reduce data redundancy and improve data integrity. That relationship not always match perfectly with the reality in the world, but you must abstract from the real word and to treat the data as it is related to each other.

Answer 3

I will share with you some information I collected this week.

Maybe the SOLID principles would help you to decide that.

SOLID =(Single responsibility principle,Open/closed principle,
Liskov substitution principle,Interface segregation principle,
Dependency inversion principle or Dependency injection principle.

Alright, that's much more than property abstraction. Let see Some examples:

S

According Wikipedia, Single responsibility principle means

• One class shall have only one reason that justifies changing its implementation;
• Classes shall have few dependencies on other classes;
• Classes shall be abstract from the particular layer they are running.

O

When you define a class or a unit, keep in mind:

They shall be open for extension;
But closed for modification.

About modification, think that, in bug situation, which you are obligated to do that, a modification in second model is most easy for common fields.

First model

InvoiceRequest: 
 - id
 - amount
 - discount
 - date
 - invoiceSpecificFieldHere
QuoteRequest:
 - id
 - amount
 - discount
 - date
 - quoteSpecificFieldHere.

Second model-Common fields

 QuoteRequest:
     - id
     - requestData: <RequestData>
     - quoteSpecificProperty.  

L

According "Barbara Liskovs substitution principle" , if TChild is a subtype of TParent, then objects of type TParent may be replaced with objects of type TChild without altering any of the desirable properties of that program (correctness, task performed, etc.). I mean, the objects of TParent, the instances of TParent, not the TParent classes properly.

That is an interesting topic to think when you want to implement this example using Interface. Also follow:

I

Interface segregation principle

D

Dependency Inversion Principle Another form of decoupling is to invert the dependency between high and low level of a software design: - High-level modules should not depend on low-level modules. Both should depend on abstractions; - Abstractions should not depend upon details. Details should depend upon abstractions.

To know more about SOLID principle, read http://blog.synopse.info/post/2011/11/27/SOLID-design-principles

In resume, observe three characteristics of an object model:

• Rigidity – Hard to change something because every change affects too many other parts of the system;
• Fragility – When you make a change, unexpected parts of the system break;
• Immobility – Hard to reuse in another application because it cannot be disentangled from the current application.

Special thanks for A.Bouchez, source http://blog.synopse.info/post/2011/11/27/SOLID-design-principles

Answer 4

Invoice and quote are two completelly different things even they look similar. It's better to keep them separated because changes to one might produce unwanted side effects to the other.