please fix the code you submitted to reflect the attached factory design pattern and the business layer.

 

 

The Factory Design Pattern
We end this topic with a design pattern for instantiating Service layer services, namely
the Factory design pattern. Our goal is that we would like to remove all references to the
service implementations. That is, the code that uses the service should only be aware of
the service interface, not the service implementation. For instance, consider once again
our Book service with the following interface and implementation names: IBookSvc BookSvcSerializedIOImpl
The above service could be used by instantiating it as shown below:
IBookSvc bookSvc = new BookSvcSerializedIOImpl();
The problem with the above statement is that the code is now coupled to the
implementation class of the service (i.e., BookSvcSerializedIOImpl). In particular, if we
decide to release a new implementation of the service based on a different technology, for
example BookSvcSocketImpl, we would have to locate all the instantiations of the
service and change the implementation name:
IBookSvc service = new BookSvcSocketImpl();
A better design would be to hide the implementation by providing a “creational” class
that knows how to instantiate (i.e., create) services. Such a class is characteristic of the
Factory design pattern. We’ll provide a simplified version of the Factory in this topic and
then expand on it in the next topic. For now, consider the following definition of a
Factory:
package services;
public class Factory {
public IBookSvc getBookSvc() {
return new BookSvcSerializedIOImpl();
}
… // additional methods for instantiating other services
}
The Factory allows the application to get a handle on a service by doing the following:
// use the Factory to get a service …
Factory factory = new Factory();
IBookSvc bookSvc = factory.getBookSvc();
Notice that the implementation class is not referenced in the above snippet; rather, the
reference to the service is limited to its interface IBookSvc. So now if we want to change
the implementation class (e.g., to BookSvcSocketImpl), all we have to do is change the
Factory:
public IBookSvc getBookSvc() {
return new BookSvcSocketImpl ();
} The above approach requires the Factory to have a separate method for each service,
which is not a good idea. We will improve this design in the next topic so that there is
only one method for all services.
Revisiting the Business Layer
Revisiting the Business Layer
Now that we understand what the Service layer is all about, let’s revisit the Business layer
to see how it gets implemented using services from the Service layer. We’ll start with the
notion of adding books to the Library and then re-examine the AuthenticationMgr that
was first discussed in Topic 4.
Add Books to the Library
To add books to the library, we need a Business layer manager that the Presentation layer
can use when a Librarian invokes the use case “Add book.” We choose to call the
component, BookMgr, with a method addBook(Book book) as shown below:
package business;
import services.*;
import domain.*;
public class BookMgr {
public Book addBook(Book book) throws Exception {
Factory factory = new Factory();
IBookSvc bookSvc = factory.getBookSvc();
return bookSvc.add(Book);
}
}
Notice what the manager does; the manager: Declares that it throws an exception (that may be thrown in the Service layer). Instantiates a Factory and gets a handle to an IBookSvc. Invokes the IBookSvc to add a Book to the library. Returns the results to the caller (the Presentation layer). Has no visibility to the underlying service implementation; i.e., the impl is not
referenced by the manager.
The above pattern is typical of Business layer managers. They invariably use one or
more services in the Service layer to get the required work done. Let’s look at one more
example: the authentication of users who are trying to login to the application.

Attachments:

• 1494228452-Wk2PrjV3.zip