Skip to first unread message
Jop van Raaij
Jul 12, 2013, 6:31:50 AM7/12/13
to clean-code...@googlegroups.com
Hi Bob, thank you for the videos and comments on this forum. It provides me with answers and motivations to become a software craftsman!
I strongly try to follow the Boundary Interactor Model pattern combined with TDD. I have a question about the responsibility of the Model. The model should be independent of application logic (interactors) , so I've put them in a separate jar and include them in different projects (modules). The modules are used in multiple applications.
How do I contain logic strongly related to the model? In the model itself, in the interactor, or in some kind of (static?) utility class?
Example
Consider a Location class, containing the longitude and latitude. Some applications need the Spherical representation, some the mercator version, etc (why doesn't everyone use 1 representation?). This logic could be in the Location model class itself, or is a separate GeoLocationConverter class. The converter class will be some utility class used in about all projects.
Should I bundle the GeoLocationConverter class with the Location class in my Entities.jar? Or should the GeoLocationConverter be in a separate project (module), which can be used by other modules/applications?
I think the GeoLocationConverter can exist, when the situation of two applications needing a different representation rises. I should then refactor the logic from the Location class to the GeoLocationConverter class. But should I also introduce a complete new module/project? This seems to be a lot of overhead for adding one translation of coordinates.
Looking forward to your comments.
I strongly try to follow the Boundary Interactor Model pattern combined with TDD. I have a question about the responsibility of the Model. The model should be independent of application logic (interactors) , so I've put them in a separate jar and include them in different projects (modules). The modules are used in multiple applications.
How do I contain logic strongly related to the model? In the model itself, in the interactor, or in some kind of (static?) utility class?
Example
Consider a Location class, containing the longitude and latitude. Some applications need the Spherical representation, some the mercator version, etc (why doesn't everyone use 1 representation?). This logic could be in the Location model class itself, or is a separate GeoLocationConverter class. The converter class will be some utility class used in about all projects.
Should I bundle the GeoLocationConverter class with the Location class in my Entities.jar? Or should the GeoLocationConverter be in a separate project (module), which can be used by other modules/applications?
I think the GeoLocationConverter can exist, when the situation of two applications needing a different representation rises. I should then refactor the logic from the Location class to the GeoLocationConverter class. But should I also introduce a complete new module/project? This seems to be a lot of overhead for adding one translation of coordinates.
Looking forward to your comments.
Uncle Bob
Jul 12, 2013, 11:07:04 AM7/12/13
to clean-code...@googlegroups.com
I would not separate the GeoLocationConverter from the Location into separate components until some new application forced this upon me. I would, however, anticipate that this might happen, and keep the two relatively decoupled.
Some folks might complain that this is anticipatory design, and invoke the YAGNI principle. But there are times when the seam between to concepts is so obvious that it would be irresponsible not to do the minor work necessary to keep them decoupled.
Some folks might complain that this is anticipatory design, and invoke the YAGNI principle. But there are times when the seam between to concepts is so obvious that it would be irresponsible not to do the minor work necessary to keep them decoupled.
Reply all
Reply to author
Forward
0 new messages