MVC, Do I have to read all the previous chapters

[Costa lamona]

Hi
I am using Head First Design Patterns, I did not read a design pattern book before, but I read some tutorials about design patterns, and I read some MVC tutorials, However I had a bad time in my designing using MVC , I am telling my boss that this problem raise because we don't have a written requirment file, I have fack written requirment file which made to make un-techniqal people think that the system analyst did his job (in my openion, he did not, and he cannot do it, I am sure, I might be wrong!!!), but I am .

Ok, because I might be wrong I have to read MVC from a good resource
and I have to "run", so I want to jump into MVC section in chapter 12.

1- Do you think I had to read the rest of the book first??
2- if no, What chapters do you recomend before start read before MVC??
3- Do think it is a very bad idea to go into MVC directly??
4- Why I did not choose to be a doctor? or a Hitman??!!!
5- Can I kill the System Analyst? Which way you recommend?

Note that I don't want to wast my time in reading MVC and then All I got is mis-understanding. I prefer to not-understand than mis-understand

Any thoughts
Thanks

[Ilja Preuss]

You definitely should understand the Observer pattern before you dig into MVC. Some general understanding of patterns would certainly serve you well, too. I don't know the book, so I can't give more specific advice here...

As an aside, I don't understand at all what this has to do with the analyst or requirements - the usage of MVC typically is a purely technical decision, as far as I can tell...

[Costa lamona]

Originally posted by Ilja Preuss:

As an aside, I don't understand at all what this has to do with the analyst or requirements - the usage of MVC typically is a purely technical decision, as far as I can tell...

Thanks Ilja, The requirements determine what the application will do (at least its basic functionality) in very detailed way, if you put your design, then extra requirements appear this will lead to a need to change the design, especially in low level design (determine the API of each interface and class), for example in a Book Creation Application, I assumed that the View will handle the user actions in every page like change a font in a text, (and send any update to the model), while Controller will be responsible of determining which page will appear to the user now, the low level design is completed and Software specifications (How every thing works) is written, suddenly, I was told that page flow of one Book type is differ from another type, this information lead to x change to the design, after a while another piece of information appeared, it need y change, and because there was no really any kind of analysis and requirements, we need after one month to do a, b, c, d, e ,f , g, h, i, j and k changes, as a result program readability is destroyed and because a lot of changes and poor readability, you might face a lot of debugging problems, you cannot read it, you don't know where is the Controller and where is the Model, and where is the View, you cannot trace bugs, the project is not extensible (how you can extend thing you cannot understand how it works), we have to go for "though away prototyping software engineering Model" which is not acceptable for my company, there must be a good imagination for requirements written neatly on a piece of paper to avoid a lot of changes in the design.
For next versions, we should have another requirement file, and take a deep look to the design and decide, who will stay, and who should be re-created
Yes it has nothing to do with MVC except re-Creating MVC all over again.

Note that as I told you I am not sure if it is my design fault, or it is his fault, simply I have less than one year experience in professional Application development. But I am saying, simply If you don't know what exactly you should do, how you will do it??

Thanks

[Ilja Preuss]

Mohammed, if I understand correctly, you were hurt by the need to change the system, so you are trying to find a way to reduce the need for change in future systems.

I'd like to kindly suggest that there is a better way: building the next system so that it is easier to change. Important parts of that would be to learn how to refactor a system so that the design doesn't become worse and worse while you implement changes; to manage code dependencies so that changes don't ripple through the whole system; and to write an extensive suite of automated tests, so that you get immediate feedback when you break something.

The reason that this is, in my opinion, a superior strategy is simple: changing requirements are inevitable. A successful software system is one that gets used. And it will change the way the users do their job. So while using the system, they will find out other ways the system could even better support them doing their job, and they will naturally ask you to change the system so that it can do that. Another reason is that the environment a system is used in changes over time, so the system will have to adapt.

In my experience, if you want to be successful in the software world, you will have to learn how to effectively deal with changing requirements and how to use them to your advantage.

[Costa lamona]

Originally posted by Ilja Preuss:
Mohammed, if I understand correctly, you were hurt by the need to change the system, so you are trying to find a way to reduce the need for change in future systems.

I'd like to kindly suggest that there is a better way: building the next system so that it is easier to change. Important parts of that would be to learn how to refactor a system so that the design doesn't become worse and worse while you implement changes; to manage code dependencies so that changes don't ripple through the whole system; and to write an extensive suite of automated tests, so that you get immediate feedback when you break something.

Thanks again for the advice

I think you agree with me that one of the key targets of the software design art is the project extensibility, so that you have to expect where are the places you will need an update, and facilitate that update by isolating changeable things from those things that not likely to be changed, and that is why you should have a good vision to the whale system, thus we need to understand the system through requirements, What is the input?, what user should see? , and what is the output?, what is the system should provide to the user to customize program output?, changing requirements is not the problem, the problem is if there is no requirements, there is no correct vision to the system.

Furthermore, I think it is normal to update the requirements every time mangers decide that we will go for the next version, you cannot say after we start implementation "Sorry, this does not work, we have to update the design in places we did no expect a change, and with things that have nothing to do with the current system, simply it is new system!!", this will lead to what I was talking about.

