CS 3354 Midterm

throw

The "throw" keyword is used to throw an exception.

Be able to describe the Model View Controller (MVC) architectural style and its benefits

The architecture components of the MVC pattern are designed to handle different aspects of an application in development. The MVC design pattern serves to separate the presentation layer from the business logic. Why do developers care about MVC? MVC is popular in app and web development, and it's one of the most widely used software design patterns for app and web development. The Model View Controller design pattern separates concerns into one of 3 buckets: Model View Controller

model-driven development

A software development approach that uses models to capture application logic during the development of end-to end enterprise applications Forrester's Definition: "An iterative approach to software development where models are the source of program execution with or without code generation." MDD Objectives Raise the level of abstraction for application development Reduce development time and improve application quality Reduce maintenance cost and Total Cost of Ownership of enterprise applications

Be able to describe 3 most common OO principles (inheritance, encapsulation, polymorphism) and their benefits and downsides

Abstraction One of the most fundamental concept of OOPs is Abstraction. Abstraction is a process where you show only "relevant" data and "hide" unnecessary details of an object from the user. For example, when you login to your Amazon account online, you enter your user_id and password and press login, what happens when you press login, how the input data sent to amazon server, how it gets verified is all abstracted away from the you. Another example of abstraction: A car in itself is a well-defined object, which is composed of several other smaller objects like a gearing system, steering mechanism, engine, which are again have their own subsystems. But for humans car is a one single object, which can be managed by the help of its subsystems, even if their inner details are unknown. Encapsulation This post provides the theoretical explanation of Encapsulation with real-life examples. For detailed explanation on this topic with java programs refer encapsulation in java with example. Encapsulation is: Binding the data with the code that manipulates it. It keeps the data and the code safe from external interference Looking at the example of a power steering mechanism of a car. Power steering of a car is a complex system, which internally have lots of components tightly coupled together, they work synchronously to turn the car in the desired direction. It even controls the power delivered by the engine to the steering wheel. But to the external world there is only one interface is available and rest of the complexity is hidden. Moreover, the steering unit in itself is complete and independent. It does not affect the functioning of any other mechanism. Similarly, same concept of encapsulation can be applied to code. Encapsulated code should have following characteristics: Everyone knows how to access it. Can be easily used regardless of implementation details. There shouldn't any side effects of the code, to the rest of the application. The idea of encapsulation is to keep classes separated and prevent them from having tightly coupled with each other. A example of encapsulation is the class of java.util.Hashtable. User only knows that he can store data in the form of key/value pair in a Hashtable and that he can retrieve that data in the various ways. But the actual implementation like, how and where this data is actually stored, is hidden from the user. User can simply use Hashtable wherever he wants to store Key/Value pairs without bothering about its implementation. Inheritance This post provides the theoretical explanation of inheritance with real-life examples. For detailed explanation on this topic with java programs refer inheritance with examples and types of inheritance in java. Inheritance is the mechanism by which an object acquires the some/all properties of another object. It supports the concept of hierarchical classification. For example: Car is a four wheeler vehicle so assume that we have a class FourWheeler and a sub class of it named Car. Here Car acquires the properties of a class FourWheeler. Other classifications could be a jeep, tempo, van etc. FourWheeler defines a class of vehicles that have four wheels, and specific range of engine power, load carrying capacity etc. Car (termed as a sub-class) acquires these properties from FourWheeler, and has some specific properties, which are different from other classifications of FourWheeler, such as luxury, comfort, shape, size, usage etc. A car can have further classification such as an open car, small car, big car etc, which will acquire the properties from both Four Wheeler and Car, but will still have some specific properties. This way the level of hierarchy can be extended to any level. Java Swing and Awt classes represent best examples for inheritance. Polymorphism This post provides the theoretical explanation of polymorphism with real-life examples. For detailed explanation on this topic with java programs refer polymorphism in java and runtime & compile time polymorphism. Polymorphism means to process objects differently based on their data type. In other words it means, one method with multiple implementation, for a certain class of action. And which implementation to be used is decided at runtime depending upon the situation (i.e., data type of the object) This can be implemented by designing a generic interface, which provides generic methods for a certain class of action and there can be multiple classes, which provides the implementation of these generic methods. Lets us look at same example of a car. A car have a gear transmission system. It has four front gears and one backward gear. When the engine is accelerated then depending upon which gear is engaged different amount power and movement is delivered to the car. The action is same applying gear but based on the type of gear the action behaves differently or you can say that it shows many forms (polymorphism means many forms) Polymorphism could be static and dynamic both. Method Overloading is static polymorphism while, Method overriding is dynamic polymorphism. Overloading in simple words means more than one method having the same method name that behaves differently based on the arguments passed while calling the method. This called static because, which method to be invoked is decided at the time of compilation Overriding means a derived class is implementing a method of its super class. The call to overriden method is resolved at runtime, thus called runtime polymorphism

