Are certain OOP benefits and patterns uneeded for small projects?

[linus72982]

For example, if I am building a forum program that I, myself, will code and update and that will never be released as open source to the public, aren't some of the OOP programming conventions and principles overkill?

 

For example, I don't need to encapsulate all of my variables as I know what my program does and what functions take and can't take and what variables not to change - why would I need to encapsulate anything (assuming I don't have a partner working with me.)

 

As another example, do I really need to hide logic from certain places in this scenario?  What's the danger, with the program I used as an example, of combining program logic and view logic?

 

Do I really need to use interfaces if I know that noone else is helping me with the project?

 

What is the harm of directly getting and setting object properties in this case?

 

Those kind of things.  Most of this stuff is for enterprise level programming, is it not?

 

I guess I can understand maintaining good practices so you practice them for when you need them, but sometimes it is just a pain.

[trq]

I guess I can understand maintaining good practices so you practice them for when you need them, but sometimes it is just a pain.

 

Um, good practices are just that, good practices. If you want to be able to reliably change parts of your application without interfering with or breaking other parts then encapsulation is key. Only the simplest of programs will scale without it.

[ignace]

I guess I can understand maintaining good practices so you practice them for when you need them, but sometimes it is just a pain.

 

Good practices, are called good practices for a reason. Sure, you can cut corners, build shortcuts and bridges in your software. But as these come from people who have 10x the combined experience you have, they must of had a motivation somewhere in their lifes, that I believe you will share in the near future.

[gizmola]

It seems to me there are 2 parts to your question.  The first part concerns oop.  Do you absolutely need to use oop?  No.  There's no great barrier to oop and many advantages in my experience, so I gravitate towards it, but if it's not something you are fluent with and it's not 2nd nature to you to write oop based code at this point, you are not breaking any taboos by sticking with procedural code. 

 

The 2nd question involves structure.  How you structure your code, where you put includes and things of that nature is a choice.  You can have one giant script with everything in it, or you can choose to have a number of different scripts as well as scripts in different directories.  It's really an organizational question. 

 

The argument about mixing logic with markup is a much more important one.  When you have if-then-else constructs that are pages long it is a lot harder to see the forest for the trees when you have to later edit those files.  It's just a lot better to put the markup in seperate files that you include as needed. 

[vicodin]

I thought the same way as you when I had procedural programing down pat but was not very skilled in OOP. I put off mastering OOP for a long time and now I realize that was a mistake. I write anything that's gonna be over 30 lines in OOP now. In the end it becomes so much more manageable to update and I can stop working on it for months and when I come back to work on it im not spending hours of time wondering where i left off. The extra time it takes to code in OOP for you will be well worth the experience and headaches down the road.

[jawef]

Of course there is no need to use OOP. Of course carrying reusable classes (or even a framework) might have a cost. But if you stay in OOP best practices will make your code “clean gold” that you will enjoy change it or use it in other projects. OOP is not a one way road but it is the cleanest one we have so far.