Skip to main content
replaced http://stackoverflow.com/ with https://stackoverflow.com/
Source Link

This seems to me to break the principle of encapsulation - I have to expose a lot of the internal data on my class just to provide a representation for it.

Not really. In one approach, you expose data and structure through 100 getters, in the other, you expose essentially the same data and structure through an XML with 100 tags. From the viewpoint of dependencies and encapsulation, there is no (!) difference between these two solutions.

Moreover, you should consider not to implement this "manually". There are some reflection based libraries (like XStream) which can do an Xml serialization / deserialization for you (some more are mentioned in this former SO postin this former SO post). They work fine with private attributes, so no need to write any additional getters and setters. Using such a library will allow you to stick to the SRP - your object will not know anything about the serialization format.

If you really cannot use one of those "out of the box" XML serializers, you may consider to implement this based on reflection by yourself. That will surely safe you from writing the same kind of boilerplate code again and again.

If you do not want to use reflection and go the route of writing similar code for each individual attribute, consider to provide a method asMap in your class MyObject which delivers you a more or less "format neutral" representation of your object like a Map<String,String> (with the field names or tag names as keys). Your XmlBuilder then can take this as input and reformat the map into the final xml format.

This seems to me to break the principle of encapsulation - I have to expose a lot of the internal data on my class just to provide a representation for it.

Not really. In one approach, you expose data and structure through 100 getters, in the other, you expose essentially the same data and structure through an XML with 100 tags. From the viewpoint of dependencies and encapsulation, there is no (!) difference between these two solutions.

Moreover, you should consider not to implement this "manually". There are some reflection based libraries (like XStream) which can do an Xml serialization / deserialization for you (some more are mentioned in this former SO post). They work fine with private attributes, so no need to write any additional getters and setters. Using such a library will allow you to stick to the SRP - your object will not know anything about the serialization format.

If you really cannot use one of those "out of the box" XML serializers, you may consider to implement this based on reflection by yourself. That will surely safe you from writing the same kind of boilerplate code again and again.

If you do not want to use reflection and go the route of writing similar code for each individual attribute, consider to provide a method asMap in your class MyObject which delivers you a more or less "format neutral" representation of your object like a Map<String,String> (with the field names or tag names as keys). Your XmlBuilder then can take this as input and reformat the map into the final xml format.

This seems to me to break the principle of encapsulation - I have to expose a lot of the internal data on my class just to provide a representation for it.

Not really. In one approach, you expose data and structure through 100 getters, in the other, you expose essentially the same data and structure through an XML with 100 tags. From the viewpoint of dependencies and encapsulation, there is no (!) difference between these two solutions.

Moreover, you should consider not to implement this "manually". There are some reflection based libraries (like XStream) which can do an Xml serialization / deserialization for you (some more are mentioned in this former SO post). They work fine with private attributes, so no need to write any additional getters and setters. Using such a library will allow you to stick to the SRP - your object will not know anything about the serialization format.

If you really cannot use one of those "out of the box" XML serializers, you may consider to implement this based on reflection by yourself. That will surely safe you from writing the same kind of boilerplate code again and again.

If you do not want to use reflection and go the route of writing similar code for each individual attribute, consider to provide a method asMap in your class MyObject which delivers you a more or less "format neutral" representation of your object like a Map<String,String> (with the field names or tag names as keys). Your XmlBuilder then can take this as input and reformat the map into the final xml format.

added 198 characters in body
Source Link
Doc Brown
  • 220.5k
  • 35
  • 410
  • 625

This seems to me to break the principle of encapsulation - I have to expose a lot of the internal data on my class just to provide a representation for it.

Not really. In one approach, you expose data and structure through 100 getters, in the other, you expose essentially the same data and structure through an XML with 100 tags. From the viewpoint of dependencies and encapsulation, there is no (!) difference between these two solutions.

Moreover, you should consider not to implement this "manually". There are some reflection based libraries (like XStream) which can do an Xml serialization / deserialization for you (some more are mentioned in this former SO post). They work fine with private attributes, so no need to write any additional getters and setters. Using such a library will allow you to stick to the SRP - your object will not know anything about the serialization format.

If you really cannot use one of those "out of the box" XML serializers, and you think you needmay consider to implement this based on reflection by yourself without using. That will surely safe you from writing the same kind of boilerplate code again and again.

If you do not want to use reflection and go the route of writing similar code for each individual attribute, consider to provide a method asMap in your class MyObject which delivers you a more or less "format neutral" representation of your object like a Map<String,String> (with the field names or tag names as keys). Your XmlBuilder then can take this as input and reformat the map into the final xml format.

This seems to me to break the principle of encapsulation - I have to expose a lot of the internal data on my class just to provide a representation for it.

Not really. In one approach, you expose data and structure through 100 getters, in the other, you expose essentially the same data and structure through an XML with 100 tags. From the viewpoint of dependencies and encapsulation, there is no (!) difference between these two solutions.