Controller

Brains of the application. The controller connects the model and view. The controller converts inputs from the view to demands to retrieve/update data in the model. The controller receives input from view, uses logic to translate the input to a demand for the model, the model grabs the data, the controller passes data from the model back to the view for the user to see in a nice display.

exception

Dictionary Meaning: Exception is an abnormal condition. In Java, an exception is an event that disrupts the normal flow of the program. It is an object which is thrown at runtime

Know various software and OO notions (object, class, interface, type)

Encapsulation There are two important aspects of encapsulation: Access restriction - preventing one object from accessing another's internal state, for example. Namespaces/scopes - allowing the same name to have different meanings in different contexts. Encapsulation mechanisms are essential for reducing couplings between software components. Many encapsulation mechanisms originated with non-object-oriented languages. Object-oriented languages add additional encapsulation mechanisms. Inheritance There are two types of inheritance in OOLs interface inheritance and implementation inheritance. Interface inheritance is only necessary in typed OOLs. This is best understood when considering delegation-based design patterns. Implementation inheritance mechanisms depend on the type of OOL. For class-based OOLs, classes inherit from classes. For classless OOLs, objects inherit from objects. Polymorphism Polymorphism refers to the ability of different objects to respond to the same message in different ways. Polymorphism is essential for modeling our world including our social environment. We frequently use the same phrases and sentences to mean different things in different contexts. Often there is an abstract sameness, but concrete differences. For example, say the following sentence to two different architects and you will likely get two houses: "Build me a house". Abstractly, both architects will do the same thing but many of the details will differ. In early structured design methodology there were three principle types of control or data structure elements: sequence, alteration, and repetition. Polymorphism is often used as an alternative to alternation. Polymorphism is implemented with a dispatch mechanism. This mechanism may only be dependent on the object that receives a message or it may also be dependent on message parameters.

What is Exception Handling

Exception Handling is a mechanism to handle runtime errors such as ClassNotFoundException, IOException, SQLException, RemoteException, etc.

View

Graphical User Interface The view is a visual representation of the data- like a chart, diagram, table, form. The view contains all functionality that directly interacts with the user - like clicking a button, or an enter event.

Be able to explain what OO programming means

Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code: data in the form of fields (often known as attributes or properties), and code, in the form of procedures (often known as methods).

Be able to describe SOLID principles

Single responsibility principle (SRP): This principle states that software component (function, class or module) should focus on one unique tasks (have only one responsibility). Open/closed principle (OCP): This principle states that software entities should be designed with the application growth (new code) in mind (be open to extension), but the application growth should require the smaller amount of changes to the existing code as possible (be closed for modification). Liskov substitution principle (LSP): This principle states that we should be able to replace a class in a program with another class as long as both classes implement the same interface. After replacing the class no other changes should be required and the program should continue to work as it did originally. Interface segregation principle (ISP): This principle states that we should split interfaces which are very large (general-purpose interfaces) into smaller and more specific ones (many client-specific interfaces) so that clients will only have to know about the methods that are of interest to them. Dependency inversion principle (DIP): This principle states that entities should depend on abstractions (interfaces) as opposed to depend on concretion (classes).

