Christ Centered Gamer

So jumping back to OO design principles, how do you define "one" thing?

For instance, if I'm attempting to use a database via JDBC (because this was before I learned of ORM), does one thing mean an object that performs CRUD on the database (it only handles queries against that one database, basically), or does one thing mean a separate object for Creation, Read, Update, and Deletion? Or some other combination?

The way I traditionally did it was create an interface for Database connections that defined the CRUD methods (create(Object newObj), get(Object toGet), etc), and then have a separate implementation for each database (if, for instance, I wanted a stub database or a connection pool over direct connection, Oracle vs Postgres vs MySQL, etc). So if I am accessing three databases, I have three objects. And if I accessed them concurrently (e.g. I needed the data to be cloned across all of them), I might have a Database Manager object that contains those three db objects and sorts out the logic appropriately.

For web services, I would do something similar. We had a REST API that used JSON or XML, so I created a separate class for each request object (Like user, some data point, a collection containing references to both, etc), and implemented a method for each REST function (The HTTP commands GET, PUT, UPDATE, DELETE). Then when we manipulated data, we went to a manager object who held all of the service request objects.

In case you didn't gather from objects within objects, I was always taught "Make main as simple as possible, and encapsulate objects as much as possible. Ideally, main should use as few objects as necessary, within reason."

I think that's better than God objects, but not sure if that fits your definition. How do you view it?

If I'm creating a DB client then yeah, I'll generally have just one object do the CRUD operations, because in that case, the "one thing" is provide an access point for the DB.

In the case of having to be able to accommodate multiple databases, I actually did that very thing recently. In my case, I created an abstract superclass to define all the CRUD ops I wanted to support, and then derived all my specific DB classes from it.

When I create a new class I try to give it a name that tells you what it does. "ECGFileConverter" or "Phillips103Reader." That helps to remind me the specific "one thing" the class does, so in the Philips example, if I need to create a method that writes to a Philips103 ECG file, it doesn't belong in a class named Philips103Reader.

But hey, it may be that reading and writing from a Philips file is trivially simple, in which case it might be appropriate to have both operations in the same class, calling it something like Philips103FileManager. It all depends on the environment. In my case, I broke it up because the system I'm working on needs to accommodate several different ECG file formats (Like Philips, GE Muse, HL7, Schiller, etc.) Some are more complicated to deal with than others, so for the sake of consistency and clarity I have an abstract ECGFileLoader class, from which I derive specific Loaders for each ECG file. Separately, I have an abstract ECGFileWriter class, and derive from it several writers for the various ECG file formats.

So yeah, the definition is very situational, but I know a God object when I see one. When I first got into the meat of this project I had to break up a 4,000 line God object that created and managed several web service calls, including handling the callbacks as inner classes, as well as managing several FTP connections. (Talk about code duplication) all while processing ECG files along the way. Hideous.

Bitter nerds?

Naw man, they're all sour.

The abomination that is CSS?

I hate CSS so bad I haven't the words.

I'm very fortunate to have a guy on my team who understands CSS well.

I think you and I need this mug:




Which one technology have you used that you would absolutely do away with if possible (If it's CSS, what's the second choice? )? Which one technology have you used that you would use more if you could?

I LOVE that mug...

I'd do away with JSP. I can't comprehend why new projects are still being started with a plan to use JSP technology. It's old, it's crusty, it's hard to work with and it is just a hot mess. It was a huge innovation when it was new, but its time has passed, with much better technologies available to do what JSPs do.

I'd use more Maven. Our team uses it for managing builds but there are a lot more things it can do to help us.

Adobe ovens?

ArcticFox wrote:Once I took a straw, and held it in my fist where I had a hidden mini cup of coffee creamer. Then I drew my fist up to my face so it looked like I was stabbing myself in the eye with the straw... This pierced the creamer cup so white fluid came pouring out of the straw and through my fingers... And of course I screamed for effect...

Peoples' reactions were epic...

WOW!!

AWESOME!

Chozon1 wrote:Adobe ovens?

Hehe at first I thought it was a new software application...

Adobe Ovens 2.3 click here to install

Hah, that's the first thing that came to mind too.

ExtraCredits is awesome?

100% pure, undistilled awesome.

Star Wars games?

WAY hit or miss. In general licensed games tend toward weakness because there's usually a ridiculous deadline and they're relying on the name to sell the game. That said, when Star Wars games are good, they're AMAZING. My favorites include X-Wing, Rebellion and Galaxies.