Top products from r/PHP

We found 191 product mentions on r/PHP. We ranked the 141 resulting products by number of redditors who mentioned them. Here are the top 20.

Next page

Top comments that mention products on r/PHP:

u/aaarrrggh · 8 pointsr/PHP

I was right where you are now about 6 months ago. I'd done some unit tests in previous projects and could kinda see the point in using them for certain things, but I didn't understand the need for writing tests first, and didn't understand the value in the red, green refactor cycle.

I can tell you six months ago I started working for a company that believes heavily in TDD, and after going through the initial pain barrier, I now can't see any other sane way of writing code.

There were a few hoops I had to leap through in order to get to this point. One of them was due to the fact that I simply wasn't testing things correctly in the past. You should always isolate your tests to the EXACT thing you are testing in each case - so you should never really be connecting to the database, or depending on other modules etc. Any dependencies therefore need to be injected into the system under test and mocked accordingly, so you know you are isolating the thing you want to test.

You also should never be testing implementations, which is why you should never have to test private methods. You only care that the public methods of a class will return whatever you expect under the conditions you are testing for. This is crucial, because it's this that makes it really easy to refactor your code later.

When you take this approach for everything you do (combined with doing red, green, refactor), you find yourself soon entering a luxorious position of being able to refactor things at a higher level just to make things cleaner and easier to understand.

Just this week I took a system with over 2500 unit tests and refactored some of the fundamentals of that system - found some abstractions and moved them higher up the chain + extracted some interfaces to make the code easier to extend without modification, and all the while I knew everything was working because my unit tests proved it. This is part of the core of a system that deals with literally millions of users each day (seriously), and I did so without fear.

This approach means the code is constantly getting cleaned and tidied up as we go along.

The red/green/refactor approach works something like this:

  • write a failing test (this is important, because simply going for a green pass right away can sometimes bite you - perhaps the test is providing a false positive? You should always see the test fail first for this reason)

  • Make the test pass - I tend to do this in a sane way, but I don't try to engineer my code so much at this point. Just get it passing. The key to this is to only test the expected behaviour of the class, not to test the implementation - we only care about the result, not how the result is achieved. Doing this brings us to the next part:

  • Refactor. This means we can do obvious stuff like removing duplicate code, and then generally chopping and changing stuff around to make it easier to understand and less complicated.

    The refactor step is crucial, but because your tests should be rapid (because we've mocked out all dependencies), you can refactor in very small steps and run the tests each time you make a small change. This way you can neaten up and tidy your code in small, safe, incremental steps, and you keep doing so until you are happy that it's easy to understand and give you the flexibility you need. Once you're happy, you move onto the next test.

    The entire cycle is quite quick actually - much of the complexity comes down to to learning the best way to test and how to mock out dependencies etc.

    Our suite of around 2500 tests takes about 15 seconds to run, but as I'm working on a feature I may only be running one test at that point, so it'll usually take less than a second to run the tests as I'm refactoring. Toward the end of the process I run the entire test suite to make sure everything still passes.

    I went from not believing to seeing this work in practice, and now I honestly don't think I can work anywhere that doesn't do TDD. I would be happy to teach other people how to do it in a company, but as mad as it sounds, to me now, not doing TDD is like saying you don't want to use version control. This has all changed in the last 6 months, having seen it work in practice.

    Here's a book I highly recommend:

    I love the title of that book "Growing Object Oriented Software Guided By Tests" - this it the thing - working this way allows you to "grow" your software, and the tests really do guide you towards the solution you actually need (this is powered by the refactor step).
u/jtreminio · 6 pointsr/PHP

I've noticed this is a fairly major problem with people like us:

  • We're self-taught
  • Have worked alone almost 100% of the time
  • Have not had any formal training whatsoever

    This hasn't stopped me from slowly, but surely, climbing the totem pole job/salary wise, but there's always that nagging feeling in the back of my head of

  • Am I doing this right? These ~200 lines of code ... is there a native function I'm not aware of that handles it in a single line of code that makes mine look stupid and amateurish in comparison?
  • This tutorial I'm reading ... is it written by someone who knows their stuff? Are they using best practices? (1)
  • What's my next logical step? I'm comfortable with what I know, but I need to up my game! What do I do now?!

    We're like the 21st century's hermits... and it's not really our fault. Most of my job interviews can be divided into three different types of companies:

  • Remote, long-term freelance/contract work,
  • In-house, replacing a company's contractor or replacing a programmer that is leaving/fired/whatever,
  • In-house, to join a huge company's team of programmers where I'll be simply another faceless employee delegated to a chilly back office away from most human interaction except for my fellow programmers

    I've done a ton of #1 work, but it feels fleeting and doesn't give me a sense of security. #3 seems to be the best way of gaining access to more programmers where theoretically I learn from them and this would solve the 'hermit' issue I feel I have, but having worked for large companies before that really doesn't appeal to me. So, I'm most comfortable with #2, even though I'm always the only programmer there and all the work that I do goes right over the heads of the people I share the office with (secretaries, designers, managers, owners, etc).

    So, what have I done so far? Well, 6 months ago I tightened my belt and decided to move away from my procedural-style comfort zone and finally wrap my head around OOP. I bought Object-Oriented Solutions and went through it. I felt I learned a ton of useful information that I previously couldn't understand. I've also purchased PHP Objects, Patterns and Practice but I've yet to start on it. Why? Because it wouldn't look good for me to sit in my office at work and go through a book to teach myself, so the only option I have is doing it all at home where my wife complains I'm no longer spending enough time with her. It's the problem with learning by book, instead of learning by example which I would have if I was surrounded by programmers, but it's the price I have to pay I guess!

    Anyways, learn OOP. If you know OOP, learn about namespaces. If you know about namespaces, dive into MVC theory. If you're comfortable with MVC, learn yourself frameworks. If you know one framework, learn more. Companies are paying big money to programmers who can say, "I know Zend Framework/CakePHP (ugh)/CodeIgniter/Symfony inside-out". I mean big money (as in, upper 5 figures, lower 6 figures).

    Once you know a good selection of frameworks and are comfortable with them, start (or you can probably do this concurrently) donating time developing to an OSS project of your choice. It makes your resume sing!

    Trust me, you have a lot to learn if you've only 3 years under your belt (unless you've skipped bathing and working and socializing for those 1095 days, then you may actually be a guru already).

    Sorry about going off on a semi-related tangent!

    (1) - For my most recent example of this, I'm "learning" the whole MVC thing, with frameworks. I've jumped around with, I'd say, at least 10 different PHP frameworks. I settle in to try to learn it, and pick up a few pointers, but then I find I'm not comfortable in that particular framework (CakePHP, too many arrays), or there's simply not enough documentation to walk a newbie through the whole process (Zend Framework, newest version, and ESPECIALLY Kohana), or the writing style is still a little over my head (namespaces! namespaces everywhere!). Anyways, one thing I noticed on reading tutorials is that many framework tutorials say we should build big great monolithic controllers, and the "model" should only be used to do simple CRUD work. But then Zend Framework books/tutorials tell me the model should be nice and fat, and the controller should be very small, which makes a ton of sense to me since the model will be reused over and over by different controllers, so why on earth would I stick a bunch of logic in my controllers? Controllers should be like the office manager - doesn't really do much of the heavy lifting, but directs everyone towards a common goal.
