Re: MVC and OO Design?

"MetalOne" <[e-mail]> wrote in message
news:[e-mail]...
> Thanks to all for your help.
>
> I was really thinking very abstractly about a problem in my head that
> MVC kind of demonstrated.  I was in search of deep answers in regards
> to when to include a function in a class and when not too.  The common

Initially I found the tricky part to decide between inhertance and
aggregation, leaning towards aggregation.
That was C++, now single inheritance languages like Java and Ruby makes this
choice easier as you often have to go with aggregration. Aggregation leads
to more effort in mirroring aggregated functionality to the aggregating
class. How to avoid this? Use Ruby Mix'ins.

I'm no longer so interested in OO design - either it is obvious and you
just do it - or the interaction becomes too complicated and it is better
abstract out in components. Too complex object interaction isn't good. The
difference between components and objects are not clear, but generally
components are more loosely coupled. Like require a ruby package that
internally has more objects than you care about.

Hence my focus is on component interfaces. Dealing with  published
functionality, lifetime management across interfaces, handling of
identifiers across interfaces. These are challenging issues. (And the fact
that Ruby makes this comparitively easy is a significant part of Ruby's
power - take distributed Ruby as an example and compare the effort going
into DCOM/Corba).

Most benefit I've seen in Ruby has actually little to do with classes and
more its functional nature. The essential problem with pure functional style
is that it is difficult to subsequently add an extra piece of information to
the set of interacting functions. Objects become a good way to contain a
concept. Like a coordinate object that later needs precision added.

In the end it is a question of - how can I easily access data without
becoming too dependent on changes in implementation. Some solves this by
brain-dead refactoring. Refactoring is a good tool, but not a design tool.

You control this complexity be choosing a component interface abstraction.
Then I'm less concerned with what is behind the component interface because
it is not more complex than what refactoring allows and the OO design
choices essentially becomes - how can I most easily do this job.

> wisdom states that when a function needs access to the classes data,
> it should be included with the class.  MVC strays from this notion
> because the View needs access to the Models data and yet the View
> functions are not placed in the class.

Unless you are hooking into a framework or building one, you don't (IMO)
need to think too hard about the separation between model view and
controller - instead it is better to study the actual flow of information
and build objects that most easily represent this. You won't add a new
totally indendependt view type later on that just plugs in neatly - it
doesn't happen that way. But if you have a clean structure that does not
work against your information flow, it should be easy to extend whether it
conforms to a specific concept such as MVC or not. Perhaps this pragmatism
only comes with experience and as such it may be good to follow a guideline.

> classes, containing only functions that modify state.  Writing all the
> accessors seemed awkward though.  I suppose as always there are no
> hard fast rules and comprises are required.

Certainly. I'm really don't like looking at pages and pages of Java code
doing nothing but setting and getting data - it's good to protect you data
access, but you could have done it at a larger granularity.
I've seen some horribly bloated code where you can search the source for
hours without being able to locate where exactly the logic is happening
because everything is about data hiding and making baseclasses for
everything as if you would ever implement those ten different versions of
the same thing. (I've to some extend done so myself - I'm just bailing out
now).

There is no rulebook - the objective is clean, understandable and
maintainable code that can also be implemented in reasonable time.

> Perhaps it is wise to pull functions out of a class along functional
> lines that require specialized developer skills such as GUI, Database
> Access, Encryption, etc.

That's what you could call component interfaces, and I agree - except it has
nothing to do with developer skills but with functionality. About seperating
out things that can be separated in order to decrease complexity.

> Or maybe it only makes sense for GUI,
> because, of the need to easily change the GUI.

A (G)UI is rather much a consumer of other entities as those you mention
above. I.e. A GUI is on "the other side" of the interfaces and orchestrates
what should happen when, whereas the component interfaces should just
deliver (that does not prevent a push model, but still someone decides when
to request for having data pushed).

Mikkel