Comment by arthurcolle | Hacker News Reader

Comment by arthurcolle | Hacker News Reader

Parent Full thread

I don't really understand this approach. I don't think that even in my earliest days programming Java using object-oriented principles that I would have added "search" to a Product class. After all, search is not a behavior that products perform, rather it is a property of theirs... i.e. "I am searchable". I would have most likely make some kind of ProductIndex which consisted of a hashmap or something, mapping hashes of product strings to a list of their properties for easy lookup or something... This is one thing that immediately stands out to me.

Lo and behold, you created a ProductSearcher class. It seems to me that the initial approach stems not from the view that "objects are things" but rather the notion that any related property of an object should be included in the class definition of the object, which can be summed up as a misunderstanding of object-oriented programming more so than anything else, but maybe I'm looking at this the wrong way.

Interesting article, thanks for sharing.

In the past, when mentoring developers that tend towards god-objectery, they tended to avoid creating service objects because their mental map of the problem had a one-to-one correlation between "objects" and "the physical problem domain" (e.g., Users, Accounts, etc.)

Given how much I've seen this sort of stuff in the wild, I felt it would be a useful article to hand off to new-ish developers (I'm the author).

It sounds like you're well beyond that, though, but thanks for reading nonetheless!

In GRASP this is called "Pure Fabrication" - a thing that is not directly modeled in the problem domain. Initially, adding a search method to Product seemed sensible by using "Information Expert" (another GRASP term), but when proceeding on to adding suggestions and requiring the User object, it begins to violate "Low Coupling". You have to "fabricate" another object to avoid the God object.

http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

Sent this to a budding developer in our business. Thank you for the article. I too tend to think of objects as actors with contracts.

My pleasure -- I'm glad it helped!

I've noticed that Java's tedium with millions of little files creates an instinctive knee-jerk resistance to creating new classes in new developers. Alternately, newbie C++ developers who don't have a good toolset develop a similar fear of adding classes because of concerns they'll miss something in their delicate language.

Never, ever, ever be afraid to add a class. If you've chosen an OOP language, then you have to make classes, and make them willy-nilly. Always better to create a class and then consolidate its commonalities with another class into a common base than to try and shoehorn too much logic into a single class where all its uses are intertwingled together.

Reply on news.ycombinator.com