u/localheinz · 11 pointsr/PHP

If upgrading your application from Yii1 to Yii2 requires a rewrite, then switching to Laravel or Symfony will also require a rewrite.

If you have read Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, then you might remember the Grand Redesign in the Sky - if not, take a look at What is Clean Code?:

> The Grand Redesign in the Sky
>Eventually the team rebels. They inform management that they cannot continue to develop in this odious code base. They demand a redesign. Management does not want to expend the resources on a whole new redesign of the project, but they cannot deny that productivity is terrible. Eventually they bend to the demands of the developers and authorize the grand redesign in the sky.
>A new tiger team is selected. Everyone wants to be on this team because it's a green-field project. They get to start over and create something truly beautiful. But only the best and brightest are chosen for the tiger team. Everyone else must continue to maintain the current system.
>Now the two teams are in a race. The tiger team must build a new system that does everything that the old system does. Not only that, they have to keep up with the changes that are continuously being made to the old system. Management will not replace the old system until the new system can do everything that the old system does.
>This race can go on for a very long time. I've seen it take 10 years. And by the time it's done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it's such a mess.
>If you have experienced even one small part of the story I just told, then you already know that spending time keeping your code clean is not just cost effective; it's a matter of professional survival.

Unless you and the team you work with has already asked and answered these questions, maybe there are more interesting questions to ask, for example:

  • What are the actual costs of a rewrite?
  • What is the business value of rewriting the application?
  • Perhaps the business is better off improving the current system than rewriting it entirely?
  • What can we learn about coupling our application to frameworks from this situation?
u/xnoise · 1 pointr/PHP

There are a ton of books, but i guess the main question is: what are you interested in? Concepts or examples? Because many strong conceptual books are using examples from java, c++ and other languages, very few of them use php as example. If you have the ability to comprehend other languages, then: definetly a must read. Beware not to memorize it, it is more like a dictionary. It should be pretty easy to read, a little harder to comprehend and you need to work with the patterns presented in that book. - has already been mentioned, is related directly to the above mentioned one, so should be easier to grasp. - one of the most amazing books i have read some time ago. Needs alot of time and good prior knowledge. - another interesting read, unfortunatelly i cannot give details because i haven't had the time to read it all.

u/soadapop · 12 pointsr/PHP

Check out this online book, it covers a wide array of PHP topics, but there are some solid chapters on objects including the building of a basic OOP website.

The book, PHP Objects, Patterns, and Practice is an incredible resource of PHP OOP concepts and application design. It starts off with a few chapters on the basics of OO PHP coding, giving you the rundown of syntax and inner-workings. From there it covers popular OOP design patterns (MVC, Adapter, Component, etc) and then lives up to its name by showing the patterns in practice.

After you've picked up the basics of OOP, check out a PHP web framework. I would recommend CodeIgniter for its amazing documentation, not to mention this wonderful set of video tutorials CodeIgniter from Scractch featured on Nettuts.

Once you get a working knowledge of a framework and have built some basic applications and websites, take the time to study the code behind the framework. Find out where the entry point is and trace its execution, checking out the source for each and ever object that is instantiated. Not only will you pick up on some sweet OOP concepts, but you'll gain a great understanding of how a typical OO PHP application is structured.

Good luck and have fun!

Keep your programs DRY! (Don't repeat yourself) In procedural, you would take those large blocks of code and faction them up into functions. With OOP, look even more abstractly and take several large blocks of related code and put them into classes, which are, at a very basic level, a collection of related functions and properties.

u/mr_deleeuw · 3 pointsr/PHP

In my opinion, both PHP and Ruby can work well for this.

Were you to use PHP, I'd recommend a framework anyway, something along the lines of Laravel (my favorite at the moment).

This effectively gets you the same general framework tools that you would have using Ruby on Rails. I disagree that RoR would be "too much" for this project, it can be heavyweight, but it is that way to help you create your application faster, not because it has an over abundance of features.

The advantage of PHP is that there are a great deal more choices for hosting your project than with Ruby. That said, there are great choices for hosting Ruby as well - just not as many of them.

I would look at the two languages and get a sense of which you'd be more productive in off the bat. My guess is that would be PHP, because although more people are moving to using template engines like Twig, you can still mix PHP into HTML extremely easily In my opinion, that lets you experiment faster than you can with Ruby.

If you chose PHP, I'd recommend the PHP Cookbook - it's a touch older now, but it contains very helpful learn-by-solving-a-problem recipes that can get you familiar with the basics of the language quickly.

If you're a more academic learner, you might try the more rote Programming PHP - which covers a lot more basics, but doesn't solve as many problems. Still, teaches a lot of the core language.

From there I'd work through tutorials on whatever framework you chose so you can get a sense of the patterns that framework uses. In conjunction with building your core knowledge of PHP, you'll start moving pretty quickly.

u/dohpaz42 · 3 pointsr/PHP

Agreed. There are plenty of resources out there that will help you understand design patterns. If you're new to the concept, I would recommend Head First: Design Patterns, it might be based on Java, but the examples are simple to understand and can mostly apply to PHP as well. When you feel like you've grasped the basic concepts of design patterns, you can move on to more advanced texts, like Martin Fowler's Patterns of Enterprise Design - this is a great reference for a lot of the more common patterns. There is also Refactoring: Improving the Design of Existing Code. These are great investments that will help you with any project you work on, and will help you if you decide to use a framework like Zend which uses design patterns very heavily.

u/thestandardtoaster · 1 pointr/PHP

Hi I think writing small projects will help only to a point. In the end your project may work but will it be readable, easily maintainable, extensible and so on (to anyone but you)....

If you are looking to improve your programming skills and not just php I highly recommend Clean Code, there is another book as well called the Clean Coder which is also excellent.

Reading other peoples code is also very helpful. Check out the code base for, and, they are very high quality php code.

u/code_guy · 3 pointsr/PHP

Then PHP-5-Objects-Patterns-Practice is for you. PHP is know as a "kids" and "insecure" language, because so many people do php the wrong way. I'm not saying there is a right way, but there sure is a wrong one.

After reading first two chapters, learn a little about http protocol. Since you are programming in C i assume you have some knowledge with network programming and sockets, if yes it will be really easy to understand basics. If you didn't program with sockets, do that (it's really fun, you can create you own server, listen on that port and create a web application with C ).
After you get familiar with http ( pay special attention to POST and GET ) you can start working on home projects, learning HTML in the process ( it's really easy so i won't post anything about it here ) and using knowledge you used in first book to design a good app. Also manual is amazing, if unsure about something go there.

