1 / 49

Procedural vs. Object-Oriented Design.

Procedural vs. Object-Oriented Design. What is Design?. Scientists design experiments that validate or invalidate theory. Engineers design solutions to problems. design is a plan. A plan never survives the first encounter with the enemy. Design is:. An iterative process (many plans).

nola
Download Presentation

Procedural vs. Object-Oriented Design.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Procedural vs. Object-Oriented Design.

  2. What is Design? • Scientists design experiments that validate or invalidate theory. • Engineers design solutions to problems. • design is a plan. • A plan never survives the first encounter with the enemy.

  3. Design is: • An iterative process (many plans). • Converging process (the design improves). • Design involves modeling and analysis. • Design requires a good problem statement.

  4. What is a procedure? • plan of action. • a list of actions that may contain conditions.

  5. What is Procedural Design? • The creation of plans. • Listing out conditional actions. • Sketching out multiple blueprints. • Deriving several levels of detail for a software project.

  6. Procedural Design is: • All of these things, and MORE! • Start with Problem statement • This drives the process. • step-wise refinement of the problem more and more detail is used to define a solution. Getting more detail for the problem. Refining the problem specification.

  7. Procedures follow from the spec. • Procedures are actions that are taken given some situation on some data or device. • Recipes are procedural elements that give direction. • Cooking run the recipe procedure using ingredients and cooking utensils.

  8. Cooking ideas • Recipe is an algorithm... • Ingredients are data structures. • Utensils are like the subroutines

  9. What is Object Oriented Design? • Uses procedural design and add encapsulation. • Encapsulation controls complexity. • It limits the interface that the outside world sees in the system.

  10. Object Oriented Cooking Design • Roles are assigned to different Objects in the system. • The waitron role is to deliver the rolls. • The waitron role is to take the orders and deliver them to the kitchen. • The kitchen cooks the meals and tolls the bell!

  11. Service the interrupt • Waitron services the bell interrupt by getting the meal and taking to the proper table. • A clear division of labor and assignment of roles, this leads to limit of knowledge about the different implementations of the roles.

  12. Object Oriented Design • Still needs procedural design • Now needs an interface between objects with a clearly defined role. • Enables a reduction of fragility in the system. • Why?

  13. The interface is the protocol • Well defined • Stable • Public • It enables reuse of the subsystems. • Interchangeable parts use the same interface!

  14. Component Software Development • Software Engineering has been criticized for the lack of software reuse! • Procedural design had reuse using subroutines and functions. • Large tool kits were the only means of software reuse.

  15. Interfaces enable Component Connections • Suppose I had a standard for gun barrels • subcontract the creation • mass produce guns • interchangeable parts.

  16. Frameworks • Frameworks use standard interfaces to make use of a large set of related classes to solve a problem. • Example: • public interface Runnable { • public void run(); • }

  17. If you program to the interface you can: • Thread t = new Thread(r); //r is runnable • public interface ImageProcessInterface { • public Image process(Image img); • }

  18. Functional Design • f(a,b,c,e,f,g); • drawString(x,y, “hello world”); • Function design requires that you know the parameters, their order and their meaning. • So data structures were created: • f(ds), drawString(graphicObject);

  19. Functional Design • Characterized by an input and • Perhaps some output. • Use it on data structures. • A kind of Procedural Design

  20. Object Oriented Design • Functions and data structures resides in the objects. • Interfaces are used to communicate outside of the system. • If the interfaces are made simpler than the system then you have facade design pattern.

  21. Facade Design Pattern • Object Oriented Design Pattern • Used to simplify the interface to the system. • Example: bell and order in the restaurant. • Example: gas, brake and steering. • A standard interface to a car -> I know how to drive all standard cars!

  22. Interfaces are not flexible! • Both good and bad • Good because: leads to standards....all AC outlets are the same. • Bad because: not all interfaces serve all applications. • A plane is different from a car. • I need to learn how to fly a plane!

  23. How do I change from one interface to another? • The Adapter design pattern allows one interface to be changed into another. • USA uses 120 VAC in two prongs. • EU uses 220 VAC with different shaped prongs. • An adapters converts between the two.

  24. What is an Object Oriented Design Pattern? • A design pattern is a recurring solution to a well understood problem in object oriented design. • Design patterns have names. • Design patterns formalize the object oriented designs so that they can be reused. • They represent the maturation of SWE.

  25. Design Patterns are Good because... • Nomenclature (i.e., jargon) • Every mature discipline has a jargon. • Well understood vocabulary of communication. • DP’s enable efficient communication about OOD’s. • They enable reuse of OODs.

  26. Design Patterns change the way we THINK about design. • Language is a tool. • DP improve the language tool and this alters how we thing about solving problems. • There are lots of design patterns!

  27. Singleton Design Pattern • Pattern to have when you are only having one! • Singleton design pattern controls the total number of instances in a system. • Only one instance can be created! • This instance is unique.

  28. Why do I need singleton design pattern? • For example: trademark like DocJava • The PTO makes sure there is no duplication of a trademark. It uniquely identifies a business or product or service. • Only one trademark can be issued for this purpose.

  29. Programming is different from design! final class SingletonExample { private static SingletonExample se = new SingletonExample(); private SingletonExample () {} public static SingletonExample getExample() { return se; } }

  30. OOD vs Proc Design • You can’t do singleton DP in • FORTRAN • Pascal • COBOL • VB You need an OO language for this!

  31. A new era? • When did OOP start? • Popularized by Simula (1967). • Design patterns are newer (1995)! • The best way to learn design patterns is by using them. • Just in time design patterns (introduce DP’s as they are needed).

  32. Patterns • Pattern Concept • Why use patterns? • What patterns did we use? • Flat-files to DBMS transitions

  33. Pattern Concept • A Design Pattern is solution to a recurrent problem. • A Design Pattern has: • Pattern Name – new vocabulary • A problem that is solved: • Context • Given • Constraints

  34. What is a Pattern... • A solution that is solved: • Context • Given • Constraints • The consequences of use: • trade-offs • costs • comparison to other patterns

  35. Why use Patterns? • Permit more abstract thinking • Improved communication • Greater code reuse • Improved reliability • Easier maintenance

  36. What Patterns did we use? • The Singleton Pattern • Large systems can have multiple instances • Want to make sure that only once instance is made • Want class to be responsible for making a single instance • Example: The Hub public class Hub { private Hub() {} private static Hub hub = new Hub(); public static Hub getHub() { return hub; }

  37. Observer Pattern • Observer Pattern • Problem: How do we propagate change events? • used to notify instances about changes • keeps a complex environment consistent • methods called for side effect • Before: • No clean separation between the GUI and the logic • No indication of the inputs and outputs • No indication of the order in which calls had to be made • Drawback: • need to centralize the relationships or too many updates

  38. The Mediator Pattern • The Mediator centralizes the observer pattern • Promotes loose coupling • no explicit referral • Like Ethernet wiring hub • Elementary API: • addObserver • update • setChanged

  39. Mediator Example private Materialdb mdb = Materialdb.getMaterialdb(); private static SSFrameData ssFrameData = SSFrameData.getSSFrameData(); public void wireUpObservers() { mdb.addObserver(ssFrameData); ssFrameData.addObserver(ssFrame); propagateObserverMessages(); } private void propagateObserverMessages() { mdb.update(); ssFrameData.notifyObservers(); }

  40. Framework • Framework is: • set of cooperating classes • reusable design for specific class of software • NOT a design pattern • Problem: need a specific overall architecture • define responsibilites • segment the programming job • design for specific patterns • Drawback: • domain specific • not much code reuse for other problems.

  41. Toolkit design pattern • a collection of classes that provides a library of subroutines • Reusable code • can be used for functional programming • Can typically characterize a clean compute function: • Input variables • Output variables • Intermediate variables • Example: • y = Math.sin(x) • diagTenOut = DiagonalTension.compute(beamWeb);

  42. Polymorphic ToolKit • A toolkit with polymorphism • Requires general interface • Reuse of implementations • Good for • integration • plotting • function manipulation

  43. Polymorphic Toolkit • Example: Curve Plots public interface Computable { double compute(double x); double getMin(); // returns the min value allowed for x double getMax(); //returns the max value allowed for x }

  44. Composite Design Pattern • Composite Design • tree structure • treat objects uniformly • has-a relations • Problem • a single Frame with flat structure of components • textfields • labels • buttons • A Rivet Panel logically groups all GUI element for Rivets • Much easier to interact with, layout and reuse!

  45. Facade Design Pattern FDP - provides an interface to a subsystem • Need a clean API • Need a new notation for variables • For example: public double getStringerE() { return stringerE; } public void setStringerE(double d) { stringerE = d; setChanged(); // triggers local DBMS }

  46. The Proxy Pattern A Proxy is a place holder for another instance • Problem: Many DBMS calls cause communication The cached material database is a proxy • IO is threaded • can disk-based database • can change to network based DBMS • a surrogate for the dispatch of SQL commands.

  47. The Remote Proxy Pattern • RPP - Remote Surrogate • enables distribute computing • used by JINI and Java Spaces • Can be implemented with • RMI • CORBA • sockets • Calls non-Java network-based services

  48. Remote Proxy Example Shell wrappered FORTRAN URL u = new URL("http://www.computeserver.com/cgi-bin?23.2?22?..."); • very fast on intranetwork • Can incur network overhead • A VERY EASY SOLUTION!

  49. The Delegation Pattern DP-defers the implementation Problem: • Services are often duplicated • Must make changes in several places Solution: • Centralize the changes • isolate your code from the implementation Example: public Metse1 getMetse1() { // replace with singleton pattern return dtMetFrame.getMetse1(); }

More Related