CODEWITHSUNDEEP
javaoopdesign-patterns
James P.
James P.

Reputation: 19617

Resolving processes: keeping classes/instances separate or having them chained?

Say I have a process which reads an image file and then allows to zoom in and out using a resizing algorithm. This could be decomposed into classes as follows:

ImageFileReader
ImageFileFormatIdentifier
ImageFileValidator
ImageFileHeaderParser
ImageZoomer
ImageResizer

What is the most appropriate way to combine these classes ?

Should they be "loose" such that a programmer could compose them as he sees fit in his code ?

Or should they be designed in such a way that one object has a reference or interface to another class that it's dependant on ?

Additionaly, with a layered architecture it seems that with a Service layer the first approach tends to be priviledged, with methods being used for composition. Is this a kind of pattern ?

Upvotes: 2

Views: 36

Answers (1)

Chris Cooper
Chris Cooper

Reputation: 5122

I would suggest that the reader and validator are closely coupled, since when you read, you want to confirm the content is valid. (This applied before your edits!)

If the zoom and resize are going to be use arbitrarily, then I would suggest that you have an overarching controller and the images are passed to zoom/resize with the modification parameters and the result is passed back to the controller.

This is use of the Facade pattern, when multiple services (Reader/Identifier/Validator/etc) appear to be one service that provides simplified functionality (Load/Zoom/Resize/Save/etc.) by coordinating the behaviour of the other components.

Further by considering Inversion of Control as a pattern you could plug in further behaviours at a alter time. You define the interface for image loaders, validators and savers for example, then you can add support ofr other image types at a alter time.

Upvotes: 1

Related Questions