In this article you'll find a basic example of this Java interface and it will introduce you to the use of the @Async Spring, EJB, annotation
You can find it at: Future interface basics
In this article you'll find a basic example of this Java interface and it will introduce you to the use of the @Async Spring, EJB, annotation
You can find it at: Future interface basics
You can find a whitepaper of blockchain's project Bletchley, with good definitions
This example tries to solve the following problem: We have a NxN checker. Every (i,j) case contains k points (in this example k=4). One entry point that is a point located into the case's boundary. Two points are inside the case and the last point is an exit point, also at the boundary (different from entry). The algorithm uses Branch & Bound technique to: given an initial case and an end case, compute the minimal cost path from init to end. It also uses visitor pattern to get results. Implementation needs to be finished in some points.
Main library: "pathfinder.h"
#ifndef PATHFINDER_H_INCLUDED #define PATHFINDER_H_INCLUDED #include "visitor.h" #include
Getting results (visitor pattern): "visitor.h"
#ifndef VISITOR_H_INCLUDED #define VISITOR_H_INCLUDED #include "pathfinder.h" #includeclass SolutionDisplay { public: SolutionDisplay(Solution * sol); ~SolutionDisplay(); virtual void print(); private: Solution * _solution; }; class Visitor { public: Visitor(); ~Visitor(); virtual void visit(Backtracking * b) virtual void printSolution(); virtual vector * getSolution(); virtual double getCost(); private: Solution * _solution; SolutionDisplay * _solutionDis; }; void Visitor::printSolution(){ this->_solutionDis = new SolutionDisplay(this->_solution); this->_solutionDis->print(); } class PathFinderVisitor: public Visitor { public: PathFinderVisitor(); ~PathFinderVisitor(); private: }; void PathFinderVisitor::visit(Backtracking * backtracking) { if(!backtracking->compute()) this->_solution = backtracking->getSolution(); } #endif // VISITOR_H_INCLUDED
Southwind C++ (codeblocks ide) project for GoF patterns practicing. It takes as example a possible template method from the trader company "Southwind" and the use of 2 different Strategies (Kanban and JustInTime).
Files in project:
#include#include "templatemethod.h" #include using namespace std; int main() { const static vector * catalog = {"Tablets offer", "SmartPhones offer", "Javas offer", "Androids offer", "Creatives offer"}; const static vector * locations = {"KanbanCity","JustInTimeCity"}; int status = -1; map > * tradingdata; Strategy * strategy = NULL; Context* context = NULL; TraderCompany* southwind = NULL; vector * preorder = createPreOrder(catalog); string* location = getLocation(locations); if(location->compare(locations->at(0))== 0)) /* we work with Kanban city */ strategy = new KanbanStrategy(); else strategy = new JustinStrategy(); context = new Context(strategy); southwind = new Southwind(context); /* call to the template method */ status = southwind->trade(preorder); tradingdata = southwind->getTraderdata(); return status; } vector * createPreOrder(vector * catalog) { vector * selecteds(-1,5); vector * preOrder ; vector ::iterator it = catalog->begin(); int i = 1; int j = 0; bool exit = false; cout << "Welcome to Southwind company please choose our offers : "; cout << endl << endl; cout << "Catalog :" << endl; while(it!= catalog->end()) { cout << "Number: " << i << " " << "Product: " << *it << " " << endl; it++; i++; } i = 100; cout << "Choose your offers : (input correct offer's number (1-" << catalog->size() << ") or 0 number for exit) " << endl; while(i!= 0 && !exit){ cout << "Offer's number: " << endl; cin >> i; if(i>0 && i< catalog->size()) selecteds->push_back( i--); else{ j++; cout << " Input number is incorrect (1-6)" << endl; i = 100; if(j==10){ cout << "Too many incorrect input, exiting..." << endl; exit = true; } } it = selecteds->begin(); while(it!= selecteds->end()){ preOrder->push_back( catalog[ *(it++)]); } return preOrder; } string * getLocation( vector * locations) { string * loc; vector ::iterator it = locations->begin(); int i = 1; int j = 0; int k = 0; cout << "Welcome to Southwind, this are the possible locations:"; cout << endl << endl; cout << "Location :" << endl; while(it!= locations->end()) { cout << "Number: " << i << " " << "Location : " << *it << " " << endl; it++; i++; } i = 100; cout << "Choose your location : (input correct location's number (1-" << locations->size() << ") or 0 number for exit) " << endl; while(i!= 0 && k>1){ cout<< "Location's number: " << endl; cin >> i; if(i>0 && i< locations->size()){ selecteds->push_back( i--); k++; } else{ j++; cout << " Input number is incorrect (1-" << localtions->size() << ")" << endl; i = 100; if(j==10){ cout << "Too many incorrect input, exiting..." << endl; exit = true; } } } it = selecteds->begin(); while(it!= selecteds->end()) *loc = locations[ *(it++)]); return loc; }
#ifndef TEMPLATEMETHOD_H_INCLUDED #define TEMPLATEMETHOD_H_INCLUDED #include#include #include "strategy.h" #include
#ifndef STRATEGY_H_INCLUDED #define STRATEGY_H_INCLUDED #include#include #include
A C++ (codeblocks ide) project for GoF patterns practicing.It can be extended with the rest of patterns (command, state, factory, mediator, etc...).
Files in project:
#include#include #include "chainofresp.h" #include "patternexec.h" using namespace std; const int CHAIN = 2; int main() { int sdirective = 2; PatternExec* _patterne = 0; string name ="CHAIN"; string conf = "1000"; switch(sdirective){ case CHAIN: _patterne = new PatternExec(new ChainOfResp(name,conf)); break; default: return -100; } int r = _patterne->execute(); if(!r) cout << "Program ended correctly" << endl; return r; }
#ifndef PATTERNEXEC_H_INCLUDED #define PATTERNEXEC_H_INCLUDED #include#include #include using namespace std; class Pattern { public: Pattern(); Pattern(string name, string conf); virtual int run(); private: string _name; string _conf; }; Pattern::Pattern() {} Pattern::Pattern(string name, string conf) { _name = name; _conf= conf; } int Pattern::run() { cout<< "Running an empty pattern " << endl; return 10; } class PatternExec { public: PatternExec(); PatternExec(Pattern* pattern); virtual int execute(); private: Pattern* _pattern; }; PatternExec::PatternExec(Pattern* p){ _pattern = p;} int PatternExec::execute() { return this->_pattern->run(); } class ChainOfResp: public Pattern { public: ChainOfResp(); ChainOfResp(string name, string conf); virtual int run(); void setConf(string conf); private: string _staticName = "CHAIN"; int _deep; }; ChainOfResp::ChainOfResp(){} ChainOfResp::ChainOfResp(string name, string conf){ if( _staticName != name) cout<<"Incorrect pattern Name" < setConf(conf); } void ChainOfResp::setConf(string conf) { if(conf == "1000") _deep = 1000; } /** Here is where pattern is applied The value _deep indicates the TOPIC value which determines which component will process the call */ int ChainOfResp::run(){ Widget* aButton; Widget* aField; Dialog* aConfirm; Application* anApp; anApp = new Application(0, (TOPIC) _deep); aConfirm = new Dialog(anApp, (TOPIC) _deep); aField = new Widget(aConfirm, (TOPIC) _deep); aButton = new Widget(aConfirm, (TOPIC) _deep); cout << "Launch ChainOfResp from Button" << endl; aButton->handle(); cout << "Launch CofResp from Field" << endl; aField->handle(); cout << _staticName << " Pattern ended correctly " << endl; return 0; } #endif // PATTERNEXEC_H_INCLUDED
#ifndef CHAINOFRESP_H_INCLUDED #define CHAINOFRESP_H_INCLUDED #include#include using namespace std; typedef int TOPIC; const TOPIC NO_VALUE = -1; class Handler { public: Handler(); Handler(Handler* sucessor,TOPIC topic); virtual int handle(); virtual int doProcess(); private: Handler* _sucessor; TOPIC _topic; const static TOPIC _myTopic = 0; }; Handler::Handler(){} Handler::Handler(Handler* sucessor, TOPIC topic){ _sucessor=sucessor; _topic = topic; } int Handler::handle() { cout<< "Handling from Handler class" << endl; if(_topic == _myTopic){ _sucessor->handle(); }else doProcess(); } int Handler::doProcess() { cout<< "Processing!!! from Handler class " << endl; } class Widget: public Handler { public: Widget(); Widget(Handler* widget, TOPIC topic); virtual int handle(); virtual int doProcess(); private: Handler* _parent; TOPIC _topic; const static TOPIC _myTopic = 1; }; Widget::Widget(){} Widget::Widget(Handler* w, TOPIC topic) { _parent = w; _topic = topic; } int Widget::handle(){ cout << "Hadling from Widget class " << endl; if(_topic == _myTopic){ _parent->handle(); }else doProcess(); } int Widget::doProcess() { cout << "Processing from Widget class " << endl; Handler::doProcess(); } class Dialog:public Handler{ public: Dialog(); Dialog(Handler* h, TOPIC t); virtual int handle(); virtual int doProcess(); private: Handler* _handler; TOPIC _topic; const static TOPIC _myTopic = 2; }; Dialog::Dialog(){} Dialog::Dialog(Handler* h, TOPIC t):Handler(h,t) { } class Application:public Handler { public: Application(); Application(Handler* h, TOPIC t); int handle(); int doProcess(); private: const Application* _app = this; const static TOPIC _myTopic = 1000; }; Application::Application(){} Application::Application(Handler* h, TOPIC t):Handler(h,t){} #endif // CHAINOFRESP_H_INCLUDED
As object-oriented techniques steadily gain ground in the world of software development. users and prospective users of these techniques are clamof object-oriented or more and more loudly for a “methodology” software construction - or at least for some methodological guidelines.
This article presents such guidelines, whose main goal is to help improve the reliability of software systems. Reliability is here defined as the combination of correctness and robustness or more prosaically, as the absence of bugs.
Everyone developing software systems. or just using them, knows how pressing
this question of reliability is in the current state of software engineering. Yet the
rapidly growing literature on object-oriented analysis, design, and programming
includes remarkably few contributions on how to make object-oriented software
more reliable. This is surprising and regrettable, since at least three reasons justify
devoting particular attention to reliability in the context of object-oriented development:
The cornerstone of object-oriented technology is reuse. For reusable components, which may be used in thousands of different applications, the potential
consequences of incorrect behavior are even more serious than for application specific developments.
Proponents of object-oriented methods make strong claims about their beneficial effect on software quality.
Reliabitity is certainly a central component of any reasonable definition of quality as applied to software.
*The object-oriented approach, based on the theory of abstract data types,
provides a particularly appropriate framework for discussing and enforcing
reliability.
Reliability is even more important in object-oriented programming than elsewhere. This article shows how to reduce bugs by building software
components on the basis of carefully designed contracts.
The pragmatic techniques presented in this article, while certainly not providing infallible ways to guarantee reliability, may help considerably toward this goal. They rely on the theory of design by contract. which underlies the design of the Eiffel analysis, design, and programming language’ and of the supporting libraries, from which a number of examples will be drawn.
The contributions of the work reported below include a coherent set of methodological principles helping to produce correct and robust software; a systematic approach to the delicate problem of how to deal with abnormal cases. leading to a simple and powerful exception-handling mechanism; and *a better understanding of inheritance and of the associated techniques (redeclaration, polymorphism, and dynamic binding) through the notion of subcontract, allowing a systematic approach to using these powerful but sometimes dangerous mechanisms.
Most of the concepts presented here have appeared elsewhere. They were previewed in the book “Object-Oriented Software Construction”; and a more complete exposition was presented in a recent book chapter,”from which this article has been adapted”. More profoundly, this work finds its root in earlier work on systematic program development and abstract data types. This article focuses on the central ideas, introducing them concisely for direct application by developers.