catch

The "catch" block is used to handle the exception. It must be preceded by try block which means we can't use catch block alone. It can be followed by finally block later.

finally

The "finally" block is used to execute the important code of the program. It is executed whether an exception is handled or not.

throws

The "throws" keyword is used to declare exceptions. It doesn't throw an exception. It specifies that there may occur an exception in the method. It is always used with method signature.

try

The "try" keyword is used to specify a block where we should place exception code. The try block must be followed by either catch or finally. It means, we can't use try block alone.

Benefits of MVC

Traditionally used for Graphical user interfaces (GUIs) Popular in web applications MVC responsibilities are divided between the client & server, compatible with web application architecture MVC is helpful design pattern when planning development Separation of Concerns: that code is divided based on function to either the model, view, or controller bucket Works well with Ruby on Rails Loosely Coupled Removes unnecessary dependencies Reuseable without modification MVC makes model classes reusable without modification Code reuse Extendable code High Cohesion Easier to maintain or modify Supports Multiple views Each part can be tested independently (Model, view, controller)

- Know the Law of Demeter for object oriented systems

he Law of Demeter was originally formulated as a style rule for designing object-oriented systems. "Only talk to your immediate friends" is the motto. The style rule was discovered at Northeastern University in the fall of 1987 by Ian Holland. A more general formulation of the Law of Demeter is: Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Or: Each unit should only talk to its friends; Don't talk to strangers. In this general form, the LoD is a more specific case of the Low Coupling Principle well-known in software engineering. The Low Coupling Principle is very general and we tried to make it more specific. The benefit of the specific Law of Demeter shown below is that it makes the notion of unnecessary coupling very explicit. The main motivation for the Law of Demeter is to control information overload; we can only keep a limited set of items in short-term memory and it is easier to keep them in memory if they are closely related. The definition of "closely related" is intentionally left vague so that it can be adapted to particular circumstances. In the application of LoD to object-oriented design and programming we have:unit = method fclosely related = methods of class of this/self of f and other argument classes of f and methods of immediate part classes (both computed and stored) of class of f (classes that are return types of methods of class of this/self (= computed) and the classes of data members (= stored)) and methods of classes of objects that are created in f. The above is the class form of the Law of Demeter which has the advantage of being efficiently computable. However, it is the Object Form of the Law of Demeter which expresses the style rule we really want. Unfortunately, whether a program satisfies the object form is undecidable. However, we can run the program and check at run-time whether violations occur (this is a nice exercise in Aspect-Oriented Programming). Rumbaugh summarizes the Law of Demeter as: A method should have limited knowledge of an object model. This view leads to aspect-oriented programming: we pull out the method and transitively all its auxiliary methods into a separate aspect. This works best if the separate aspect has limited knowledge about the object model. The Law of Demeter and narrow and wide interfaces (initiated by Mitch Wand 2003, invited talk at ICFP 2003):At the method level, the LoD leads to narrow interfaces because each method needs to know about a small set of methods of closely related objects. On the other hand, at the class level, the LoD leads to wide interfaces because the LoD requires that we introduce many auxiliary methods instead of digging directly into the object structures. Wide interfaces for classes are a problem and the solution is an aspect-oriented approach where the behavior of the method is specified as an aspect at a high level of abstraction. We still have wide interfaces but we manage them through a language that specifies implementations.

website for exception handling

https://www.javatpoint.com/exception-handling-in-java

create a state diagram

https://www.youtube.com/watch?v=L9UCsQxuWmw

Model

stores & manages data. Often a database, in our quick example we'll use local web storage on a browser to illustrate the concept.