Timeline for Design pattern for similar classes that require different implementations
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 12, 2019 at 8:02 | comment | added | pstatix | @Ewan I understand how extensible your solution is, I guess I was looking for something that didn't require the users to instantiate two classes (the writer and visualizer) just to create a file. Was hoping to abstract it enough that a user could simply create a writer for a file format while simultaneously specifying what internal visualizer to use via method abstractions (i.e. insert() operates the same and doesnt matter if you set shape='hex' or shape='rect'; that is abstracted from the user, all they know is the file type will be binary hexagons or rectangles). | |
| Jan 12, 2019 at 7:58 | comment | added | Ewan | @datta that library writes files in a single specific format. You have two possible formats. Go write it the way I suggest and you will see why it is better. | |
| Jan 12, 2019 at 7:52 | comment | added | pstatix | @Ewan For example, pyshp/github (a library similar to mine) has a Writer class that allows you to set the data type (point, polygon, line, etc.) it is going to write and does all the checking. But here, it seems you're suggesting that I should do all the operations outside of the writer. This would, in my case, mean the only method a writer class would have is save(). | |
| Jan 12, 2019 at 5:28 | comment | added | pstatix | @Ewan I'm having trouble grasping why composition is no good here. | |
| Jan 12, 2019 at 4:13 | comment | added | Ewan | my answer remains unchanged after your edit. Do not link the two objects. | |
| Jan 12, 2019 at 0:29 | comment | added | pstatix | @MihaiComan So yes, files contain serialized representations of the visualizer shapes. However, they are only displayed when loaded into an application. This aligns more with Ewan, but I don't understand why I wouldn't want to bind a visualizer class as an attribute of a writer (e.g. composition) to facilitate the writing of the file based upon appropriate geometric operations for that visualization type. | |
| Jan 12, 2019 at 0:26 | comment | added | pstatix | @Ewan I've updated my post. I want to expand upon your comment of "the whole point is to separate the reading data and the displaying data". First, I don't intend to have any reading from file operations; its all one way generation at this time, so writer classes only. Second, the visualizer classes will not display the data, they only contain methods to determine appropriate geometric attributes that would be given to the writer class to determine where in file to write and what to write. | |
| Jan 12, 2019 at 0:12 | comment | added | pstatix | @Ewan You are correct, each file would represent only a single visualization (a binary file containing formatted data as a grid of triangles or an XML file of a grid of hexagons). As I mentioned to Mihai, the visualizer classes are used to determine how a writer class would add data to the file; they aren't used to actually visualize the data but instead facilitate the creation of the file. | |
| Jan 12, 2019 at 0:07 | comment | added | pstatix | @MihaiComan Each file type contains the data for display in its respective application. For example, a binary file that whats to display data as triangles would contain data IAW the file specification for a grid of triangles. The visualizer classes would never be called to "display" (i.e. no visualizer.display(data) exists). Instead, a visualizer class is simply used to determine certain operations before a writer class would write to file. For example, a binary writer that has a grid of triangles would use a Triangles object to determine which part of the grid writer.insert(point_data). | |
| Jan 11, 2019 at 10:20 | comment | added | Mihai Coman | I was assuming the file contains the data that needs to be visualised, I think @Ewan is assuming the file contains the serialized visualisation object. So, yes, I would agree that choosing the approach depends on what the file contents and visualisations are, specifically. | |
| Jan 11, 2019 at 10:17 | comment | added | Ewan | @Mihai's answer is the same thing. I have assumed that a file on disk can only be a single visualisation. but if its just the data you can load into any visualisation you should follow their pattern with the extra data object | |
| Jan 11, 2019 at 10:15 | comment | added | Ewan | the whole point is to separate the reading data and the displaying data. You dont want to couple the two things into a single object and have to add all the visualiser methods to your reader object. Thats the problem you have now | |
| Jan 11, 2019 at 10:12 | comment | added | pstatix | I'll have to add that detail later, but why not? Don't I need it to use composition? For example, writer = binaryFileWriter(shape='hex'). Now the writer.visualizer is a Hexagons() object. That what I call call writer.add(1, 2) and it calls the self.visualizer to update it accordingly. Some confusion may be coming from the fact that Hexagons() isnt just a single hexagon shape, but rather a grid. | |
| Jan 11, 2019 at 10:08 | comment | added | Ewan | It would be helpful if you expanded your question with more information on exactly what these classes are supposed to do. But no, you do not want to have a self.visualiser property. | |
| Jan 11, 2019 at 10:05 | comment | added | pstatix | Returning becomes somewhat problematic, and I will need to think on it. And perhaps not with a reader, but a binaryFileWriter may have a self.visualizer = Hexagons(). Thats valid composition right? I'm afraid I havent used composition intentionally before. | |
| Jan 11, 2019 at 10:03 | history | edited | Ewan | CC BY-SA 4.0 | added 1 character in body |
| Jan 11, 2019 at 10:02 | comment | added | Ewan | Yeah, No inheritance in my example and you really should be returning an object and not tacking the visualiser onto the file reader | |
| Jan 11, 2019 at 9:57 | comment | added | pstatix | Still chewing on this idea. In the meantime, does this use composition? It clearly doesnt use inheritance. For example, a binaryFileReader object may take a filename as an parameter at construction, and its self.visualizer might be a Hexagon object. Given what I intend to do, I don't plan to return an object like you've shown here after reading, but thats alterable to my case quite easily. | |
| Jan 11, 2019 at 8:18 | history | answered | Ewan | CC BY-SA 4.0 |