Forum Stats

  • 3,827,853 Users
  • 2,260,832 Discussions
  • 7,897,398 Comments

Discussions

Constructor/ OOD Standard or Best Practice

sniperd
sniperd Member Posts: 6
edited Feb 11, 2016 5:22PM in New To Java

Making the move to Java and need some OOD feedback. Building a class that serializes data. Is it better to pass the data to the constructor that stores it in a private instance variable and then call a method that will serialize that data... or is it better to instantiate the object and then call the serialize method passing in the data as an arg to the method?

Best Answer

  • TPD-Opitz
    TPD-Opitz Member Posts: 2,465 Silver Trophy
    edited Feb 11, 2016 5:10PM Answer ✓

    At this point the better question was: what "JSON framework do you recommend".

    Especially when being new into (Java) programming its always a good idea to use some framework that already does what you need.

    Back to your question:

    In general you should not pass workload via constructor.

    rp0428 stated a constructor is responsible to configure an object so tat it is fully functional. The data to work on does not belong to such kind of precondition.

    Exception to this rule of thumb are DataTransferObjects (DTOs) or Wrappers for them which have no business logic, only accessors to the Data or parts of it. The advantage here was that you cold declare the member variables of the DTOs final which would turn them into "immutables".  And that will give your application a push towards thread safety...

    Back to your use case: The Objects doing the actual translation from/to JSON should not get "Data" via constructor.

    But those converters  may work on DTOs which could/should get their data via constructor.

    bye

    TPD

Answers

  • TPD-Opitz
    TPD-Opitz Member Posts: 2,465 Silver Trophy
    edited Feb 8, 2016 4:37PM

    Serialisation has nothing to do with OOD/OOP.

    And how or when to use parametrized constructors is not covered by OOD (where D stands for Design).

    From the OOP (with P like Programming) perspective: what you describe is one form of dependency injection which is in fact a good OOP practice.

    On the other hand some serialisation frameworks for java (which usually convert java object trees into some arbitrary file format) require the java classes to have a public default constructor (without parameters) and setters for their properties.

    bye

    TPD

  • Unknown
    edited Feb 8, 2016 5:03PM
    Making the move to Java and need some OOD feedback.
    

    Ok - does that mean you were NOT using OOD before the move? Because if you were then Java isn't really the issue.

    Building a class that serializes data.
    

    What data? What form is the data in now? What form will it be after you serialize it?

    Show us an example of the before and after.

    Is it better to pass the data to the constructor that stores it in a private instance variable and then call a method that will serialize that data... or is it better to instantiate the object and then call the serialize method passing in the data as an arg to the method? 
    
    

    Usually neither - you would typically pass a pointer (to the data) to a method and that method would serialize it. The method might be either a class or instance method depending on the use case.

    Why would you pass it to a constructor? A constructor is to, well, construct an instance of an object.

    Your questions are confusing because you haven't told us WHAT PROBLEM you are trying to solve.

    You already have access to the data so storing it anywhere else just wastes time and resources since all you have then is a second copy.

    Also if the data is in a form that you can 'store it in a private instance variable' then it must already be encapsulated in some fashion. If that encapsulation is an Object instance then why not just add a serialization method to that Object class?

    Otherwise I don't see a need to 'instantiate the object'. What is there about your use case that requires anything other than a static method? Give it a source - it produces a serialized version.

  • sniperd
    sniperd Member Posts: 6
    edited Feb 11, 2016 11:27AM

    rp0428, sorry about that. In trying to be concise I rather probably made this too open ended. I was trying to not be like these posts I see that are novellas about their project with 5MB of log or stack dumps.  And thank you for not waxing vain over semantics. So....

    We are tasked with creating a web forms processing system, (Info Sec driven) for lack of a better explanation. So there is one standard system for accepting form posts, inspecting the content and file types for anything malicious, PHI, PII, etc then parsing into tables with an administration system for the recipients to access the data. At this point, the concept is that there will be a service that will receive the form data, but this data must come in JSON. The form developers will be responsible for client and server side validation, but then must serialize their form data into JSON, so though once concept was to have the service deal with the serialization upon receipt, the other is that there would be a class for serialization the developers could use. Which comes back full circle to my original question, what is the better way to design/implement that class. The developer, at the end of validating/santizing their form data will just have form data structured as a hashmap.

    I hope that helped clear things up.

  • TPD-Opitz
    TPD-Opitz Member Posts: 2,465 Silver Trophy
    edited Feb 11, 2016 5:10PM Answer ✓

    At this point the better question was: what "JSON framework do you recommend".

    Especially when being new into (Java) programming its always a good idea to use some framework that already does what you need.

    Back to your question:

    In general you should not pass workload via constructor.

    rp0428 stated a constructor is responsible to configure an object so tat it is fully functional. The data to work on does not belong to such kind of precondition.

    Exception to this rule of thumb are DataTransferObjects (DTOs) or Wrappers for them which have no business logic, only accessors to the Data or parts of it. The advantage here was that you cold declare the member variables of the DTOs final which would turn them into "immutables".  And that will give your application a push towards thread safety...

    Back to your use case: The Objects doing the actual translation from/to JSON should not get "Data" via constructor.

    But those converters  may work on DTOs which could/should get their data via constructor.

    bye

    TPD

  • sniperd
    sniperd Member Posts: 6
    edited Feb 11, 2016 5:22PM

    Great breakdown and recommendations. Thank you.

This discussion has been closed.