OOP turning functionally built code into modularized code

These notes were created while working with the following project:

https://github.com/SharinaS/bitmap-transformer

Code review from java-401d6 on Sept 20, 2019: https://frontrowviews.com/Home/Event/Play/5d76a964bdb9b10d0cb5cd59

These are steps for converting functional code into OOP with modularity

Note, it is perfectly fine to start with functionally built code. As in, you have starting code that runs as you expect it to.

Steps

1. Create a class where the instances come from (makes a new file)

Look at main (public static void main(String[] args) throws IOException {})

Consider where files should come from. Either grab that from args or have it as a string.

Goal is to use that file to fill in data in some bitmap instance. Goal is to create a class so we can create individual bitmap objects that know all the data to be that bitmap, and be able to do things for the program. In other words, create a bitmap instance that uses a file's data.

Note that when we define a class we define our desired datatype.

Can create a bitmap instance and then use option-enter (on mac) to have IntelliJ provide the option to create a class file.

2. Map out the organization within the class

Organization within the class:

• // instance variables
• // constructor
• // instance methods
• // class variables and methods can go either at the very top or very bottom

3. Make a constructor within the class

(it will be empty for a moment)

4. Create instance method(s)

To call a method like convertToGrayscale on a file, like a bitmap, we have to define a convertToGrayScale instance method in the class, such as BitMap. So, in the BitMap class, we need to have a convertToGrayScale method if we want to be able to call it.

In other words, to call a method on a class instance over in main, we have to define a class instance method in the class file.

Name appropriately, after thinking about if the method needs to return anything or just do something, like transform a bitmap (in which case it will be a public void).

If an instance method takes in a string, as planned out in the main method, make sure to add into the name that it takes in a string

public void write(String fileNameToWriteTo) {}

static

Anything that does not have the word static is an instance method.

Things that have the word static are class methods

5. Flesh out the instance variables in main

At this point the code is probably compiling just fine. It's just not doing anything.

Examine the app file.

If the goal is to access pieces of a file or an image, the instance variable we most want, in the case of a bitmap, is the buffered image. In the class file, that's where one bitmap instance stores its image data.

With having each bitmap instance storing its image data, if we create one bitmap that read in from one picture, and another bitmap that reads in from another image, each instance would have their own pixel data.

6. Return to the constructor

Note that a constructor's goal is to fill in instance variables.

In the constructor, fill in the pixel data (in the case of the BitMap example) with an actual image.

Go to the app file, where the code is already written, from when the code was written functionally way back when. Copy in code that involves accessing the pixel data. This is where we connect the instance variable we've defined to the code that does something.

If we have a File f = new File(path-for-file) that we copy-pasted over into the constructor, we need to take into account that we don't want to have that path-for-file for every BitMap. Change that path-for-file to match the variable used in the BitMap's parameter.

#7. Return to the instance methods Fill in with the code that was written in app.java, that was written functionally. Put each code block in the appropriate instance method.

Do appropriate problem solving to get code to work now that it's been moved. Remember to let IntelliJ fill in with smart suggestions as you make changes.