Does any aspect of web development include oop - oop

I have been given a programming project. One of the criteria for being marked is
"Complex user-defined use of objectorientated
programming (OOP) model,
eg classes, inheritance, composition,
polymorphism, interfaces"
I am thinking of building "a website with dynamic content driven by a database back end". However, I don't see where I could incorporate OOP into a website. Is it possible to do so? Should i just switch to making an app instead?

If you implement your web site based on Java (Java EE or Spring Boot), C#, Pyhon, the of course you will have to do with OOP.

If you are planning to do a backend and a database ,you are most likely to use PHP and PDO/mysql/ respectively. And in OOP PHP you are definitely going to get what you are looking for like creating clases and as such. For example take a look at the example below taken from a PHP 5 manual:
<?php
class Foo {
public $aMemberVar = 'aMemberVar Member Variable';
public $aFuncName = 'aMemberFunc';
function aMemberFunc() {
print 'Inside `aMemberFunc()`';
}
}
$foo = new Foo;
?>

To make it easy you'll prefer to rely on MEAN stack ,
MEAN is a framework for an easy starting point with MongoDB, Node.js, Express, and AngularJS based applications ,
Because AngularJS depends on OOP and you can mange your database by using MongoDB
but if you want builld just website python is good chosen and it is OOP

Related

Software design pattern for branching logic?

In the context of test automation I'm using a simple version of the Page Object Pattern and facing the problem of having redundance in my code.
That said, in a class I'm having multiple methods which basically do the same thing but just return different page objects:
class Checkout {
gotoNextPageExpectCreditCardPage() {
clickSubmitButton();
return new CreditCardPage();
};
gotoNextPageExpectPaypalPage() {
clickSubmitButton();
return new PaypalPage();
};
...
gotoNextPageExpectErrorPage() {
clickSubmitButton();
return new ErrorPage();
};
}
I've done some research and thought of some design patterns like State Pattern, Template Method, Chain-of-responsibility, but am also thinking these might be overkill and that I'll have to do a huge refactoring.
Does anyone come up with a simpler solution?
PS.: I'm using node.js
PageObjectModel has its pros and cons, as any other pattern. Maybe you need to consider again what is your case and why you are using it. In most tutorials you will find, it is very easy and simple to implement, but those solve and demonstrate toy problems, not real life ones. I use POM only where the test framework API supports it by design, for example pywinauto. The concepts here allows you to chain your elements like so:
app.UntitledNotepad.Edit
And there is no point of repeating such screen structure all over your codebase, just put the UI details in a POM and provide the element when an interaction is needed.
notepad.EditInput.type_keys("pywinauto Works!", with_spaces = True)
As you can see - this is very far away, from Selenium and Web automation. But,
there are plenty of other patterns you can look for:
Object repository is very helpful when it comes to UI test scripts maintainability, I have used it in numerous big projects with great success (e.g. mSOA platform with more than 40 web sites)
Screenplay is a user-centred model, which helps you shift the focus of automated acceptance tests from low-level interactions with the system to thinking about who the users of your system are, what is that they want to achieve by their interaction with your system and how exactly they're going to do it.
Mission helps you modularise your code and create personas which describe business or functional interactions of software users.
Aiming at full answer - a good collection of other patterns in the xUnit world is the xunitpatterns. However, there is not a single pattern solution for your test framework you are building. One should follow and use other design principles and concepts as well. For example, your domain logic (business specific) should be layered in a DSL, having no knowledge of underlying drivers or higher level BDD specifications.

What does the Elm "stack" look like for a full application/site?

