From: MikkelFJ Date: 2002-09-20T08:18:59+09:00 Subject: Re: MVC and OO Design? "MetalOne" wrote in message news:92c59a2c.0209161426.5a777753@posting.google.com... > 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