

Accessors: There and Back Again - thangalin
http://blog.whitemagicsoftware.com/accessors-there-and-back-again/

======
jbandela
I disagree. I think the accessor solution is the better solution in your
example. You modification requires that File know about all extensions. It has
to know if something is an image, a document, a spreadsheet, etc. Every time
there is a change, it needs to be updated. Thus you will have File object that
is constantly updated. File version 2.2 won't process docx files (it thought
documents ended with .doc). Also you place on File the burden of
classification. is svg an image format or a text description.

Also with your classification of File.IMAGE, File.Document, can you really
generically process an image file. You might be able to, but it is hard.
Whereas if you had the extension, with .jpg or .jpeg you load up libjpeg, .png
you load of libpng, etc. With File.Document it is even worse. Can process
document really generically process without knowing the extension?

This is the reason I like accessors. Having them gives me flexibility in ways
the original designer may not have foreseen.

~~~
Jare
One thousand times this. The best way to design flexible and maintainable
systems is to encourage small and simple objects and functions that can be
asked to collaborate together via well defined interfaces. This collaboration
will always require some objects to provide information that other objects and
functions can use.

In addition, the fact that part of an object's interface is the same as its
implementation can mean that the implementation details are exposed (sounds
bad), or that the implementation closely matches the interface (sounds
efficient). Use your brain, not a canned rule, to decide which one of those is
happening in your code.

------
thangalin
This is my first technical blog post; I am looking forward to your comments.