I'm trying to get an initial understanding of what a full Elm application looks like. In particular what the "stack" looks like. As a concrete example, let's say I have a website that allows users to register/login and then upload pictures and comment on others' pictures and comments. It delivers HTML, JavaScript, and CSS, and uses PHP and/or Perl on the server, The PHP/Perl interacts with MySQL or Oracle. If I were to re-develop this site with Elm, what parts does Elm handle and what are the common/recommended choices for the rest of the stack?
Elm handles the frontend responsibilities. You can use it instead of javascript and use its libraries to generate the needed html & css.
For backend you can use whatever technology you want. Since Elm is a functional language, some people chose a functional language for the backend too. Most frequent I've seen are Elixir (Phoenix Framework) and Haskell.
Take a look at Tour of an Open-Source Elm SPA for a real world example of implementing an Elm frontend for an already available backend.
Elm is purely the front-end, so you won't need any php to create html code.
It provides broad coverage of standard HTML, but excludes service workers and some other modern web APIs - you can use javascript through Elm's foreign function interface (called Ports).
Elm has out of the box support for json from a REST environment, and powerful parsers if you need to use something else (e.g. xml). As Peter suggest, you might want to use a functional backend, but there is absolutely no necessity (I've Elixir and Node with success to date).

3 tier architecture in objective-c

I just finished reading the objective-c developer handbook from apple. So I pretty much know everything that there is to know about objective-c (hee hee). I was wondering how do I go about designing a 3-tier application in objective-c. The 3-tiers being a front-end application in Cocoa, a middle-tier in pure objective-c and a back-end (data access also in objective-c and mysql db).
I'm not really interested in discussing why I'd need a 3-tier architecture, I'd like to narrow the discussion to the 'how'.
For example, can I have 3 separate x-code projects one for each tier? If so how would I link the projects together. In java, I can export each tier as a jar file and form the proper associations.
Thanks!
I think I figured out how to do this...use a static library for the middle and back-end tier use a Cocoa app for the front end.

Design Patterns Used in CakePHP

My Question:What are some good examples of design patterns used in CakePHP?
Why Use CakePHP As My Context
I've been using CakePHP for about a year so I think it's easier for me to think in that context. CakePHP is also rich in design pattern use (I'm confident of that)--I just don't know what patterns are being used other than a few obvious ones.
Example Books I've been Reading On the Subject:
I'm reading the following books which all cover design patterns to one extent or another; unfortunately they mostly use Java and C++ code examples which makes it harder for me to get a grip on the design patterns on a practical level (I'm a PHP developer so its hard for me to absorb it):
"Patterns of Enterprise Application Architecture", by Martin Fowler
"Head First Design Patterns", by Gang of Four (Eric Freeman, Elisabeth Freeman, Kathy Sierra & Bert Bates) (2004)
"Design Patterns: Elements of Resuable Object Oriented Software)", by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides)
Examples of Patterns I Can Observe in CakePHP
-I'm guessing the config file uses something akin to the factory pattern
-maybe $this->params is using something related to the observer pattern? I'm not sure on that...
-MVC (obvious! since Cake PHP uses the MVC file structure)
-ORM (another very obvious one)
-Maybe the HTML helper is using the decorator pattern?
Summary
I don't expect anyone to go down the line and identify all the patterns used in CakePHP--I'm just looking for a few examples of design patterns that should be obvious that I'm missing.
One that comes to mind is the concept of mixins. Not exactly a pattern but actually a language feature available in some languages (ie. modules in Ruby) but not in others (ie. Java). It will be coming to PHP when 5.4 goes stable and we get traits, but CakePHP's model behaviours are a good example of mimicking this kind of multiple inheritance where it normally isn't possible.
class Post extends AppModel { // we can only inherit from one class
public $actsAs = array('This', 'That', 'Other'); // but we can do this instead
}
Software design patterns (like a RoR):
Convention over configuration: all configuration files from Configure
Model-View-Controller: folders: Model, Controller, View, etc
ActiveRecord, Association Data Mapping: database mapping
Front Controller: main entry point (index.php)
Found in the comments:
Creational patterns:
Singleton -- find by "getInstance, singleton"
Factory -- find by "factory"
Builder -- find by "builder"
Structural patterns:
Adapter -- find by "adapter"
Front controller (.htaccess, include)
Behavioral patterns:
Strategy -- find by "strategy"
View:
Two-step-view pattern -- "two-step-view"

Where to start learning about Seaside internals?

I've become pretty enamored of the Seaside web framework lately. I'd like to start digging into the source to figure out how it works. Unfortunately, there are a lot of classes and I don't know where to start! Does anyone know what classes I should try to understand first? I assume that there's a routing class somewhere that I should start with...
Stephan gives good suggestions. Basically, if you understand the Seaside-Core package in Seaside 3.x, you understand how everything fits together:
The Canvas stuff is all a specific implementation of WARenderer from the Seaside-Core-Rendering category
The Session/Application stuff is all a specific implementation of WARequestHandler from the Seaside-Core-RequestHandling category
The Component/Task stuff is all an implementation of WAPainter from the Seaside-Core-Presenters category
There are really two ways of approaching studying the framework. Either start with one of the specific things you are interested in (say WAComponent) and work your way up the superclasses. Then repeat with each of the other classes Stephan mentions.
I'd suggest the other way: starting with the three sets of abstract classes I mentioned in Session-Core. Looking at them together (combined with the HTTP and Document classes) will give you an idea of the generic concepts and how they plug together to form the framework. You can look at each of the specific implementations as needed to relate the generic concepts to the actual implementation.
Subclasses of WAServerAdaptor form the starting point of request handling in Seaside, where a request from a specific web framework is converted into a Seaside request and dispatched to an appropriate handler. Callbacks are also pretty important and are in Seaside-Core-Callbacks.
If you understand everything in Seaside-Core, you basically understand how the framework works at a high level. Once you have a broad understanding of the basic core concepts, you can then proceed to get a deep understanding of each area that interests you by examining the concrete implementations in more detail. But keep in mind that everything in Seaside-Core is intended to be subclasses and plugged together to extend the framework.
I assume you have read the Seaside-Book?:
http://book.seaside.st/book
If you want to go deeper just look at the source, starting with the classes WAComponent and WARenderCanvas+WAHtmlCanvas. The routing class is WAAdmin in the sense as "this is the place where different Seaside-apps are registered".
There are several parts that are interesting. Start from WARenderCanvas to understand how the html generating dsl is build. WAComponent is the starting point for the composite page structure with call: and answer:. WAApplication represents a Seaside application, WASession a session, WAServerAdapter connects the Seaside framework to a http server and WARequestHandler handles http requests. The Grease package handles differences between Smalltalk dialects.
You are using the different browsers (class and hierarchy), class commments and senders and implementors, aren't you?