This is a proper way to do PHP, so you actually know what you are doing. If you want to just build web apps and don't care about anything ( and continue to contribute to myth that php is "xy" language ) do just that.

Protip: Go the hard way.

u/SandyZoop · 2 pointsr/PHP

My company is working on an introductory PHP book, but I'm not sure when it'll be out (my hope is soon). It will be up to date, at least.

Until then, the most solid introductory one I've found is Luke Welling and Laura Thomson's book. It, too, is a bit long in the tooth now, but it's pretty solid. They are working on a new edition, apparently, which I'll recommend until my wallet says to trash it in favor of ours. ;)

For free resources, as always, I'll plug PHP the Right Way which really does cover up-to-date practices for developing with PHP and also covers lots of PHP 5.4 and 5.5 stuff.

u/[deleted] · 5 pointsr/PHP

I'm not sure the book you are looking for exists. I would recommend a couple of different sources and, put together, would bring you to the "forefront" of PHP (this won't happen overnight tho):

  • Read PHP Object-Oriented Solutions to figure out how PHP's object model works

  • (Already mentioned) Check out PHP: The Right Way to get up to speed on all the latest best practices

  • (Already mentioned) Learn the Symfony2 framework and the Composer dependency manager developed by Fabien Potencier. This will not only introduce you to the best engineered tools in the community but show you what a well engineered project utilizing all of PHP's best practices looks like.

  • Check out Sebastian Bergmanns's Real-World Solutions for Developing High-Quality PHP Frameworks and Applications. This will give you insight into the best practices in managing a high-quality, modern PHP project.
u/ihadisr · 2 pointsr/PHP

The book Learning PHP, MySQL, JavaScript, CSS & HTML5 was one of the most useful PHP books I read as a newcomer to PHP. It's very basic but it teaches how you can start using PHP to do useful and interesting things.

After making it though that book, I think PHP Objects, Patterns, and Practice is a really good next step. It will help you learn to design, organize, and write your code to a more professional standard. It will also help you better understand the workings of a PHP framework.

u/SamHennessy · 1 pointr/PHP

When I said "I can see how maybe they could be useless to you.", that's because I instantly know what kind of programmer you were. You're a low level guy.

