Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
CSE 332S Lab Design
This lab will build upon studios 16-21. You should complete all studios before starting the lab.
Throughout studios 16-21 and continuing into lab 5, you will build a software simulation of a file system, some simple file types that may be stored in a file system, and a user interface similar to a command prompt or terminal that allows a user to interact with the file system and files it contains. Throughout the design and implementation of the file system, OOP design principles and patterns learned throughout the semester will be used to ensure the file system is easy to extend with new functionality in the future, easy to modify without major code refactoring, and easy to configure with different functionality as needed. Here is a quick overview of what you have done in studio already:
This studio separates the task of creating files from the file system object. A file system should simply be responsible for storing and managing access to files, not creating them.
A new object, a file factory, will be responsible for creating files instead. The abstract factory pattern is used to support extensibility and flexibility in our design. The AbstractFileFactory interface declares an interface for creating files and concrete file factory objects define that interface to handle the creation of objects of different concrete file types. The abstract factory pattern provides extensibility by making it easy to create new concrete file factory classes (as in studio 20). Each concrete file factory may enforce restrictions on what types of files it can create, or can vary how the files are actually created. The pattern supports flexibility as a client that creates files using the AbstractFileFactory interface may be configured with any concrete factory class that inherits from AbstractFileFactory. This allows us to easily configure a client to change what types of files it may create or how those files are created.
This studio introduces the visitor pattern. The visitor pattern allows us to add new functionality to an existing set of related classes, where each concrete class may require a different implementation. For instance, a file may be displayed in different ways.
Maybe we want to display the bytes contained in the file directly, without any special formatting; maybe we want to display metadata about the file only; or, maybe we want to display the file in a format specific to that concrete file type. Rather than adding a virtual member function to the AbstractFile interface for each of these display methods (such as readBytes(), readMetadata(), readFormatted()) and overriding those methods in an appropriate way in each derived file class, we can instead use the visitor pattern to accomplish this without cluttering the AbstractFile interface. After completion, you will now have a couple of concrete visitors. One prints the contents of a file in a format specific to that file type, the other displays the metadata of the file.
Touch is a command that creates a new file and adds the file to the file system.
What you will implement in lab 5: For lab 5, you will be creating a few additional commands to increase the functionality of the program. The commands you will modify or implement are listed below, you will find further details on the specification and requirements of each command later in this document. In lab 5, you will:
And finally, the details…
Modify, or create and implement the following commands as described below. All commands you add should be ConcreteCommand objects as part of the command pattern. You should name your classes exactly as they are typed below when highlighted in blue. Header and source files for your classes should already be created and linked in the solution.
Note: You should not:
Command objects should not need to understand the types of files they are interacting with.
Doing any of the above will result in deductions.