2

I've been reading and digging into the theory in OOP a lot recently and one question always seems to come up for me.

It seems that some of the concepts, such as abstract classes, interfaces, and to a lesser extent visibility, have more to do with situations where other people will be extending your code...

For example, let’s say I was making a simple CRUD application for a small company to store customer information, contact information, orders, etc. The size of the application may warrant an OOP architecture, but I know from the offset that no one else will be extending this code and that it will be a 'closed' project once I've finished it. As such, it seems that setting things up for the future, and creating those sort of protections and contracts -- via abstract classes, interfaces -- may be overkill? Does that seem accurate?

All that being said, I'm all for doing things correctly and thoroughly at all times. And I also understand that one of the main purposes of OOP is for maintainability and extendability for the future. I just have a hard time wrapping my head around interfaces and abstract classes sometimes, and I have the feeling it's because the smaller projects I do rarely involve other people extending the code, or creating APIs and such.

Improve this question
2
  • It's more for your benefit than anything else. When you have to go back to maintain it, do you want things to be clearly organized and simple? Commented Feb 1, 2011 at 6:28
  • true, and I get that. But I suppose I'm not quite sure how interfaces and abstract classes my play into that, when dealing with a small scale app Commented Feb 1, 2011 at 6:47

5 Answers 5

Reset to default
2

The size of the app may warrant an OOP architecture, but I know from the offset that no one else will be extending this code and that it will be a 'closed' project once I've finished it. As such, it seems that setting things up for the future, and creating those sort of protections and contracts -- via abstract classes, interfaces -- may be overkill? Does that seem accurate?

Well, in short, that's not accurate. If you're writing code for a reason, there's a good chance it'll need to be maintained. Following good OOP practices will make it easier to debug problems in the future. But that's not where the key to OOP is.

As you have indicated, the true benfits of the OOP paradigm are when it comes to future modification. From the 60/60 rule, we know that 60% of a projects cost come after delivery. And 60% of that cost comes from changes to the specification. That's why you should do "all that work".

Sure, for some projects it will be completely overkill. But the key is that the only time that you can actually know if it's overkill is well after delivery when you don't change the application. I've seen first hand many projects that fit into both categories (before delivery we thought would be dead after, but wasn't and those we thought would be really active but died). So since you can't know for certain until the time comes to make the modifications, it may (or more likely is, depending on you exact situation) be worth it to just invest all the effort for all projects...

Remember, if you don't have time to do it right the first time, when will you have time to do it over?

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

+1 because this
1

Honestly, you won't be writing any interfaces or abstract classes until you start writing code with sufficient complexity. The reason they feel like overkill for the examples you read in books is that they often are. Once you actually get into one of those big projects, though, you'll see why they're useful.

What you will immediately benefit from are simple classes, with maybe some shallow inheritance. The most obvious place will be your database abstraction and data models. You benefit from doing that immediately, even while your program is small. If there are two places you create a new blog post, then having a blog post object immediately moves the code for creating it, and all the database interaction related to it, to a single place instead of duplicated:

$post = new BlogPost(); $post->setTitle("Hello World"); $post->setContent("An awesome update about my life!"); $post->save();

...etc

Improve this answer

Comments

0

It is not just other people extending your code, but you at a future date.

If your application is one page, or very small, you can code your PHP procedurally.

Improve this answer

1 Comment

sure, i get that. What I'm talking about is not one page, it's definitely multiple pages, maybe 15 classes. Basic CRUD, and best suited for OOP, im just wondering to what I extent I apply it, as thing like Abstract classes and Interface seem a little unnecessary in that context
0

And I also understand that one of the main purposes of OOP is for maintainability and extendability for the future. You pretty much summed it up there. If not for the sake of present usability, it definitely can prevent major bald spots by employing such methods early on in the development process.

How are you so sure it will be a "closed" project? Is it really impossible for no other features/modifications to occur?

Improve this answer

1 Comment

that's true, I suppose it could potentially need modification
0

OOP is foremost a syntax variation. You can write object-oriented code in procedural or low-level languages too (see glib).

Since it's a syntax construct, it should be used for making code more readable. And only that. Maintainability and extendability are secondary attributes (and sometimes misattributions).

Avoid object happiness, but don't eschew sensible structures.
http://www.codinghorror.com/blog/2007/03/your-code-oop-or-poo.html

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.