I've never understood object oriented programming. NEVER. Not even once.
Sure, there's inheritance and I grok that (that's a geek term -- I get it), but designing object oriented code seems a dark art to me. How the hello do you know when to use it? If I wanted to design a system, where do I start? Delegation relationships? Has-a, uses-a, looks-like-a-duck?
Side note: I'm tired of people telling me that fortune cookies originated in the USA. Thanks, I do get it.
The real problem that I've noticed is that all the books I've read that try to "teach" object oriented programming all deal with too-abstract concepts. I get that a geometrical object should have a .draw method. Yep. And a circle's .draw method is different from a square's .draw method, and that the circle and square override the .draw method that they inherited from the geometric object. Hooray.
What about real software? Ok readers. Here's a challenge. Lets say I'm going to design some fancy web application thingy do. I've got an database, some templates, and users, photos, write-ups. How do you design it? How do you start?
Please, enlighten.
Comments (7)
what the deuce?? I understand what you are saying, on a word-to-word, grammatical level, meaning: you express yourself well, but as for content: I can’t make heads or nothing out of--- . .. it’s almost like a fantastic river-wade miracle. Lordy! Enlighten, indeed! :D
Posted by caroline | April 4, 2005 1:30 AM
Posted on April 4, 2005 01:30
"How do you start?"
Hello?! A little something called html?! Ever heard of it?
Posted by m | April 4, 2005 3:53 PM
Posted on April 4, 2005 15:53
Well, you start by not re-inventing the wheel. There are some great frameworks out there.
Struts
http://struts.apache.org/
or
Spring Framework
http://www.springframework.org/
and a Object-Relational Persistence Model like Hibernate:
http://www.hibernate.org/
Examine the mirade of practical examples that people have developed for these frameworks and develop a business model based on your requirements.
Then flesh out an interface and develop HTML and CSS to seperate data display from presentation.
If you don't want to use Java for your application development language, I'm sure that there exists equivalents to those stated above in other languages like Perl and PHP.
Design Patterns are also a great place to look for common practices in seperating concerns in your logic.
Posted by majeric | April 6, 2005 9:17 AM
Posted on April 6, 2005 09:17
BTW: Did I tell you that I am really good at buzzword bingo?
Posted by majeric | April 6, 2005 9:25 AM
Posted on April 6, 2005 09:25
OO is a dark art, and I'm still trying to nail down design patterns. There's two really good books which introduce the subject. Head First Design Patterns and the 2nd edition of Design Patterns Explained.
When building a web app, I start by getting the database schema ironed out. When that's more or less fleshed out, then it's time to write up an API to access it. Then it's just a matter of plugging API calls into the code which spits out the HTML.
... I tried to post a code snippet here in PHP but it got chomped by the goddamn filter which runs on these posts. I'll send an email your way ...
This is a very PHP-centric view, since PHP has, until recently, had very poor OO support. Mind you PHP wasn't designed for larger systems which require all the OO stuff.
What language were you building this beast in?
Posted by Clifford's Mojo | April 7, 2005 9:31 PM
Posted on April 7, 2005 21:31
Design Patterns are things we do every day... It's a common pratice. A rule of thumb..
Once I understand what a design pattern is, I find that I've already been using it.
They aren't magical things..
Posted by majeric | April 8, 2005 12:56 AM
Posted on April 8, 2005 00:56
I have no idea what you just said... but I LOVED it!
Posted by Jason | April 14, 2005 10:24 PM
Posted on April 14, 2005 22:24