Moreover, you should consider not to implement this "manually". There are some reflection based libraries (like XStream) which can do an Xml serialization / deserialization for you (some more are mentioned in this former SO post). They work fine with private attributes, so no need to write any additional getters and setters. Using such a library will allow you to stick to the SRP - your object will not know anything about the serialization format.

If you really cannot use one of those "out of the box" XML serializers, and you think you need to implement by yourself without using reflection, consider to provide a method asMap in your class MyObject which delivers you a more or less "format neutral" representation of your object like a Map<String,String> (with the field names or tag names as keys). Your XmlBuilder then can take this as input and reformat the map into the final xml format.

This seems to me to break the principle of encapsulation - I have to expose a lot of the internal data on my class just to provide a representation for it.

Not really. In one approach, you expose data and structure through 100 getters, in the other, you expose essentially the same data and structure through an XML with 100 tags. From the viewpoint of dependencies and encapsulation, there is no (!) difference between these two solutions.

Moreover, you should consider not to implement this "manually". There are some reflection based libraries (like XStream) which can do an Xml serialization / deserialization for you (some more are mentioned in this former SO post). They work fine with private attributes, so no need to write any additional getters and setters. Using such a library will allow you to stick to the SRP - your object will not know anything about the serialization format.

If you really cannot use one of those "out of the box" XML serializers, you may consider to implement this based on reflection by yourself. That will surely safe you from writing the same kind of boilerplate code again and again.

If you do not want to use reflection and go the route of writing similar code for each individual attribute, consider to provide a method asMap in your class MyObject which delivers you a more or less "format neutral" representation of your object like a Map<String,String> (with the field names or tag names as keys). Your XmlBuilder then can take this as input and reformat the map into the final xml format.

deleted 12 characters in body
Source Link
Doc Brown
  • 220.5k
  • 35
  • 410
  • 625

This seems to me to break the principle of encapsulation - I have to expose a lot of the internal data on my class just to provide a representation for it.

Not really. WhateverIn one approach you choose, you are exposing the XML data and its structureexpose data and structure through 100 getters, in publicthe other, so even if you do not write any getters, changingexpose essentially the fieldssame data and their structure will not be easy at a later point in timethrough an XML with 100 tags. From the viewpoint of dependencies and encapsulation, there is no (!) difference between these two solutions.

Moreover, you should consider not to implement this "manually". There are some reflection based libraries (like XStream) which can do an Xml serialization / deserialization for you (some more are mentioned in this former SO post). They work fine with private attributes, so no need to write any additional getters and setters. Using such a library will allow you to stick to the SRP - your object will not know anything about the serialization format.

If you really cannot use one of those "out of the box" XML serializers, and you think you need to implement by yourself without using reflection, consider to provide a method asMap in your class MyObject which delivers you a more or less "format neutral" representation of your object like a Map<String,String> (with the field names or tag names as keys). Your XmlBuilder then can take this as input and reformat the map into the final xml format.

This seems to me to break the principle of encapsulation - I have to expose a lot of the internal data on my class just to provide a representation for it.

Not really. Whatever approach you choose, you are exposing the XML data and its structure in public, so even if you do not write any getters, changing the fields and their structure will not be easy at a later point in time.

Moreover, you should consider not to implement this "manually". There are some reflection based libraries (like XStream) which can do an Xml serialization / deserialization for you (some more are mentioned in this former SO post). They work fine with private attributes, so no need to write any additional getters and setters. Using such a library will allow you to stick to the SRP - your object will not know anything about the serialization format.

If you really cannot use one of those "out of the box" XML serializers, and you think you need to implement by yourself without using reflection, consider to provide a method asMap in your class MyObject which delivers you a more or less "format neutral" representation of your object like a Map<String,String> (with the field names or tag names as keys). Your XmlBuilder then can take this as input and reformat the map into the final xml format.

This seems to me to break the principle of encapsulation - I have to expose a lot of the internal data on my class just to provide a representation for it.

Not really. In one approach, you expose data and structure through 100 getters, in the other, you expose essentially the same data and structure through an XML with 100 tags. From the viewpoint of dependencies and encapsulation, there is no (!) difference between these two solutions.

Moreover, you should consider not to implement this "manually". There are some reflection based libraries (like XStream) which can do an Xml serialization / deserialization for you (some more are mentioned in this former SO post). They work fine with private attributes, so no need to write any additional getters and setters. Using such a library will allow you to stick to the SRP - your object will not know anything about the serialization format.

If you really cannot use one of those "out of the box" XML serializers, and you think you need to implement by yourself without using reflection, consider to provide a method asMap in your class MyObject which delivers you a more or less "format neutral" representation of your object like a Map<String,String> (with the field names or tag names as keys). Your XmlBuilder then can take this as input and reformat the map into the final xml format.

deleted 12 characters in body
Source Link
Doc Brown
  • 220.5k
  • 35
  • 410
  • 625
Loading
added 713 characters in body
Source Link
Doc Brown
  • 220.5k
  • 35
  • 410
  • 625
Loading
Source Link
Doc Brown
  • 220.5k
  • 35
  • 410
  • 625
Loading