Advanced Guide to PHP on IBM i - Softcover

Schroeder, Kevin

Softcover

ISBN 10: 158347384X ISBN 13: 9781583473849

Verlag: MC PR LLC, 2014

Inhaltsangabe

Working through many of the concepts and skills needed by intermediate and advanced PHP developers, this book is specifically designed to help good PHP developers become indispensable ones. Topics include debugging, test-driven development, web-based development, advanced object-oriented programming, and web security, and the book also takes an in-depth look at the new PHP Toolkit for IBM i provided by Zend Technologies. Upon completion of this book, readers will be able to use its principles as a basis for architecting complex applications, building web services according to the best standards currently available, significantly reducing the time spent discovering and fixing errors in code, designing architectures that are testable and predictable, building secure applications by protecting against most known attacks, and avoiding and preparing for common performance issues.

Über diesen Titel

Über die Autorin bzw. den Autor

Kevin Schroeder is the technical manager for education and consulting for MagentoU and a former technical consultant for Zend Technologies. He is the author of You Want to Do What with PHP? and the coauthor of The IBM i Programmer&;s Guide to PHP. He lives in Frisco, Texas.

Auszug. © Genehmigter Nachdruck. Alle Rechte vorbehalten.

Advanced Guide to PHP on IBM i

By Kevin Schroeder

MC Press

Copyright © 2014 Kevin Schroeder
All rights reserved.

ISBN: 978-1-58347-384-9

Contents

Chapter 1: A Re-Introduction to Basic Concepts, 
Chapter 2: Design Patterns, 
Chapter 3: Standard PHP Library, 
Chapter 4: Debugging Basics, 
Chapter 5: Security, 
Chapter 6: Working with the Browser, 
Chapter 7: Test-Driven Development, 
Chapter 8: Web Service Basics, 
Chapter 9: Using the Toolkit, 
Chapter 10: Performance Considerations, 

CHAPTER 1

A Re-Introduction to Basic Concepts

We will start this section with a (very) quick re-introduction to the basic concepts of object-oriented programming (OOP).

Classes and Objects

When it comes to OOP, the most basic discernible concept is the class. The class is the foundation of everything that follows it. You cannot have an object without a class. An interface is largely pointless without a class. Abstract classes refuse to instantiate. Sometimes that class might simply be a definition that says an object of said type can exist, and other times it can be part of a much larger grouping of functionality.

As a general starting point, think about a class as the definition of a reference in an application to a real thing. Although, in practice, objects rarely are accurate representations of a thing, it is a good starting place for your understanding. It is much the same as in real life.

Consider from within the world of biology, which has many different taxonomic groups, such as Plants, Fungi, and Animals. You can break down these groups into even more distinct categories; for example, you can sort the Animal group into Fish, Birds, and Mammals, and then divide the Mammals group into yet more distinct categories like People, Dogs, and Kittens. These are examples of classes. They are definitions of what could be. An object is when you give form to that definition. You do not just have a person, but you have a "Kevin" or a "Bob." An individual can be likened to an object, whereas taxa can be likened to classes. It is the relationship of definition to instance.

When defining a class, you can define three general types of things: properties, methods, and constants. Let's look at an example that encapsulates about 80 percent of what you will be using when working with OOP:

[PROGRAM LISTING NOT REPRODUCIBLE IN ASCII]

Properties

Think of a property as a variable attached to an instance of a class. It will contain only data and no logic. In this case, you have two properties: $name and $breed.

Methods

Methods are the class version of a function. A method is basically a function that is tied to a class, and where you will implement any logic in the class.

In this example, you have two methods: setName() and setBreed(). The setBreed() method contains a little logic that allows only defined breeds to be set for the instance's $breed property. By setting the $breed property as private (we will look at what that means in a bit), you ensure that the only way to set that property is by calling the setBreed() method.

Constants

Classes can contain data that is consistent, or constant, across multiple instances of a class. This technique is often used as a means to introduce defined predictability. In the previous example, you would not be allowed to enter just any breed; instead, you must enter one that the class has defined as valid. And one of the easiest ways of doing that is by providing the constant name rather than a defined value.

The following code shows how you might be tempted to set a breed:

$macy = new Dog();
$macy -> setName('Macy');
$macy -> setBreed('Corgi');

But go back and look at how you defined the constant representing a Corgi. Notice the difference? The code example here uses an uppercase "c," whereas the class definition is all lower case. So by providing the string value, you might have accidentally introduced inconsistency into your data.

However, when you use the constant, you are saying, this dog is a Corgi, according to my definition. And by doing so, you reduce the risk of accidental mistypes on the keyboard and provide a much more predictable use case:

$macy = new Dog();
$macy -> setName('Macy');
$macy -> setBreed(Dog::BREED_CORGI);

Context

Context is the nature of our interaction with a definition. When you interact with static context, you are working with the class itself. Any logic can be executed from any class instance, can affect other instances, or might not be related to an instance of that class at all. To some degree, we can liken it to procedural functionality within a class structure. This is not entirely true, but it's accurate enough for a base definition. If working from within the object context, you are interacting not with the class, but with the instance of that class.

Two important keywords to know are self and $this. Because self refers to the class definition, it is somewhat global in its scope — not global like a global variable, but simply globally accessible. You can define the static context as a property (self::$breeds) or as a method (self::addBreed($breed)).

However, you can use the self keyword only when you are working within the class definition itself. If you are working within the global context or calling from within another class, you must specify the class name to call it:

Dog::addBreed('beagle');

When working in the object context, you generally use the keyword $this. It is a reserved variable name that simply refers to the current object instance. So if you have two instances of the Dog class — one for Macy and another for Sasha — calling setName() sets the property for the individual instance, which means that $this->name will have a different value depending on the instance of the object that you are working from within.

Visibility

When working in OOP, you have three levels of visibility: public, protected, and private, as Table 1.1 shows.

Abstract Classes

Sometimes a class can have some functionality defined in it, but not enough to let it instantiate. Or it has additional functionality that will diverge at further levels of taxonomic completeness. For example, fish can share certain commonalities such as fins, scales, and cold-bloodedness. But if you were to add gills to that list, you would be wrong. Some fish (called the lungfish) have lungs. So although you can define the Fish class to a certain extent, you cannot include the breathing mechanism because it can be completely different based on the type of fish.

Therefore, you need to define the Fish class as abstract and add functionality in later implementations:

[PROGRAM LISTING NOT REPRODUCIBLE IN ASCII]

Then when you later define Fish, you can include the breathing mechanism (e.g., gills for trout and lungs for lungfish).

Interface Definition

If classes are the definition of an instance, as "human" is to an individual, then interfaces are the expectations. But unlike classes, interfaces do not contain implementation details. That is because an object frequently needs only to know that something exists, not how it exists. And often that something might be an item that is not instantiated within the class itself but is injected from the outside. When that happens, the outside item might include a wild range of functionality that...

Details zur Ausgabe

• Verlag: MC PR LLC
• Erscheinungsdatum: 2014
• Sprache: Englisch
• ISBN 10: 158347384X
• ISBN 13: 9781583473849
• Einband: Taschenbuch
• Auflage: 1
• Anzahl der Seiten: 328
• Kontakt zum Hersteller: Nicht verfügbar
• Verantwortliche Person: Buchbär; info@buchbaer.de; ; Weberstr. 67; Osnabrück; 49084; Deutschland