But again the problem could be "I cannot create a good vision" even if the requirements file is well done. Because It is first time I involved in any thing "not tiny application"
I will tell you something funny, they decide to put me in C# group although there is a java group and I am SCJP5!!

[Ilja Preuss]

Originally posted by Mohammed EL-Adawi:
I think you agree with me that one of the key targets of the software design art is the project extensibility, so that you have to expect where are the places you will need an update, and facilitate that update by isolating changeable things from those things that not likely to be changed

In my experience, that is in fact part of software design, but probably the less important one (not unimportant, though).

The problem is that there will be unexpected changes - and even the changes you expected will call for a slightly different design than you originally anticipated.

So in my experience the much more important design skill is being able to change the existing design in a reliable way so that it is possible to incorporate unexpected changes without the design decaying. That skill is called "refactoring" - in my opinion, it's one of the most important skills an OO developer can acquire. See http://refactoring.com/

[Costa lamona]

Thank you Ilja

I beleive that I will learn that art over the time, Thank you for your guidance.

[Stan James]

isolating changeable things from those things that not likely to be changed

Or carried to an extreme: isolating all things from all others. Robert Martin has recast the Single Responsibility Principle from the old "a class does one thing well" to the more interesting "a class has only one reason to change." The other side of this coin is when something changes, you want to make the change in only one place.

That's not quite literally true of course. At some level of abstraction maybe only one class changes - say the one that fetches data from a particular source - but it may change to use a whole cloud of new objects for some new protocol. Still the impact to existing clients of this class is minimized or negated if the change can happen in one place, ideally behind an interface.

As Ilja says, spotting those places and building the right abstractions is a key skill, and a measure of design robustness and success over time.

[Ilja Preuss]

Originally posted by Stan James:

The other side of this coin is when something changes, you want to make the change in only one place.

The less well-known Single Choice Principle...

[Peer Reynders]

Originally posted by Mohammed EL-Adawi:
2 - if no, What chapters do you recomend before start read before MVC??

The HF MVC write up (Chapter 12: 499-576) clearly states that the MVC pattern is a compound pattern that uses the Strategy (Chapter 1: 1-35), Observer (Chapter 2: 37-78) and the Composite (Chapter 9: 316-381) pattern. One problem with skipping chapters is that you will be missing out on some Object Oriented Design Principles that are scattered throughout the book - and that you will have less practice in applying and understanding patterns in general.

Originally posted by Mohammed EL-Adawi:
3- Do think it is a very bad idea to go into MVC directly??

You haven't mentioned in which context you wish to apply the MVC. Personally I have always been a bit puzzled when this term is applied to web applications were you operate in an essentially connectionless environment, were everything is built up to serve a single request and then torn down after that request is served - only leaving an essential core of session data on either the server or the client. The practices used when referred to as the MVC pattern seem nothing more than judicious application of separation of concerns and other Object-Oriented Design Principles that only have a faint resemblance to the MVC pattern that originally emerged from the Smalltalk community.

If you are talking about MVC in the non-Web GUI context then you should know that the MVC has drawn a lot criticism over the years for its various shortcomings that have lead to various variants in an attempt to control its complexity. And if you are talking Swing then you already have to worry about two models - the Swing Model for the GUI and the "application" model that your application uses. This idea has been expanded by the HMVC which establishes a hierarchy of MVC triads.

Currently the Model-View-Presenter variant is often subject of discussion.
Robert C. Martin: Designing a User Interface in C# Using the Model View Presenter Design Pattern
Wikipedia: Presenter First
Presenter First: Organizing Complex GUI Applications for Test-Driven Development (PDF) from the Presenter First page
Supervising Presenter Passive View
Micheal Feathers: The Humble Dialog Box(PDF)

Ultimately I think it would be a mistake to skip any chapters as learning the Object Oriented Design Principles (OODP) is ultimately more important than the patterns themselves (a nice sideeffect though).

Your application will be the better for it - it will turn out better if you simply apply OODP rather than trying to force it into an MVC mold.

[Ilja Preuss]

Peer, very good points!

[Stan James]

And in the four days this has been going on, one could probably read the whole book.

[Peer Reynders]

Originally posted by Stan James:
And in the four days this has been going on, one could probably read the whole book.

I don't know, when I was reading, writing, speaking and thinking german (many years ago) my english reading speed wasn't all that hot ...

[Stan James]

The Ranch has been a positive influence on my cultural sensitivity but I have a ways to go, no? Sorry if that struck anyone the wrong way. I had a lysdexic friend (his word for it) who hated reading even with no language challenges; advice on what he could skip was valuable to him, too.

[Peer Reynders]

Originally posted by Stan James:
The Ranch has been a positive influence on my cultural sensitivity but I have a ways to go, no?

Wasn't meant as criticism. However quite frequently, with the pace of technology and developments and the huge body of information published in English (first), I often thank my lucky stars that I don�t have to break through an additional layer of language translation to get to the heart of the matter (which can be especially frustrating to native speakers of languages that tend to be more "precise" than English). It is much easier to "keep up" if you can digest information in the original language without further "indirection".