Click here to Skip to main content
13,052,022 members (64,375 online)
Rate this:
Please Sign up or sign in to vote.
See more:
The question in general is:
Is it a right design to add functionality to primitive objects, so that the object can "take care of himself"

Recent example:
I have a singleton logMngr. The logMngr saves records of different types to different Azure Tables. records are received, queued as BaseRecord, and then saved to Db with different thread using threading.Timer. We have 2 ideas:

1.The BaseRecord has an abstract method"saveToDb", and each record knows how to save himself to Db(the table name, the keys...) save to Db needs to use DAL singleton to do that. Maybe it is not a good idea for primitive type to have such a complex functionality, But the code is very "object oriented"

2. use:

if (record is xRecord){logMngr.SavexRecordToDb}

, and then it is not an open - close code. We do not expect to have more record kinds.

Any insights? Maybe a better idea than both?

Thank you, Tal
Posted 5-May-13 19:53pm
Updated 5-May-13 20:13pm

1 solution

Rate this: bad
Please Sign up or sign in to vote.

Solution 1

It is always good to add methods to an object so that the object is cohesive and knows what to do with data provided to it.
For e.g. a save to database class could have add / delete and update methods implemented within the class.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web02 | 2.8.170713.1 | Last Updated 6 May 2013
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100