3 ms·
Most of the benefits of OO programming come from abstracting the machine / concerns (eg. MVC) rather than modeling the domain. (eg. Cars / Ducks / etc). I know
by fleitz 15y ago
Most of the benefits of OO programming come from abstracting the machine / concerns (eg. MVC) rather than modeling the domain. (eg. Cars / Ducks / etc).
I know it's just an example but it raises several important questions:
Why does the GameObject need to know how to render itself?
Why does the GameObject update the GameState which the GameObject is ostensibly also a part of?
Does updating the GameState directly affect the ability to separate concerns as to whether the GameState being modified is local vs. remote?
When you start modeling domains it leads very easily to situations where you have hardcoded permissions for the Manager class instead of bothering to implement a permissions system. Or you have a CEO class that's a singleton. (Hopefully, your code doesn't have to work at RIM)
The code savings from
class DeathStar2 : DeathStar {
public override FatalFlaw(){}
}
is going to pale in comparison to
class DeathStar2 : Object {
acts_as_travelling_salesman
has_many :laser_turrets, :max => 1024
has_many :tie_fighters, :max => 2048
}
when applied over many many systems and objects. Modeling domains is to modeling concerns as algebra is to calculus. Most things in life despite their appearances are not hierarchical and thus do not fit well when modelled explicitly using a class hierarchy. Showing people how to model a domain is easy but virtually useless, showing people how to model concerns is hard but is where the big payoffs are.
- jeffreymcmanus 15y agoCode savings isn't a reasonable goal of OOP. Information-hiding (in which you take an arbitrarily-complicated method and abstract it behind a class) is.
- fleitz 15y agoWhen you give people inheritance all they see is hierarchies and when you give them information hiding systems all they see is access control. One should not be able to find trade secrets by grepping for "private", nor reproduce a companies org chart by a class inheritance graph.
- wlievens 15y agoModeling a domain right is deceptively hard, and to me is one of the primary skills of our profession. Teaching what OO and inheritance mean is not the same thing as modeling a domain.
- equalarrow 15y agoThe 'CEO singleton' - very funny. :) However, I'm all for domain modeling in the beginning, for a beginner. I learned OO the hard way - all by myself and pouring over books. I agree with the OP that a vehicle or duck was not a good model. Having worked with databases and crm's in the past (before they were 'crm's), I always dealt with people, organizations, calls, notes, etc. So when I came across an infamous car example, I was always wondering 'this has no bearing on anything I would do - why not talk about real objects like people?'. Even before hitting any kind of patterns, it's crucial (in my mind) to understand datatypes, methods, scoping, inheritance, etc. 3 Simple classes like Person, Address, Organization can go a long way. In my mind, there's no way a beginner is going to understand patterns first. They have to be shown the basics and the have to be handheld when entering the OO way of thinking. One those first few steps are taken, then it paves the way for more complex examples and patterns.
- oconnor0 15y agoDo you have an example of modeling concerns vs. modeling domains?
- fleitz 15y agoLets say you're modeling a system with Customers and Salesmen both of which are Persons, should you put that travelling salesman algorithm into the Salesman class or the Person class? That's what I mean by modeling domains. By modeling concerns I mean that you should create a RouteFinder class and an adapter that extracts the coordinates from Salesman, Persons, and Customers. Maybe there is a convenience method on the Salesman class that makes it easy for him to travel to his customers but most of the work (the concern) is modelled separately from the domain. The primary concern of the program is routing, not Salesmen and Customers. It's like how rails/ASP.NET MVC/django concerns itself with making websites, not modeling domains. If you focus on the concerns the domain becomes an implementation detail. (eg. For the person class the coordinate can be found at Person.Address.Latitude)