Re: [Classpathx-discuss] Activation implementation

[Nic Ferrier]

> That is exactly my point.  There is an FSM directly in the class.  That is
a
> logical pattern that can easily be pulled out, especially due to it's size
> (sure it's not large, but it is significant).  The benefit of OOP is that
> every component has it's logical piece that are used to build larger
pieces.
> I'm a huge believer of small and simple encapsulations.  And also, by
pulling
> it out into a separate class, other projects could reuse it for processing
> mailcap's.
>
> I am working on finishing JAF and there is still pieces missing in the
> functionality which I'm addressing.  I was just checking if there was any
> major reasons for the FSM being in there.

Please don't remove it... if object design is your only reason for fiddling
with the code it's not reason enough.

I can counter your argument by saying that the parser is not generic but is
local to the type defined by the class (a mailcap type or mimetype type).
Since the files which represent these types are also local to the type the
code to parse them should sit within the class.

It's modular enough, clear enough and fast enough.

What reason, other than one view of design, is there for changing it?


Nic