If youâre really seriously about advanced PHP going to the next find websites do tutorials
I use â https://www.linkedin.com/learning
though that is subscription based, but someone here posted this link https://laracasts.com/browse/all
that seems to have a free section or it asks for donations (I really havenât go to the site that much). Though it goes down to the basic levels of PHP, but you will firmly grasp PHP where advanced PHP coding will make sense and I do think it even contains some advanced coding techniques?
There are plenty of other websites like this on the internet, just have search for them and check them out to see if it is you cup of tea.
Thatâs generally my guidepost for if I need to keep actively learning at the current moment.
Iâm not one to go into a language and be âI need to learn everything about this languageâ. I learn what I need to, do what i need to do.
The trick to that philosophy is to always be ready to need to learn more. Thereâs always a question that comes up that triggers a need for more information, more syntax. (This is why iâm never an Expert at things, and will never consider myself to be so.)
I can certainly learn from othersâ code, but its not usually a deep learn, itâs a shallow âOh hey I didnt know you could use THAT syntaxâŚâ or âHow does this particular block of code work?â. This sort of passive learning happens pretty much all the time. Sâone of the reasons Iâm around this forum as much as I am.
Have you been making your own custom functions yet?
If not, get used to that before OOP, as your classes will be largely built with functions (methods).
Beyond the ânuts & boltsâ of learning the language and how to do/use specific aspects of a language, I think one of the harder things to learn (not so much to learn, but to learn to do well) is the larger concept of âhow to programâ. That is learning the strategies for how plan and construct your application architecture in a way that is maintainable, expandable and reusable. It is more of a conceptual thing, that can apply to any language, but not really something you pick up from reading the PHP manual.
I think it is relatively easy to learn the language, but much harder to learn to use it well.
Iâm actually interested in how people have learnt this, or even if they think they have.
I had the benefit of being a Computer Science undergrad. Ironically, theory classes were always groan-worthy for me when i started college, because I was always better at hands-on, just âdoingâ and learning by reading code, as opposed to theory-learning.
But itâs the theory classes that taught me the most, and itâs why i consider myself a jack-of-all-trades coder. Itâs also why a lot of my answers to âHow would I go aboutâ type questions involve pseudo-code, or even⌠I have forgotten the term⌠but writing out the steps in english, and then descending through the layers to pseudo-code, and then actual code.
I can tell you how to code a loop in PHP; but if you understand the THEORY of a loop, why and when to use it, youâve got far more flexibility. You can take that concept, and with just a little bit of syntax learning, can apply it to EVERY language. Having a solid foundation of theory is 95% of the way to coding anything; the last 5% is just the syntax of the language youâre using. (sometimes i change these numbers to 99/1% when explaining it. But you get the point.)
I want to add that I usually learn best by solving a problem. I decide to do something then I learn what I need to learn to do it. I do not spend much time learning something I do not need to learn.
Many years ago that was called Structured Programming and top-down design but I assume it was called something else when you were in college.
This topic was initially created to understand the pedagogy of enhancing skills in one language, but I am extending the discussion further.
I got this link:
Interfaces are helpful when you are using code created by someone else. For example, another developer may have created code that manages online payments, but they want to give you the ability to create your own payment class that works with their code.
Here:
interface Payment
{
public function charge($amount);
}
class CreditCard implements Payment
{
public function charge($amount)
{
// contacts a credit card payment provider...
}
}
what is Payment some class from some other developer or an extraction of some part of class?
An interface is a definition of a function without the implementation. An interface can be defined for a function that reads bytes and then it can later be implemented to read from a disk or from memory or from the internet.
In the case of a payment, the implementation of payment using cryptocurrency would be different from payment using a credit card, but as far as the user (the calling code) is concerned, the only thing that matters might be the amount.
Think of Payment here like a signal or âcontractâ that indicates that any class which âimplementsâ this interface must declare certain members/functions. For example, the class CreditCard implements the Payment interface. Meaning, that the class CreditCard âmustâ declare a public method called charge that takes in an amount.
Why is this needed? Well, imagine you also have a class called âDebitCardâ and another one called âBankAccountâ. These are different classes right with possibly much different concepts right? Well, if they all implement the âPaymentâ interface, they are all guaranteed to have a charge method with them. This means a function or some other algorithm can loop through credit cards, debit cards, bank account classes and treat them the same with regard to having a charge method.
You may not always know the types of classes you are dealing with. Is $item a credit card or a debit card? Could it be a bank account? We donât know, but as long as they all implement a payment interface we know they are all going to have a charge method so we can use $item->charge(100) without caring what type of object it is.
This is tied to an advanced system design concept called âPolymorphismâ. If you would like to know more about how this works, I suggest you read up on that topic and its relation to Interfaces. I hope this helps clarify things a bit more.
As for the OPâŚ
Yes reading other peopleâs code is always a good idea to learn more. You learn how they break down a problem, you see their good habits (and their bad, which you can learn from) and it will always introduce you to new thoughts and ideas. Always be aware that how they solve a problem is not always the right or best solution. It is just âa solutionâ. To learn more I would suggest you keep exposing yourself to different articles, tutorials and using different mediums like Videos, books, magazines etc. But donât just read and listen, practice. Write your own programs. Take someone elseâs program and make it better. Get involved in a Github project and contribute. Hands on learning with code, finding bugs, reading error messages etc. will always pay off dividends in the end.
And one last thing to keep in mind, you will always have something you can learn. Languages change, technologies evolve and new concepts are explored. I for one have been developing with PHP for over 15 years and programming in general for over 23 years. I am still finding out new stuff. Good luck on the continued learning!
If you have not yet learn about OOP, you probably need to learn about objects and classes before interfaces. Get the basic fundamentals of OOP first.
In very simple terms, a class is what defines an object, giving an outline of its properties and methods (functions).
An interface will define an outline for classes; different classes that share common things (properties and methods). Classes that implement an interface will all share the features of that interface.
I have started playing with OOP in a very small way. I guess the problem I have in learning to any great depth is that I havenât really got a need for it, and I also think that the very short-lived nature of server-side code is putting me off, in that I keep wondering whether there is sufficient gain in efficiency to make it worthwhile. I am sure on this latter point that there is, just it seems that there is less of an advantage over, say, a desktop application.
As @SamuelCalifornia noted above, I tend to think of something to do and then learn how to do it, I canât sit down and just learn how to use a programming language any more than I could sit down and learn to use a welder without having something that needs to be welded.
I agree, to learn something, you have to try and do it. After reading about OOP, the only way I really got my head around it was by using it for real, rather than following exercises form a book.
You need a project. In the absence of a real project, I started by re-factoring existing websites I had made procedurally.
I started with a very simple one, to get going quickly. Then moved on to something more complex.
And of course, each time you get better at it. If I were to re-visit the first one, I would probably take a completely different approach this time, with more OOP experience under my belt.
#1: I absolutely agree that you need to mix practical and theoretical learning. Do both at the same time, not all of one and then all of the other.
#2: On the subject of not doing âall ofâ⌠donât try and learn an entire subject all at once. Break it down. Learn some basics, practice using the basics, move on to the next small chunk. Take bites you can manage, not the entire meal, and donât be afraid to say âNo, this was too much, break it down more.â
You want to build a website that ties to a database and generates all this stuff on the fly. K, so break it down. First learn some HTML, get your structure together. Then do some PHP, learn how to do variables and loops. Then learn how to connect to a database. Then learn how query that database concisely for what you want⌠etc etc. Project based learning is how I think⌠a lot of us got our start, and what kept us going through the learning. âI want to do Xâ, is a powerful, powerful driving force.