New day! Like every day I edited and published yesterday’s notes. I’m currently on page 105 in PHP Objects, Patterns, and Practice – which is just at the start of using the Reflection API. My goal is 50 pages. That would be to the start of the Singleton pattern.
I also changed the goals a bit and made them clearer.
Back to the book! That’s a pretty cool example using the Reflection API. The author describes how to implement a simple plugin system. Neat!
With OOP think about responsibilities. Don’t try to remodel the world but focus on the problem at hand.
If you use flags or class data with a conditional then it’s a good idea to think about inheritance.
Start with the interface and stay there for a while. Don’t start implementing or thinking about the children too soon.
And we’re back to design patterns. I’m a bit optimistic that the author will present them better as last time.
Problems tend to recur, and as web programmers, we must solve them time and time again. […] Over time, we answer these questions with a greater or lesser degree of elegance and evolve an informal set of techniques that we use and reuse in our projects. These techniques are patterns of design.
Funny, how he describes them less as god-given rules and more as common manifestations.
Patterns are (or should be) essentially bottom-up and not top-down. They are rooted in practice and not theory.
Yeah.
I think I may know why I have a dislike for the hype around patterns. It feels like rote learning. Instead of teaching people HOW to create solutions, the solutions are presented. Learn the problem, learn the solution – don’t learn how you can come up with your own ones.
The examples so far are really good. Also one note: One responsibility in a sense of easy testing and decoupling.
What I mean is that if you have some object handling something which comes out of a database. The object shouldn’t wonder where it comes from.
The GoF recommend that you actively seek varying elements in your classes and assess their suitability for encapsulation in a new type.
I think I now begin to understand why Refactoring and XP become to popular – especially XP. People started using OOP (and patterns) and created flexible monstrosities which nobody understood anymore. And instead of writing valuable code they wrote flexible code. Makes a lot more sense in the context for me.
This book is so much better than the other one. I read the sections on the Singleton and Factory Method. Instead of a short intro and praising the pattern it starts off with a problem and possible solutions. You basically get tricked into patterns. Also the author shows problems with each pattern.
I don’t really have to say a lot about the presentation of each pattern. So far, there wasn’t that much new stuff which surprises me. However, there’s still a chapter about enterprise and database patterns coming up. That could be interesting!
Oh, and I love the examples in this book!
I quite like the Decorator pattern. It’s simple and works. Somehow the biggest problem I see is the speed of execution – but maybe that isn’t really problematic.
The behavioral patterns sound interesting – that is the one I didn’t know before. Let’s see!
This was definitely interesting. After reading through all these chapters which were based on GoF I changed my opinion a bit. I see the usefulness of some of the patterns however I still think that they are overhyped.
After all this exposure I want to see the other side. I mentioned that I read Norvig’s take on it. I also read Paul Graham’s take on it who basically says that either the programming language, an interpreter you write or yourself take care of ‘compiling’. In the case of design patterns it is obviously yourself.
Another criticism comes from M.J. Dominus. What’s interesting is that he talks about Alexander’s book A Pattern Language.
The most important insight from his book is that the pattern language, I quote:
- does not tell you how to design anything
- It helps you decide what should be designed
That’s a big difference. Sadly, the author doesn’t provide ideas himself on this. But this also gives me the possibility to let my imagination run wild.
I haven’t read A Pattern Language but just looking at Amazon gives me a good idea. Here’s something from a review:
Alexander and his co-authors present us with over two hundred (roughly 250) “patterns” that they believe must be present in order for an environment to be pleasing, comfortable, or in their words, “alive.” The patterns start at the most general level — the first pattern, “Independent Regions,” describes the ideal political entity, while another of my favorite patterns, “Mosaic of Subcultures,” described the proper distribution of different groups within a city. The patterns gradually become more specific — you’ll read arguments about how universities should relate to the community, the proper placement of parks, the role of cafes in a city’s life.
What immediately popped into my head were things like DRY (Don’t repeat yourself). Good names. Hiding complexity. Making the code easy to understand.
It basically boils down to defining the equivalent of pleasing, comfortable – “alive” software. There are multiple groups: users, coders, management, etc. If you really think about it, it comes down to needs and then trying to match them.
Somehow the phrase ‘Write for your audience’ came into my mind. I’ve never seen a book about programming mentioning it but I think it applies.
I also read some criticism which basically says that GoF is just applied SOLID. I knew the phrase but never looked into it.
S = Single responsibility principle. We talked about that
O = Open/closed principle: The basic idea is that a software entity is open for extension but closed for modification. Betrand Meyer even gone so far that when a class is completed there will be no new methods or functionality – only bug fixes.
L = Liskov substitution principle: I read about this. It basically says that if an object of type A then you can use any child of A instead of A.
I = Interface segregation principle: Pretty simple. An implementation shouldn’t depend on interface it doesn’t use.
D = Dependency inversion principle: Abstract so that you don’t have to care about low-level. Example: You want to copy some characters. Instead of just copying them, you first translate those characters to a higher-level entity, copy this, and translate them back.
Cool, the next chapter is about enterprise patterns. It’s based on the book I wanted to read let’s see how good the chapter is and then maybe I’m change my goal based on that.
Somehow I think that I should read the GoF myself. I experienced it before that source material gets changed over time and loses some of the details which are really important. Maybe, maybe.
The first pattern is called registry and is basically a Singleton you can set and get. Seeing how this registry is used for multiple variables all I can see it that it’s reimplements the variable management of PHP but without the GC.
I skimmed most the tons of code but I got a good idea of the patterns presented in this chapter. It’s definitely interesting, however, I don’t think I need to read the book right now. It’s more on the platform than the application side.
After finishing this book I my next few books won’t be on the topic relating to OOP or Design Patterns. I reactivated quite a lot these last few days of the stuff I learned in the past and I know that I need to practice it a bit to get back on track.
Getting down to some serious architecture is a more rewarding prospect than writing some glue to stitch together three or four existing components.
I don’t necessary agree. If I can solve the same problem using 3 existing components and some other guy writes everything from scratch then I’d say reusing is more rewarding. But I wrote about this a lot and I think I’m part of the minority of people who like to solve problems instead of writing code.
So there is PEAR (which I recognized from the past). PEAR2 which has the Pyrus installer and composer – which seems to be the new kid on the block and a bit like leninigen or pip.
PEAR seems to be some what deprecated or on its way to there.
The author recommends phpDocumentor which uses the JavaDoc comments to create a documentation. It also seems to be still updated.
From the screenshots in the book the functions looks pretty good. Even without writing any documentation you will get an overview over your classes, type hinting, etc.
This can be quite valuable if you’re new to a project and want to get an idea of its architecture.
The DocBlock is like in Java or C++ or whatever. Most important tags are:
@var for fields
@param and @return for functions
Also nice to have:
@uses which links to something and this links back
@example
Updated Goals (October 21st):
- Learn more about the PHP OOP and Design Patterns
- Learn the most important pitfalls
Learn the right and idiomatic way to do PHP development today- Learn about PHPUnit
- Learn about automated deployment / CI
- Learn about composer
- Learn about coding standards
- Learn about caching
- Learn a bit more about legacy systems and how to handle them
- Get an overview of the standard library (SPL)
- Learn about functional programming in PHP
- Learn Symfony2
- Learn a bit more about MySQL
- Write at least one web app using Symfony2 and its core components (templating, testing, forms, validation, security, caching, i18n)
- Learn the intricacies: how does the interpreter work, the OOP system, etc.
Progress status
Done
In Progress
- PHP Objects, Patterns, and Practice by Matt Zandstra [378 of 532 pages]
Webmentions
[…] I’m currently on page 378 in PHP Objects, Patterns, and Practice. Which covers branching with git. My goal is again just 50 pages which would be the chapter about git, PHPUnit and Phing. I also just published yesterday’s post. […]