I have a copy of "Algorithms in a Nutshell" ( but I never finished it. My favorit programming book may be "Patterns of Enterprise Application Architecture" ( Neither of these books are language specific, but I don't think they could be further apart in every way. Both are very valuable and I appreciate that they both exist.

There is a good number of reasons that you should maximize your use of the built-in PHP functions ( My book is an attempt to come up with a system that will help you learn all of the built-in PHP functions by giving a realistic use case that could be applied in your everyday work.

Being a PHP programmer, it is much more useful to know what functions PHP has for array sorting, than it is to know how to implement array sorting in PHP code.

u/roosterruley · 1 pointr/PHP

It sounds like the first problem you have is that the code is not written in a way that is easily separated out. That is unfortunate, but unless you get a magic wand it is something you will have to deal with. It sounds like you have the .git sorted out, but really git is just both a parachute and a deployment tool - your problem is in the code.

Your basic setup sounds good with a development server. What I'd recommend is that you either run the developer server locally on your machine or run it in a virtual machine since you don't always seem to have access to a development server.

  1. Stop making changes and make a list of the problems that you want to address, then figure out which you need to work on first.
  2. Have a consistent development server setup
  3. Refactor complicated code into simpler code - if you are spending too much time trying to figure it out it could be done better. Check Refactoring or Working Effectively with Legacy Code. Make little changes that work and test it. Don't try to fix the entire application at one.
  4. Test what you are changing to be sure you don't break things (PHPUnit is perfect for this).
  5. Define an overall structure that makes sense - it doesn't have to be a perfect MVC separation, but it have to make sense to You.
  6. Use an HTML templating tool (if you are not already).
u/SkepticalMartian · 11 pointsr/PHP

Beginner and Novice are the same thing. It sounds like you're trying to transition of Beginner to Intermediate.

You really should stop trying to write your own framework for the moment, and start using a mature framework. Good frameworks aren't trivial to write, and generally require an expert level of knowledge to write well.

The thing with a framework is that it helps remove you from a lot of boilerplate code - that is, common code everyone would normally need for any give web project. The easiest way for you to bridge the gap is to begin using and understanding code that is better than yours. Don't reinvent the wheel until you understand how to make a better wheel.

Design patterns are everywhere in good code. The trick is to recognize when a design pattern is being used, and to understand why it's being used. In order to help with this, it's commonly recommended to read Design Patterns: Elements of Reusable Object-Oriented Software. This is a book every programmer should own regardless of the language they use.

u/CaptinShmit · 4 pointsr/PHP

> I'm trying to learn programming had have chosen as my language of choice.

What? What language have you chosen?! The suspense is killing me!

But seriously, this tutorial on Tizag was very helpful to me when I was first learning PHP a few years ago.

And the book PHP and MySQL Web Development is huge, and I never technically "finished" reading it, but it's certainly got some good stuff in it and I would recommend you check it out.

By and far, the best way to learn any kind of programming, is to just do it! Before I started reading programming books, I only knew exactly enough to do what I wanted to do. Choose a project to start with and keep Googling until you figure out how to make it a reality.

Let us know if you need any further help!

u/cythrawll · 1 pointr/PHP

Honestly I haven't read a "PHP book" in ages so I am a very bad source in critiquing. the majority of the one's I have come across are painfully outdated and some right out inaccurate. My suggestion to learn PHP programming better is try books that have to do with programming in general. Books on object orientation and patterns, like GOF or PoEAA are great for learning Object Oriented principals.

But those will help somewhat. What really helped me become a better PHP programmer is to study other languages, and then study their web frameworks, then take what you learned back to PHP. Find out why one aspect is pretty common in X language frameworks, but not PHP frameworks. How do other language frameworks solve the dependency issue, etc. Some languages I suggest learning are actually other ones that are pretty mainstream in web programming: Python for it's typing and how it compares to PHP. Ruby with how mixins relate to PHP traits. and Java is great as there are quite a bit of aspects that PHP stole off Java in it's OO design.

u/stephencorona · 9 pointsr/PHP

Your database is (most likely) going to be your bottleneck.

Get High Performance mySQL - it's a great book that'll help you make smart design decisions. Make sure you get the 2008 edition and not the 2004 edition.

Check out Percona Server, a more performant fork of mySQL 5.1 server.

Depending on your Database load, you should look into mySQL Master/Slave Replication. Maatkit has lots of useful tools for monitoring/backing up mySQL Replication.

Like some other commenters have mentioned, check out Memcached. Make sure you use pecl-memcached for accessing Memcached from PHP. There is another extension, pecl-memcache, but it's missing CAS token support, which helps with concurrency.

Make sure you build pecl-memcached with the latest version of libmemcached. Older versions have a nasty bug that ignore timeouts, so if your memcached server goes down, your PHP processes will wait forever.

Use Nginx and PHP-FPM (it comes with the latest version of PHP). Nginx uses so much less memory than Apache. I have a Nginx Server that is pushing 250mbps of traffic and uses less than 200MB of memory. PHP-FPM uses (about) the same amount of memory as mod_php, but gives you way more control.

You also might want to check out the various NoSQL databases and see if any of them fit your work-load. It sounds like Redis might be a useful tool for you, but YMMV- you'll have to check it out and see if it fits your needs.

u/fatboyxpc · 6 pointsr/PHP

[Test Driven Laravel] is an excellent resource for people who are new to testing, even though it is tailored to Laravel. There are plenty of concepts you can apply to other languages/frameworks, though.

[Growing Object Oriented Software Guided by Tests] is a book that really helped me understand testing, especially test first. The examples in the book are in Java, but again, the concepts apply to other languages. The Test Driven Laravel link I provided is very clearly inspired by that book.

I'm really surprised nobody has included the books by [@grmpyprogrammer] since he's fairly well known as the "testing guy" in the PHP community. I believe all of his books are on his [Leanpub].

[Test Driven Laravel]:

[Growing Object Oriented Software Guided by Tests]:,204,203,200_QL40_&dpSrc=srch



Edit: Apparently I needed to refresh before posting as other people have linked up to Grump Programmer.

u/pogotc · 5 pointsr/PHP

A good place to start might be learning some of the common design patterns, these are common solutions that have been found to work over and over. The standard book for learning them is this one:

It's not a PHP book but the patterns it covers can be used in any language, there's also loads of stuff on Wikipedia around them:

Learning how to approach a programming problem is at the heart of being a good programmer and it's something you'll always be able to improve on (I'm still learning after 15 years of programming) so I would recommend a combination of trying to read as many programming books as you can, asking for help on StackOverflow when you need it, looking through well written open source code to see how those guys approach problems and above all else, practice, practice, practice.

u/freebit · 2 pointsr/PHP

I totally don't understand what everyone's issue is. My favorite thing to do is to refactor legacy code and my bible for doing it is Working Effectively with Legacy Code. I get a huge amount of satisfaction from turning a complete mess into something magnificent and the best part is that it can all be done with minimal risk.

u/kson34 · 1 pointr/PHP

For PHP I would definately recommend PHP 5 Objects, Patterns and Practice. Pro PHP Refactoring is also pretty good. And the latest book on PHP Security is good too.

For javascript I would start with the Good Parts, go to Javascript Enlightenment and read what is available in EAP for Secrets of the Javascript Ninjas because although the book may never actually be finished what is there is worth 30 average javascript books.

u/confused_by_php · 1 pointr/PHP

my path from pre-oop to feeling like I finally understand why to use OOP principles and when / how to implement them has been:

cakephp (briefly) > yii > laravel > Symfony 2 > starting now on ZF2

shortly after getting serious with learning MVC for work reasons, I started by trying to use a framework. I experimented with various - and only really got a basic grasp of why after trying yii properly for a project.

I then redid the project in laravel - improving it but it was still a complete shambles really.

Then I got the headfirst design patterns book:

I cannot recommend that enough.

It's in java but you should be able to grasp it - the main thing is the way constructors are named after the class name in java threw me at first, but after that, its very similar indeed.

Don't pirate that book either - I have tried it in pdf and I bought it in the end, as its not a very easy book to read if you dont have it on paper.

From there, I read about half that book and was able to apply what I had learned to how these MVC frameworks were working - and that was without ever touching the MVC chapter.

Learn about why / how to abstract, factories, why programming to interfaces is super important, and a ton of other things that will take you from being somewhere around beginner / intermediate, to comfortably intermediate heading towards advanced.

u/tedivm · 2 pointsr/PHP

Percona has more stability and better performance. It backports many features from MySQL 5.5 and has quite a few additional features. It's developed by the authors of the MySQL Performance Blog and High Performance MySQL. It remains API compatible so you can use the standard mysql client libraries, as most of the differences are internal, making transition very easy.

We switched to Percona at work recently, after being introduced to it through the XtraBackup utility that they distribute. This is one of the best innodb hotbackup tools I've seen, particularly for the price of free.

u/ForeverAlot · 1 pointr/PHP

These are insightful questions and the answers are less obvious that it might seem. There are subtleties that for various reasons I can't and won't cover here, and the best advice I can give you is to read about the subject(s). The second best advice I can give you is to search Google like mad, because there's a lot of stuff out there and I don't have time to find other books.

  • Scott Meyers' Effective C++ series are aimed at C++ but contain some general purpose advice w.r.t. API design and code structuring (in contrast, Herb Sutter's stuff is almost purely C++, so don't bother with that).
  • Eric Evans' Domain-Driven Design is a little more high-level than your questions but a good read.

    > but setters should be protected, for extensibility

    How often do you extend your classes? If it's often, it's probably too much -- favour composition ("has-a") over inheritance ("is-a"). I declare all my classes final to start with and I rarely have to change that. More, your private members are the only ones you have complete control over -- as soon as something is protected a deriving class can use it, and then the member is effectively part of the public API after all. For this reason, protected is nearly as bad as public. This is one of the things Scott Meyers talks about.

    > Furthermore, do I even need setters if my class is going to be the only thing setting its variables?!

    Automatic code generation is one of the least helpful things IDEs have given us and, I contend, a direct source of much shitty code. Make no setter or getter until it is absolutely needed, and provide neither for public fields (that will cause confusion).

    > Should I ever be setting object variables outside the class?!

    "It depends". There are valid reasons for it, and of course I can't think of any off the top of my head. What you should absolutely avoid is the ability to construct a Foo without a Bar when Foo cannot work without Bar. In this case, it's a constructor dependency, and a Foo::setBar() implies that Foo's Bar instance can be in an invalid state.
u/Xpertbot · 5 pointsr/PHP

LOL, I am also a Junior PHP developer with a Java background ( I didn't want to work for a big corporation doing Java). I took a whole summer to read this and that was more than enough to get the basis of PHP. Its way easier than Java for sure. Good luck.

u/htfo · 3 pointsr/PHP

Try as hard as you can to match the principles of [SOLID design]( Each principle has relatively straightforward rules to follow, and you should have to justify to yourself why you need to break any of them before doing so.

Coming to terms with SOLID design alone will help minimize a lot of problems and help you think differently about writing more maintainable code, but here are some other tips:

  • Minimize branching: if you're using long strings of if/elseif/else blocks, it's a fairly good sign that your function/method is doing too much. Again, there should always be a solid justification for doing that instead of breaking it up into more manageable chunks.

  • Let exceptions bubble up as far as possible: if you're catching exceptions immediately just to log it or display an error message, let them be thrown and catch them all at a higher layer. Similarly, if you have no meaningful way to handle an exception in context, don't catch it.

  • Minimize nesting: a good rule of thumb is to avoid indenting more than once or twice in a method or function unless you have a really good reason to. Practically, this means things like returning immediately if a condition fails instead of wrapping the rest of the code in an if block or breaking out nested logic into their own functions/methods.

  • When a function or method goes past 10-15 lines, start thinking about how to break it up. Is it violating the single responsibility principle? Is there code that can be reused elsewhere?

  • Start looking into design patterns. An algorithm or structure that you came up with on your own and takes 300 lines may be better solved by a pre-existing design pattern that only takes 20. A good place to start is the Gang of Four's Design Patterns. It's pretty dated in its code examples (uses Smalltalk), but it gives a point of reference to know what to look for when finding more up-to-date examples.

    Finally, check out the book Clean Code by "Uncle Bob" Martin, which goes into a lot of the above and more in more detail.
u/anlutro · 6 pointsr/PHP

If the codebase is anywhere larger than a few tens of thousands of lines of code, a complete rewrite is absolutely out of the question. Any book that talks about working with legacy code will tell you this.

To get started, start with the small tasks. Fix code styling, make it readable without making changes. Break small pieces of functionality into classes with static methods (this makes it easier to navigate and reason about than regular functions).

If you can set up a testing suite somehow (it'll probably be easiest writing acceptance/functional/system tests than unit tests), that will give you confidence to make changes and check that everything still works.

There are good books on working with legacy code out there. Here are two off the top of my head:

u/Iconate · 1 pointr/PHP

These two books were the best programming books I have ever read:

u/mapunk · 4 pointsr/PHP

I haven't read it all yet, but I've gotten through a good amount of PHP Objects, Patterns, and Practice by Matt Zandstra. Just like you, prior to reading this I was a seasoned PHP programmer but developed very little OOP stuff. The book provides some good real-world examples and also gives the pros/cons of the techniques he's teaching.

u/ustanik · 2 pointsr/PHP

I strongly suggest picking up the book Head First Design Patterns. The examples are in Java (but simple enough to do with no Java experience) and easily adaptable to PHP. It teaches best practices, design patterns, and coding principles and explains why they're good.

Once you start thinking and coding in design patterns you will be able to learn Unit Testing. After you know how to write Unit Tests you can then write code by TDD (Test Driven Development).

Edit: It's also imperative you know about PSR-0. It allows PHP to easily implement the SR (Single Responsibility) principal.

u/dreistdreist · -2 pointsr/PHP

Yes, coupling your controllers to your framework is bad. I guess you never had to migrate to another framework? I had the pleasure and it ended up in a complete rewrite.

But that was not even my argument, I was talking about the controller dependencies. I guess this is why all those frameworks use the service locator antipattern. It is one bad practice to cover up another which ends up in a lot of tight coupling and obfuscated code.

If I have to go look in another class just to see what the dependencies of a class are, then I am doing it wrong. It should be clear on first glance. Which is why it should be done through simple constructor dependencies.

And by the way, php-di is a bad example too. It is advocating the service locator antipattern.

Else, use $container->get() in your controllers (but avoid it in your services) but keep in mind that your controllers will be dependent on the container

You should NEVER pass in your DIC into your application. For a good implementation have a look at Auryn.

There is a reason why this "perfect" OOP exists and books like Clean Code were written. Good practice leads to maintainable code.

Keep downvoting me, looks like a professional approach to software development is looked down upon here. No surprise other developers don't take the PHP community serious.

u/assertchris · 1 pointr/PHP

This is true, and why I recommend folks read Clean Code when they're interested in writing better code.

u/k3n · 1 pointr/PHP

Interesting that out of all of the PHP programmers out there, of which I am pretty sure that most are men, that the most prominent PHP-extension tutorials are from women?

u/feketegy · 25 pointsr/PHP

Every quality software should have tests. So...

Read the unit tests / features tests first. Those will show you how a specific piece of the code works.


  1. Play with composer packages.
  2. Learn about PHP SPL
  3. Learn about design patterns and beyond
  4. Learn TDD, setup PHPUnit, Behat, Mink, PHPSpec
  5. Read PHP The Right Way
  6. Learn about clean code, EBI, DCI and how to put MVC on a shorter leash here: and here and check out the #cleancode IRC channel on freenode
  7. Read a couple of books like: PHP Objects, Patterns and Practice or Code Complete or Clean Code or The Pragmatic Programmer or The Mythical Man-Month
  8. Start an open-source project or contribute to one

    There are a lot to learn and if you really like programming you will never stop learning.

u/PatrickMorris · 2 pointsr/PHP

Head First PHP & Mysql

The Head First series is really good, they will walk you through the language using numerous mini projects and some bigger ones, giving you a little head start in the right direction for each one. The books in this series always get great review

u/ReconZeppelin · 1 pointr/PHP

Wow. Thanks for the list. Yep, that's pretty much what I had in mind - and I suppose I'm doing this to learn and to have a working system at the end of all of this. As for my knowledge, I'm NOT very smart in PHP or MySQL. I've been reading a book called PHP and MySQL Web Development it's long, but I hope to be familiar with the language as I take my time with it throughout my life.

u/fesor · 8 pointsr/PHP
u/noartist · 1 pointr/PHP

Imo good replacement for gang of four book would be this
To be honest i don't think there is much depth into PHP itself. If you want to become a better programmer you should pick up other languages preferably fundamentally different from PHP. It will change your preception of problems/solutions and the way you program in your main language.

u/pitiless · 3 pointsr/PHP

The following books would be good suggestions irrespective of the language you're developing in:

Patterns of Enterprise Application Architecture was certainly an eye-opener on first read-through, and remains a much-thumbed reference.

Domain-Driven Design is of a similar vein & quality.

Refactoring - another fantastic Martin Fowler book.

u/teresko · 2 pointsr/PHP

You should start slowly refactor the whole codebase. There is no other way. This will not only make you "combing through each line of code by hand" but also require you to understand what was written it.

The alternative is letting the application slowly fade into obscurity.

This might help a bit : Refactoring: Improving the Design of Existing Code

u/edwinthedutchman · 4 pointsr/PHP

You might be interesred in PHP Objects, Patterns, and Practice

It starts with the usual object basics that you might want to skip through, but quickly progresses to more interesting topics. It also provides a historic context of php. I highly recommend this book to any php coder.

u/ircmaxell · 3 pointsr/PHP

My only reservation here is that it's not really a TDD exercise. TDD typically involves choosing and writing tests for the functionality being added next by the developer, as opposed to here where the test dictates the next piece of functionality to add. It's a subtle difference, but a tangible one.

Now I'm not saying that this isn't a good idea. I'm not saying it isn't useful. Just that it's not quite TDD, as the design evolution is already in place for you, and you're just writing the code.

For a great example of what I'm talking about, check out Kent Beck's Test Driven Development, By Example. He walks through developing a few applications using TDD while keeping a "mini backlog" of what to do next, constantly adjusting the priorities.

Again, not putting this down, just not quite sure if it's as much as a TDD exercise as a testing exercise. But it's an interesting concept...

u/Veonik · 1 pointr/PHP

I misunderstood. However, I'm not seeing how that has any bearing on this conversation. Your original point was that building a well-thought-out project using proper design patterns takes longer than otherwise. Yes, I have experience and so yes it might be easier for me, personally, but what does that have to do with your original point? Are you saying that the initial time investment somehow nullifies the benefits that I am arguing for? You learned how to write code in the first place. Why not learn how to make your applications more maintainable?

If we are including the initial time investment in understanding how and when to use design patterns, then yes, there is a decent chunk of time to be spent. For me, it took about 6 months spent reading this book, using Symfony, and making myself sick with google searches to really feel comfortable-- and I am still always learning new things. But that investment has proven immensely beneficial for every single project that I've worked on since.

u/24x7man · 2 pointsr/PHP

If you don't really know how to code, I would vote for PHP. There are tons of books, tons more examples, and is pretty easy to get started on with WAMP and LAMP stacks.

I personally started PHP using this book:

But, if you don't want to take a formal training after this, dive in. It'll take a bit, but you can search and read for the stuff directly what your after. I have built a couple applications this way, and was fun.

u/dendeigh · 5 pointsr/PHP

Not particular to php, this is a book about refactoring legacy code in general

There are a few chapters about how to get legacy code under tests before refactoring. Some methods unfortunately cannot be applied to php (e.g. php core functions cannot be overriden), but still, I found it pretty useful overall.

u/leftnode · 3 pointsr/PHP

Thanks! Yeah my opinion isn't popular around here because PHPer's love their docblocks.

The book that changed my mind about them is Clean Code by Uncle Bob Martin. The book is simply amazing, a quick read, and tells you what you already know, but in an articulate way.

Two things in there that really shake up a lot of Java/PHP programmers is his view on method length and docblocks.

Regarding method lengths, he maintains that a class method should be no longer than 4-5 lines. Any longer and it needs to be split into another method because it's probably doing more than one thing (a method should do one thing only). I find this one the hardest to comply with because it requires a great deal of discipline. But boy, when you do comply with it, your code is so much easier and cleaner to read.

Obviously, this goes for programmers working on systems where resources are virtually unlimited (99.99% of all PHP programmers). An embedded programmer probably has to watch how many methods/functions are pushed onto the stack, but programmers making web apps don't need to (as much) because resources aren't as tightly controlled.

Regarding docblocks, he says they're entirely useless, and I agree completely.

For example, this is useless:

  • The ID of the user.
  • @type integer
    private $user_id = 0;

    Why is that docblock completely useless? Because it's told me nothing about the variable, and nothing that couldn't be gleaned by looking at it's definition:

  • It's name is user_id so the description is useless. If it holds something other than the ID of the user, then you're really in trouble.
  • By it's default value, 0, we can tell it's an integer.

    So now you've wasted 5 lines of code (not that they're a precious resource or anything, they just clutter up the rest of your code) to describe a variable that's obvious from it's name and default value.

    If you need a docblock to describe a method, that's just as bad because it means you can't deduce what the method does by it's name and arguments.

    Taking the only PHP project on the front of Github, let's pick a random file and pick it apart (sorry CakePHP, don't take this personally):

    Look at the method translate(). It should be pretty obvious what the translate() method does in an i18n class. Picking apart the docblock:

  • The fact it can be used statically or through an instantiation is another issue that should be remedied.
  • Any decent editor can pick up the argument list just from looking at the definition (and re: the $count variable, that's a bad name because it's not very descriptive at all. $pluralFormCount would've been better, more descriptive and now doesn't require the description, however, it uses a magic number (6?) and that's another issue)
  • We know it's public because it's not described as private
  • We know it returns a translated string (again, if it doesn't, you have bigger problems)

    Next, look at the clear() method. The docblock is longer than the entire method and it tells me nothing useful.

    clear() is a poor name because it doesn't describe what it clears. clearBuffer() or clearTranslations() would've been a much better choice. It says it's useful for testing, but not why, so that's a useless comment, and it doesn't @return void, it returns nothing, so that's a misleading docblock.

    Which brings me to another point: updating docblocks. It takes a lot of discipline to do so. I'd much rather concentrate my discipline on writing clean and clear code, unit testing, and writing good documentation outside of my code than keeping a bunch of docblocks up to date.

    Thus, in summary: docblocks cloud your code and make it harder to read while adding nothing.
u/SteelCity905 · 2 pointsr/PHP

PHP Objects, Patterns and Practice - Expert's Voice in Open Source -

I am only on page 65 and I got a good grasped of OOP.

Building PHP Applications with Symfony, CakePHP, and Zend Framework

Another great book. Especially if you havent decided which framework to go with.

u/pmjones · 2 pointsr/PHP

That's what I get for being snarky. ;-)

There's another excellent book called Design Patterns that predates the Uncle Bob one, if you'd like to learn some history on the pattern.

u/ckdarby · 4 pointsr/PHP

I have included some links for more information about myself in the original post.

To have a better idea of the type of person I am these are the books within my arms reach right now:

Design Patterns: Elements of Reusable Object-Oriented Software

[Refactoring: Improving the Design of Existing Code](

The Mythical Man-Month

Along with some other ~50 similar books I've read.

u/fork_that · 1 pointr/PHP

For TDD it's more about theory, the logic and steps pass from programming language and tools freely. So you don't need a PHPUnit specific book.

The best TDD book I've read is Read that then start applying those processes to your development flow.

u/greatredpie · -4 pointsr/PHP

The O'Reilly head first series of books are great. They offer an easy to understand and read book. These books go over the basics while teaching you PHP.

u/ivosaurus · 2 pointsr/PHP

Followed by

When you're beginning in PHP, remember that the code that you write at first will be almost surely very insecure in some way or another. Now no-one is perfect at security, but just keep this in the back of your mind while you're learning :)

u/crysiscrytical · 2 pointsr/PHP

I'm new myself, so I can't offer direct criticism myself, but I thought I'd share the book I'm reading now that I find helpful for learning design patterns.

[Head First Design Patterns]

u/growlzor · 1 pointr/PHP

I started with Head First PHP & MySQL when I started years ago. Two books I loved the most though were Beginning PHP and MySQL From Novice to Professional and PHP Solutions Dynamic Web Design Made Easy.

Later this book helped me immensely PHP Objects, Patterns, and Practice.

Ultimately, is your bible and you can learn everything from there alone. Post on forums and ask for help. Try something and stick with it, don't jump around creating dozens of projects but stick with one and expand it.

Also this

u/systematical · 1 pointr/PHP

Go to the library and skim through some books till you see something you like. If its a few years older thats okay, use the internet to catch up from there. Ideally it should be since PHP 7, but the differences between 5.6 and 7 are not terribly huge in terms of just getting your feat under you. Many many years ago I taught myself with this one from a library. I like free shit though. I don't see the point in owning books unless I view it as a classic or will use it for reference for a while, even then you can just keep checking it out for months until someone puts a hold.

u/fuzzycardboard · 2 pointsr/PHP

It's not about "sum of its parts" or composability. A response has no identity. It makes a perfect value object candidate, and immutability suits it as such.

A book has an identity. Your book is obviously different than my book, even after you get done writing and it has all the same words as mine.

An HTTP response has no identity. All responses with the same data are literally the same response.

I would suggest reading Domain Driven Design by Eric Evans if you want a much better explanation than anyone here can probably offer.

u/martindines · 5 pointsr/PHP

I've go with PHP Objects Patterns & Prac. I haven't read the other 2, but this book is definitely worth investing in

u/renang · 2 pointsr/PHP

From one of my favorites books, Clean Code: A Handbook of Agile Software Craftsmanship:

> Others who see that commented-out code won’t have the courage to delete it. They’ll think it is there for a reason and is too important to delete. So commented-out code gathers like dregs at the bottom of a bad bottle of wine.

u/amazingmikeyc · 1 pointr/PHP

Yes. Also, Michael Feather's book is good (I think they both reference eachother as they're both in the agile/tdd clique)

(tldr; write automated tests where you can)

u/mctonka · 3 pointsr/PHP

Well, any logic which doesn't encode business rules is, by definition, not business logic. So, for example, most or all of the logic within your infrastructure layer would not be business logic. But I suspect what you're really asking is "what sort of non-business logic belongs in a VO?" The answer to that is simply: any logic which goes hand-in-hand with the value being represented, and is side-effect free. One of the examples Eric Evans gives is that of a Paint VO which has a method mixIn(Paint $otherPaint): Paint that encapsulates the logic of mixing one paint into another, and produces a new VO.

u/fewpeople · 1 pointr/PHP

PHP Objects, Patterns and Practice (3rd Ed) is a fantastic book which is a little bit more advanced that takes you into the OOP aspect of PHP.

u/DukeBerith · 4 pointsr/PHP

For design patterns, this book helped me a lot when I was fresh.

Don't be fooled by the cover or the content, it is quirky on purpose to help make you remember it.

u/davedevelopment · 3 pointsr/PHP

Growing Object Oriented Software, Guided by Tests is hands down the best TDD book out there in my opinion.

u/phpdevster · 1 pointr/PHP

There's this:

And while i won't link to them here, you can find pirated PDFs of that book quite easily in Google, if you'd like to skim through and see if it's what you're looking for (and if it is, buy it - don't be a dick).

u/daronjay · 18 pointsr/PHP

Working Effectively with Legacy Code

Might be a good place to start. Don't rebuild in one hit, isolate functionality, wrap with tests and abstraction layer, rebuild one component at a time

u/serious_face · 2 pointsr/PHP

I think the best way to learn OOP and MVC (and programming in general) is to write a large program from scratch without thinking about any of that stuff. When you have it working, read a book like Code Complete, and you'll be introduced to all kinds of concepts that make your life much easier.


I forgot the most important part. If you get into OOP and really feel like you don't need it, or that it makes your life more difficult, simply don't use it. Many people like to get religious and dogmatic about certain ideas in programming, but there's absolutely no reason to not just go with what works for your situation.

u/meritt_zare · 1 pointr/PHP

Sara's book is also an excellent one on that topic.

u/Pornhub_dev · 1 pointr/PHP

I thought about the writing extensions part myself, but i think it is too much stuff to cover.

I'll probably put some reference (there is only one -decent- book anyway on the subject : Extending and Embedding PHP ), there is a couple articles on that do a nice job on this specific subject.

u/greg8872 · 9 pointsr/PHP

This book helped me a LOT.

PHP Objects, Patterns, and Practice

I've known the basics of OOP for a long time, just always had trouble wrapping my head around things for real working items. (that and OOP in PHP years ago was way different than now). This book was great. If you get it, make sure you get the latest edition. I see in getting you the link, there is newer version than what I read (of course, I read it online via

u/cs2818 · 4 pointsr/PHP

Grab a decent book on the subject, I used PHP and MySQL Web Development years ago to get started.

Alternatively, has some basic PHP intro videos.

And you can find both of these options for free by searching around if you want.

u/gevvvvv · 1 pointr/PHP

I've been trying to read everything and anything that interests me. You probably need a reading list of some sort. One book I can recommend right now is Design Patterns: Elements of Reusable Object-Oriented Software.

u/mcdronkz · 2 pointsr/PHP

It's not a website but a book like Code Complete contains this kind of information.

u/jailbird · 4 pointsr/PHP

Check out this question on StackOverflow.

I could also vouch for PHP Objects, Patterns, and Practice. When I was learning OOP, I found the book straightforward and quite easy to understand.

u/meddyiscool · 3 pointsr/PHP

Clean Code has had the most significant effect on improving my programming ability. The examples are all Java, but it's completely applicable to PHP development.

u/jesusdiez · 3 pointsr/PHP

Test, test and test. Read about TDD ( Learn about the tools (phpUnit, phpSpec, behat) and start using them. You will find hard testing at the beginning, like everything, but later you won't want to work in without tests.
Apart of that, learn how the composer package manager works and don't do anything without it. Don't reinvent the wheel and use components that someone already invested a lot of hours in (auth, orm, microframeworks).
Think about your systems as a composition of pieces that work well together, without need of coupling to a specific framework.

u/Ozymandias-X · 2 pointsr/PHP

The book that helped me most coping with legacy applications: Working effectively with legacy code

u/pisskidney · 2 pointsr/PHP

read this
then this

Build something you like while reading them.

u/joellarson · 6 pointsr/PHP

I've learned to enjoy writing similar to how Robert Martin outlines in his book, Clean Code

If I were to write this specific code by it, it would look something like this:

function retrieve_all_items_from_storage()
$result = DB::select("SELECT id, item, description, cost FROM items");

return $result;

function format_item(&$item) {
$item->item = "Hello " . $item->item;

function get_all_items()
$items = retrieve_all_items_from_storage();

if(empty($items)) {
return array();

foreach($items as $item) {

return $items;

However, I would never write my example into my own projects because there would be a lot more complexity to it. For instance, I would have the retrieve_all_items_from_storage implement a data mapper, and have it return a Collection object, where I would do $itemCollection->isEmpty() instead of empty($items). It would also be organized into a multiple classes because of the nature of the functions. So while this is not something I would condone in your software, I firmly believe it is almost always better to have your method names define what a block of code does, rather than jamming it all into a function and commenting it out.

-- Edit --

I seemed to have missed the original question. If I had to pick, I would say the second block of code for similar reasons to what I outlined above.

u/voidpirate · 2 pointsr/PHP

I personally recommend this book if you're a non-beginner as you mentioned.

u/FurriesRuinEverythin · 2 pointsr/PHP

This was the book that helped me learn a lot of what I know

It's probably considered somewhat dated with all the current obsession with OO, MVC and "unzip and run" web apps. I'm not sure though as I had the first edition, years ago. But it is one of the best PHP books out there for beginners.

u/haywire · 1 pointr/PHP

Only problem is that there's bad books out there and if you're reading one a week perhaps you will be more likely to expose yourself to them as there's not so much time to research which books are good. Perhaps it'd be better to read one excellent book every month.

Also, book learning isn't for anyone. I don't think I've actually managed to read a programming book cover to cover, however I am an experienced web developer.

Ooh, one book I did read...

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)

u/jasonlotito · 1 pointr/PHP

First, ignore the code examples on the page. They are fairly bad. The reason you don't grok OOP is because of examples like these. What you want is a good solid book.

Patterns of Enterprise Application Architecture

PoEAA sounds imposing, but it's really good. I highly recommend it.

I also recently wrote up an article on Data Mapping that you might be interested in reading. If you have any questions, you can ask. Basically, for me, when I finally groked OOP, was when I was reading an article on observers, and how that pattern works, and I started to get it. I'm still learning. I'm only now getting over my need for getters and setters (You don't need them, they are bad, stop using them).

But yeah, the reason most OOP articles are bad is because most people using objects are merely using them as namespaces for functions and variables. If you have any questions, let me know.

u/mrferos · 1 pointr/PHP

When you get to a project larger than a small business or personal website it's less about the language and more about imposing a structure that makes sense backed by a data model that's thought out and performant.

I recommend these books:

u/MorrisonLevi · 2 pointsr/PHP

As others have mentioned you need tests.

If you can't write tests at all because the way the code is put together then the first step is to untangle things. This can be hard. If your code is working I'd probably just leave it alone until you need to touch the code for some other reason (adding a new feature, usually).

I recommend this excellent book for learning about specific ways to refactor, as well as when they are commonly used:

u/cyrusol · 11 pointsr/PHP

You might want to look at Patterns of Enterprise Application Architecture by Martin Fowler. There are 3 full examples that you are looking for right now:

  • table gateway
  • active record style ORMs (like Eloquent)
  • data mapper style ORMs (like Doctrine which is exactly like Java's Hibernate)

    The examples are in Java but you probably won't have any difficulties understanding the code. He builds those from the ground up and finally compares them and says when to use what.


    Beyond that the abstraction endgame is to completely separate your persistence model from your domain model. If you have a user with an email address and other fields you don't want to have just one class that deals with loading the user row from a SQL database based on his email address, you want the latter part be isolated into its own class. (So that the user could in theory also be requested from an API or Memcached or a text file.)

    class User { ... }
    interface UserByEmailQuery {
    public function findByEmail(string $email): User?;
    class SqlUserByEmailQuery implements UserByEmailQuery { ... }

    But it's sometimes simply not worth (economically) to go that far.
u/celtric · 1 pointr/PHP

You can read books with code examples written in Java or C#, the syntax is very similar and the principles apply in the same way (PoEAA comes to mind).

u/JochenKlump · 1 pointr/PHP

Growing Object-Oriented Software, Guided by Tests - very practical description with a lot of code examples on how to implement tdd

u/modestlife · 1 pointr/PHP

Don't know how I forgot about her. Got my information mainly from her book Extending and Embedding PHP.

u/SaraMG · 2 pointsr/PHP

"Extending and Embedding PHP"

It was released in 2006 and is based on PHP 5.2 so naturally a great many things have changed about the internal APIs since then. The first five chapters are solidly still relevant, and several others are usable with a pinch of salt (array APIs have changed dramatically, zvals are stored at one level of indirection less, and PHP4 objects are beyond irrelevant).

u/gunshard · 13 pointsr/PHP

Checkout the book PHP Objects, Patterns and Practice by Matt Zandstra, it helped me dive right into OOP after years of procedural programming.

u/Thatonefreeman · 2 pointsr/PHP

You should read this:

This helped me a lot when getting used to OOP and how to practically use it in my apps.

u/jb2386 · 6 pointsr/PHP

Full rewrite in 1 go is the worst thing you can do. Doing it part by part will allow you to do it better.

Check this out of you haven't already:

u/TheOssuary · 7 pointsr/PHP

I've been reading Clean Code: A Handbook of Agile Software Craftsmanship and chapter two discusses this, and agrees with you. Interfaces should not be suffixed with 'interface', and if you run into naming issues (wanting to name the interface and the class Product) you should lean towards naming the interface Product and the class ConcreteProduct.

I started following this practice and it makes a lot of sense after you start working this way. If I'm making an interface it means anything which implements it should be valid, so I should never type-hint a concrete implementation, I should only ever type-hint the interface. Adding the Interface suffix is just adding verbosity and possible confusion.

u/likepizza · 1 pointr/PHP

If you think you can make it through what is probably a boring book, there are a lot of books that would take you from where you are to objects and design patterns. I bought this one:

u/farsightxr20 · 4 pointsr/PHP

I'd suggest finding a newer book as soon as you can. This example is riddled with bad practices, and it's best to avoid forming bad habits instead of trying to break them later.

Some things that jump out at me:

  1. The shut-up operator (@) shouldn't ever be used. It's slow, and makes debugging a pain in the ass.
  2. While using "or die()" might be adequate for a quick and dirty script, it's never a good idea to simply exit a program because an error has occurred. Look into Exceptions for error handling.
  3. The mysql_* functions are dated and shouldn't be used. Use instead PDO (with prepared statements) (highly recommended) or mysqli. Mysqli has procedural methods similar to the ones in your example, but you need to be careful to escape all of your user-inputted values with mysqli::real_escape_string or mysqli_real_escape_string

    My personal recommendation would be PHP 5 Objects, Patterns, and Practice, as it will teach you stuff you should know about programming in general, as opposed to simply PHP syntax.
u/super_thalamus · 3 pointsr/PHP

Oh man. You need to work on your coding conventions and formatting. I assume you've never worked on a team before. You will make people very upset. It's really hard to follow the logical blocks and flow of your code. You should buy this book and work your way through it. You will be 1000 times better at this.

u/newmanoz · -1 pointsr/PHP

> One single database object is not bad design.

It is bad design. Read this guide:

This book will help you to understand, where is your mistakes:

u/ir8prim8 · 4 pointsr/PHP

They are older books, but really changed my way of programming. Refactoring by Fowler and Test Driven Development by Beck.

Feeling overwhelmed and confused can always be solved by breaking things into small enough problems and making enough tests to make sure that your assumptions match reality.

Frameworks can be confusing the way they hide details away from you. Remember though, that with open source, there is nothing to stop you from digging into the framework methods you are calling and see how they work. If you get stuck, sometimes looking at the source will tell you more than looking at the docs. Try multiple frameworks in multiple languages. Once you think you have an idea of the different parts required, try using a template library and an ORM library and write the rest of the code you need to make a basic custom framework.

If you want to see a more direct approach to web services, take a look at Go, where frameworks are almost discouraged.