Procedural to oop in php
•Als PPTX, PDF herunterladen•
0 gefällt mir•686 views
IDX Broker is a real estate data and web software company. Barrett Avery, Data Systems Lead at IDX, will talk about the change in programming philosophy our data team is currently going through. He’ll talk about where we’ve been, where we’re going and why. Other topics he’ll cover include S.O.L.I.D. programming methodology and the Laravel PHP framework, and the pros and cons of each when dealing with large amounts of data.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (13)
Ähnlich wie Procedural to oop in php
Ähnlich wie Procedural to oop in php (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Procedural to oop in php
- 1. Procedural to OOP in PHP Presented by Barrett Avery, Data Systems Lead @ IDX, LLC Antonio Ortega, Biz Dev @ IDX, LLC
- 3. What is IDX? We are a SaaS product that creates web tools based on aggregate real estate data.
- 4. And More Data Provided by a Multiple Listing Service: <xml><stuffs>asihe234ouawyd7suh</stuffs></ xml> And More Data Provided by a Multiple Listing Service: <xml><stuffs>asihe234ouawyd7suh</stuffs></xml> And More Data Provided by a Multiple Listing Service: <xml><stuffs>asihe234ouawyd7s uh</stuffs></xml>
- 5. Objective ● Where we were and where we are going. ● Some differences between Procedural and OOP ● Give some insights from what we have learned along the way. ● Quick dive into SOLID Principles ● Quick dive into the Laravel Framework
- 6. Procedural - Where we were Definition: Procedural Programming is a list or set of instructions telling a computer what to do step by step and how to perform from the first code to the second code. Source: Wikipedia.
- 7. Procedural Pros and Cons Pros: ● Quick to develop and implement. ● Easy to learn. ● Simple architecture and overall structure. ● Good for quick and simple applications. Cons: ● Difficult to scale for future needs. ● Does not lend itself well to test driven development (TDD). ● Usually is very flat in terms of design and structure. ● Not good for larger applications that will likely change over time. ● Maintaining can be very challenging.
- 8. OOP - Where we are Definition: Object Oriented Programming (OOP) is a programming language model organized around objects rather than "actions" and data rather than logic. Source: Wikipedia.
- 9. OOP Pros and Cons Pros: ● Much easier to scale for future needs and development. ● Good for larger more complex applications. ● Lends itself well to Test Driven Development (TDD). ● More dynamic and fluid in terms of the architecture and overall design. ● Maintainable. Cons: ● Can easily become very complicated in terms of design and architecture. ● Takes much longer to develop initially. ● More difficult to learn than Procedural.
- 10. Why did we switch to OOP? ● Scalability ● Testable ● Maintainable ● Follows a more modern methodology of programming (SOLID) ● Laravel
- 11. SOLID and Laravel - Quick Dive Covering a couple of key components we are using in our applications at IDX, SOLID principles and the Laravel framework.
- 12. SOLID OOP Principles Single Responsibility Open Closed Liskov substitution Interface segregation Dependency inversion
- 13. Laravel Framework ● Why we chose a framework? o Gives a base to build scalable applications o Consistency between projects o Training is much easier when you have a standard to base your application on ● Why we chose Laravel? o Open Source o Fully featured o Lends itself to TDD o Provides built in tools for utilizing SOLID principles o Good for front facing as well as backend applications. o Good documentation and the framework is being actively developed.
- 15. Thank you and happy coding!
Hinweis der Redaktion
- Antonio’s Intro might go here?
- Antonio slide.
- We used to have a relatively flat structure that involved a few global classes that were huge (7 - 8K lines long) along with several other smaller classes that made up our core system. Class inheritance and “require” statements were as OOP as we were. This made for a lot of challenges in terms of maintaining the code base as well as growing the application for new features as well as bug fixes, etc. Most of our classes were top-down structure, with a few classes that could be overloaded by other classes, but still pretty flat all and all.
- Whereas Procedural can be great for your simple 10 - 30 page websites, it starts becoming very difficult to scale beyond that point. Maintaining the codebase is one of the biggest challenges, mainly because if you house most of your methods in a single file - that file becomes cumbersome and difficult to find where anything is in all that code. Especially if the coding style is different between developers, which it usually is. Procedural does not impose good coding practices that help keep your code clean and easy to read. In fact PHP allows for some pretty bad habits in this regard. Without good coding standards, Procedural code can quickly become a nightmare to look at when you have multiple different ways of coding the same thing put into a single application.
- After PHP 5.3 we have been able to leverage namespaces, which have really brought PHP into the OOP realm. And it’s only getting better with 5.5, 5.6 and seeing what the future holds with PHP 7. We initially started looking into pre-done frameworks to help standardize our codebase, one thing led to another and Laravel became the one we chose. During the learning of Laravel we started looking into design patterns as well as other OOP mythologies to help us developer our applications better, more scalable and easier for future developers to come on board and catch on quickly. In order to beat our competition, we had to rethink a lot of things. Our Acquisition system was one of them. And so while learning these new methodologies and technologies we began designing and building. We are currently nearing the end of Phase 1 in a complete rebuild from scratch of our data acquisition system. Using SOLID principles, true OOP and using the Laravel Framework as it’s base. We are also employing Test Driven Development (TDD) via a couple different testing suites (PHPSpec and Codeception). This allows us to build a robust system that is much easier to maintain, is scalable and allows for easy development and implementation of new features as they are needed. The project has been a great learning experience for us as developers and has forced us to shift our thinking away from the traditional way of coding, to a more SOLID way of coding. ON top of this we will be moving away from MySQL as our main-stay DBMS to Couchbase, as NoSQL DBMS. We are also using ElasticSearch for our search intensive tasks of the millions of real estate listings we pull from the 600+ Multiple Listing Services (MLS’s) throughout the US and Canada. This project also allowed us to implement good coding practices that make the code understandable and consistent across the application. Clean code helps maintainability after the project is complete.
- Expand on the need for our application to be scalable, so we can more rapidly add new features to our already feature rich platform.
- Give some numbers on the amount of data we are getting, normalizing and whatnot.
- Intro slide to SOLID and Laravel
- Single Responsibility: Each class should have a single responsibility or focus, this is very different from the several thousand lined classes or helper scripts we used to write in Procedural code. - Allowing for many smaller classes to do what a mammoth classes would have done. This makes for much more maintainable code. - Open Closed: Software entities (class, methods, functions) should be Open for extending but Closed for modification - Allowing the behavior of the class to be extended to other classes without modifying the source code of the class. - Uncle Bob: Separate extensible behavior behind an Interface, and flip the dependencies. Liskov substitution: Liskov's notion of a behavioral subtype defines a notion of substitutability for mutable objects; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program. - Derived classes must be substitutable for their base classes. Any implementation of an abstraction or interface should be substitutable anywhere the abstr - action is accepted. The gotcha here is when you implement a class from an interface that you are adhereing to the contract of the interface. Meaning if it expects the return value to be an array, all classes that implement the interface, need to return an array. Type-hinting in the doc blocks help remind us about this rule. Interface segregation: Meaning no client should be forced to depend on methods it does not use. So rather than having one massive interface in which many classes are dependant on, create many smaller interfaces so the classes can only know, or be concerned about, the methods in which they will use, rather than all of them. - It all comes down to the responsibility a given class has in regards to its dependencies. Many smaller interfaces rather than fewer larger interfaces. Dependency inversion: High-level modules should not depend on low-level modules, both should depend on abstractions. And abstractions should not depend on details, but details should depend on abstractions. This is where decoupling of modules comes into play. A good example would be decoupling of database tasks, as to easily switch from one DBMS to another. - Interfaces and their implementation classes.
- Laravel Framework – going over the framework, some of the features it has such as artisan, blade templates, eloquent ORM, etc.
- Thank you and now for Q & A and overall discussion of the materials covered.