Jojo's OO Design Project Log
m |
|||
| (2 intermediate revisions by one user not shown) | |||
| Line 22: | Line 22: | ||
* ...OH NOOO, Why this has to happen in my design study's space: It's...not an alien, it's [[Parallel hierarchies problem]]!!! The smell of [[Parallel inheritance hierarchies smell]] is really strong in here!! Oh Gawwd NO!! | * ...OH NOOO, Why this has to happen in my design study's space: It's...not an alien, it's [[Parallel hierarchies problem]]!!! The smell of [[Parallel inheritance hierarchies smell]] is really strong in here!! Oh Gawwd NO!! | ||
| − | == Scrap the old | + | == Scrap the old stuff, and makes way for the new == |
| − | My original plan was to work as much as possible with what Alexey's had done. However, the more I tried to work with with Alexey's design (as I tried adding classes and making changes), the more it feels like its original design choke what I want to do. I had spent my time discovering bugs and fixing | + | My original plan was to work as much as possible with what Alexey's had done. However, the more I tried to work with with Alexey's design (as I tried adding classes and making changes), the more it feels like its original design choke what I want to do. I had spent my time discovering bugs and fixing them. |
| − | So I decided to scrap everything that Alexey had done and started fresh from the start, starting small, pretty and simple...Just doing what | + | Furthermore, there are many cases where interfaces (IViewer, IPainter, etc) are limiting my freedom. All of my changes have to obey the contracts imposed by those interfaces. Now, the dilemma is, if I do change those interfaces, I have to change many things within the code even to the point of changing tiny that are not related ([[Shotgun surgery smell]]). So pretty much, the system is pretty tightly coupled in a "design way", it is slick, tight but not flexible at the same time. To be honest, there are so many functionality that are not required in fulfilling my honours project that it has became for me a bother for me to make also think of them as I go along. |
| + | |||
| + | So I decided to scrap everything that Alexey had done and started fresh from the start, starting small, pretty and simple...Just doing what I want, though it was a decision made pretty late. From now on, I will see Alexey's code as a guide. There are design decisions that I like about his Espresso, so I will pick it up and incorporate it in my design. If I did not like it, I did not pick it up. Much of it have a lot to do with the classes in the Controller layers. | ||
Latest revision as of 03:08, 1 October 2008
Alexey Blinov's Original Design
The image below shows the by Alexey Blinov, A Cosc Honours 2007 student, which also did this course. He came up with this final design at the end of the course. To say the least, it is really good design, well-packed with good design principle and design patterns. However, the design was bound to the software requirement which has now changed.
My task is to improve his designs based on the new requirements. Come to think of it, his design has some bottleneck that is not flexible (ie. not open to extension and modifications).
- Why it needs improvements?
- Why I choose this study?
- What are the bottlenecks?
Design Enlightenment. Starts. Here.
Events of Design Decisions (To Be Expanded & its language made formalized if needed):
- The very first thing I had to face with as I opened the lid of my design study box was Shotgun surgery smell just exploding right in front of my face and stained my clothes. Not good. Not good. But well, due to time constraints I chose to work with work with the current design as much as possible rather than blast it to pieces (Is this decision will make or break my honours project?)
- model view controller: controller knows about everyone...but everyone only knows about controller?
- Changed the 'Model' of my model view controller: Added DocumentFragment class.
- Added the ViewerControllers: DocumentViewerController & DocumentFragmentViewerController
- Added, ViewStrategy: SingleViewStrategy & MultipleViewStrategy, but...
- ...OH NOOO, Why this has to happen in my design study's space: It's...not an alien, it's Parallel hierarchies problem!!! The smell of Parallel inheritance hierarchies smell is really strong in here!! Oh Gawwd NO!!
Scrap the old stuff, and makes way for the new
My original plan was to work as much as possible with what Alexey's had done. However, the more I tried to work with with Alexey's design (as I tried adding classes and making changes), the more it feels like its original design choke what I want to do. I had spent my time discovering bugs and fixing them.
Furthermore, there are many cases where interfaces (IViewer, IPainter, etc) are limiting my freedom. All of my changes have to obey the contracts imposed by those interfaces. Now, the dilemma is, if I do change those interfaces, I have to change many things within the code even to the point of changing tiny that are not related (Shotgun surgery smell). So pretty much, the system is pretty tightly coupled in a "design way", it is slick, tight but not flexible at the same time. To be honest, there are so many functionality that are not required in fulfilling my honours project that it has became for me a bother for me to make also think of them as I go along.
So I decided to scrap everything that Alexey had done and started fresh from the start, starting small, pretty and simple...Just doing what I want, though it was a decision made pretty late. From now on, I will see Alexey's code as a guide. There are design decisions that I like about his Espresso, so I will pick it up and incorporate it in my design. If I did not like it, I did not pick it up. Much of it have a lot to do with the classes in the Controller layers.
