In this edition…
- What Were You Thinking? => Bimonthly Newsletters
- On the Web => Security and Privacy Made Simpler
- On the Blog => My January 2012 Non-Resolutions List
- Q&A => How do you go about designing the main OOP classes for a project?
- Larry Ullman’s Book News => “Modern Javascript: Develop and Design” Done!
What Were You Thinking? => Bimonthly Newsletters
In the previous newsletter, I asked for input on the idea of changing the newsletter from going out every 3-4 weeks but being longer to going out every 2 weeks but being shorter. You were also able to vote in an online poll. About two-thirds of the votes were for the change, although the more passionate responses were against the change, as those recipients already felt they received too many newsletters and emails. I think what I’m going to do, as a happy medium, is to shoot for a schedule where the newsletters come out slightly faster, like every 2-3 weeks, and are slightly shorter. This should be feasible for me to pull off without overwhelming you.
Towards that end, you may note that there’s no “What is Larry Thinking?” section in this particular newsletter. With the new plan for the newsletter, I’m not going to be quite so rigid about what goes into each newsletter, limiting myself to just five or so significant pieces. The bulk of this newsletter answers a question on OOP design.
My thanks to everyone for their input. And please always feel free to provide any feedback, questions, comments, etc., that you may have. (Postscript: Several of you rightfully pointed out that I misused “biweekly” in the text of the newsletter, despite correctly using “bimonthly” in the heading. I indeed meant “bimonthly”, although “biweekly” has the same inexactitude in that it can mean both every two weeks and twice a week.)
On the Web => Security and Privacy Made Simpler
When I was writing my Effortless E-Commerce with PHP and MySQL book, I naturally did a bunch of research, particularly with regards to the various laws that apply. Understanding the programming behind an e-commerce site is relatively simple; understanding all the applicable laws and implications of doing e-commerce is complex. One of the sites I found to be quite useful was the United States Better Business Bureau (BBB).
I’m currently going through some items in my “to read” folder, and am reading, or perhaps re-reading, the Better Business Bureau’s PDF titled “Security & Privacy – Made Simpler. If you do any e-commerce, or even just Web development, in the U.S. or not, it’s worth your time. It’s a 22-page document that discusses almost every facet of e-commerce, such as:
- Developing a security and privacy plan
- Creating and communicating your security and privacy policies
- Good employee screening and policies
- Common hack/theft strategies
- General Internet security
- Proper handling of customer data
- Payment processing
- What to do in the event of a data breach
- A preview of international e-commerce considerations
The document also has many resources listed in these and other categories. You can download the PDF from that page, but there are also related FAQs and more on the BBB’s site.
On the Blog => My January 2012 Non-Resolutions List
I’ve never been much of a New Year’s Resolution person: if something is important enough to do, start today, not on some arbitrary date that happens to be the first day of the year. (Or, you know, January 2nd, because the first is a holiday and all.) But this year I happen to have quite a long non-resolutions list. The timing is entirely coincidental: I just happen to be done with my “Modern JavaScript: Develop and Design” book around this time, and I always have a long list of things to do between books. I recently posted on my blog about my immediate plans (aka, my non-resolutions list).
Q&A => How do you go about designing the main OOP classes for a project?
While “diving into” Object-Oriented Programming development in PHP, Chris had emailed me about how one sets up the core classes for an OOP-based site. The specific example—user management with login/logout, roles, etc.—is common and not complex, but Chris didn’t know where to start. In my opinion, OOP is easy enough to use once the classes have been defined; the difficulties arise from coming up with the proper classes in the first place. So let’s look at that process, in the abstract.
Programming is a matter of taking actions with data. In a linguistic sense, it’s very much a noun-verb relationship: the user submits form data to a server; the server stores data in a database; the user requests another page; the server pulls data from a database. Whether you’re using OOP or procedural code, you need to identify both the actions and the data first. What are all the verbs that the user or Web site needs to be able to do? What are all the nouns that will be involved in those actions? Once you’ve identified those attributes of the site, procedural programming focuses first on the verbs, OOP focuses first on the nouns.
To start designing OOP classes, one must first organize the types of data the site will work with, in detail. In a user management system, there’s one obvious noun: a User. The properties of a User include: userId, username, userPass, userRole, dateRegistered, and so forth. (Conventionally, OOP uses camel-case for variable and property names.) When you think you’ve identified the nouns involved, go back and see if all of the actions now have the data that needs to be involved. When a new person registers, a User is created (as both a PHP variable and a record in the database). When a person logs in, a User is retrieved from the database and created as a PHP variable. When a person logs out, the User PHP variable can be destroyed. To see if a person has authority to do X, you’d check the User->userRole property.
In some situations, there will be nouns with overlapping roles and properties, which would suggest that you should create a hierarchy of classes. I think of shapes as being the easiest example to comprehend. All two-dimensional shapes have some common attributes, such as area and perimeter, but triangles have three sides, rectangles have four, and circles have none (but do have a radius). When you find yourself in situations like this, you’ll want to design one master class, in this case, Shape, which you never create instances of. Then you define derived classes—Triangle, Rectangle, and Circle—that you would create instances of. Admittedly, knowing when to create a hierarchy can be tough. You might think with a user roles situation that you’d want common users and administrators as two separate classes, but the only difference between the two types is in what actions each can take, which is easily managed using Access Control Lists (ACLs) or the like. Or, put another way, everything about the two users is exactly the same except for the type, so there’s no need to create separate classes (unlike, by comparison, circles and triangles that have some overlapping properties but other very different ones).
Another common class to use on a site would be one for interacting with the database. You could create your own class for this purpose, or just use the MySQLi object or PDO or the like.
Even in a simple site with content and users, there are other clear nouns: the pages of content. Going back to the language analogy, there are some sentences that have a single noun—Johnny runs or A User logs out—but many have more than one noun—Johnny reads a book or A User views a page of content. The content, then, would also be represented by one or more classes, depending upon the variety in the content displayed. If the content is just information displayed within a template of HTML, then Content might have these attributes: contentId, title, body, createdBy, dateCreated, and dateUpdated. The createdBy could be as simple as a userID integer, or more formally be an actual User instance.
Depending upon how OOP-y you want to be, you may also create classes for generating the HTML pages (i.e., View classes) and for handling actions (i.e., Controller classes). Those move you into the realm of a true MVC architecture, which isn’t always necessary, though.
In asking the question, Chris didn’t originally know how to handle the logging in and logging out and registration and such, not knowing if one makes classes for those. Those are actions performed on, or using, objects, and don’t get represented as classes themselves.
Because I’m going to be writing the third edition of my “PHP 5 Advanced: Visual QuickPro Guide” this year, I expect I’ll be doing a lot of writing on the subject of OOP, design patterns, and the like. If anyone has any more questions or comments regarding these topics, let me know.
Larry Ullman’s Book News => “Modern Javascript: Develop and Design” Done!
I am very, very happy to say that my latest book, “Modern JavaScript: Develop and Design”, is officially done. Like done, done. Last week Monday, I submitted the last chapter to be written, Chapter 13, Frameworks. In it, I quickly discuss how to choose a framework, when you should use a framework, and some common libraries (as a framework alternative). The bulk of the chapter introduces and uses jQuery and the Yahoo! User Interface (YUI) Library. For both I explain how to perform common tasks—selecting DOM elements, DOM manipulation, event handling, and Ajax, and then walk through more advanced examples. For both, the chapter explains an autocomplete example, using a PHP script as the data source. For jQuery, I also discuss the DataTables plug-in. For YUI, I also discuss and demonstrate the Yahoo! Query Language (YQL). For it, I go through a couple of examples, including fetching a weather report and a stock quote. (For the record, I specifically target YUI3, which is an improvement over YUI1 and 2, even if some of the framework is currently in beta.)
Chapter 13 is the first chapter in Part 3 of the book, Next Steps. I already wrote Chapter 14, Advanced JavaScript, which has a heavy focus on closures. Chapter 15, A PHP and JavaScript Example, creates a pseudo-complete auction system. Auctions are set to expire on a certain date and time. Logged-in users can bid on items. All dates and times are shown using Coordinated Universal Time (UTC) or the user’s timezone, if the user is logged-in. Then, JavaScript used to enhance the experience. This includes using Ajax for the login and bid forms, retrieving the latest bids via Ajax (and updating the table of bids with them), and creating countdown timers that show the amount of time left in an auction, when that’s less than an hour. I think the chapter turned out well, and it emphasizes the various ways to pass data back and forth between PHP and JavaScript, a common point of confusion.
Not only is all of the initial writing is complete, but I’ve also done the rewrites on the entire book, and I just—moments ago—finished reviewing the PDF layouts, which is the last step before the book goes to the printer. (As you can tell, there are a lot of overlapping steps here at the end.) I believe the book will still ship, as originally planned, at the end of February.
In support of the book, I’ll also be writing a couple of articles (published online for free) and create some screencasts (to be provided in various places).
