1

I make very long programs. There are many files.

Basically I have too many function.

Every code can pretty much call every function.

If I want to pull out some function and store it as a library so other function can use it I am in trouble. That's because one file has function that's used by other files that has function that is used by other files.

I suppose some functions should be "private" and cannot be called by other functions but PhP doesn't have private functions.

Another solution I am thinking is using namespace.

I like to avoid object oriented in PhP though it could be a solution too.

So how do I separate my codes into manageable pieces?

Currently all of my files are in the same directory. Perhaps different library should be in different directory?

What does the pro do?

user4951
  • 699
  • 6
  • 14
  • 1
    Possible duplicate of [How to build completely modular web applications](http://softwareengineering.stackexchange.com/questions/120956/how-to-build-completely-modular-web-applications) – linuxunil Dec 28 '16 at 11:13
  • the pro nowadays uses OOP. Though, i understand that thats no solution for you – marstato Dec 28 '16 at 12:57
  • In PhP? I don't even know if PhP is designed for OOP – user4951 Dec 28 '16 at 15:11
  • 1
    Well one thing that pros typically do is to learn a bit about the language they are using. PHP does do oop quite well. Lookup require_once to see how deal with functions that rely on other functions defined in other files. Might also consider changing some of your functions to static class functions. – Cerad Dec 28 '16 at 15:30
  • @JimThio the standard library is not designed for OOP. But there are some very good OO frameworks out there, e.g. Zend and Symfony. The OO features of PHP are actually usable since 5.6, more so since 7.1 (but still not as good as others like C++, Java or .NET) – marstato Dec 28 '16 at 15:55

2 Answers2

2

It sounds like you're having problems with generalization.

To generalize a function, you need to figure out what the function does in common, and then pass it the differences (that which is not common).

For example, the following is a sort function. It accepts an array or collection of some sort, and a comparison function. The comparison function is a custom comparer that tells the sorting algorithm which of two arbitrary values in the collection is greater.

function sort(array a, function comparator c(x,y)
{
    // sort occurs here.  Comparator function used to compare values during sorting
    // Comparison is generalized, because you can supply any arbitrary comparator.
}

Another example of generalization is generics:

function sort<T>(collection<T> a, function<T> c)
{
    // will work for any type, with compile-time type safety.
}
Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
0

Even though you "like to avoid object oriented PhP", you should really learn how to use object oriented design if you want to write large software. OOP in PhP is kind of tacked-on, but the tacked-on frameworks will still work.

The basic idea behind OOD is that a component should know how to do everything directly related to it, so you don't have to think about how the parts interact. For example, a Car would contain not only the parts (data) of a Car (like wheels, engine, steering wheel, location), it would also contain information on how to do all the things a Car should be able to do (start, drive forward, reverse, turn).

The potential benefit is enormous. If you need a Car object to do something, you don't need to use and maintain some function floating in global space. You just tell the Car what to do through a simple interface, which in this case would be the steering wheel, gas pedal, brake pedal, and gear shift.

If you spec what those internal functions do in an abstract way, a programmer using a Car object doesn't need to know how the engine works or how the data is stored inside the car to use the object (imagine if you needed a degree in mechanical engineering to drive a car in real life). All a programmer needs to know are simple instructions that explain what happens when they use the interface (steering wheel, etc.). As long as the implementation for those internal functions fulfills the specification, it's safe to program around it. If you have different implementations of Car for different situations (say, Sedan and Truck), the same code will work for both Car objects. More importantly, if the code needs to change because you find bugs, changing the code won't break the system.

I've worked in enormous systems that aren't OO, and it's a huge pain. Learning to approach from an OO perspective is something that will make your life much easier in the long run.

Trixie Wolf
  • 414
  • 2
  • 6