Web Development – How to Organize a Site’s File System Properly

The big reason why css is seldom generated dynamically (this is also true for javascript) is because they are good candidates for caching. CSS is a very flexible way to style your pages, with the right combination of classes, you can get all of the different parts of all of your different pages styled according to all sorts of cues all Without having to condition any of it in the CSS itself on what actually happens to be present on this pageview.

Simply because CSS doesn't need to be different per page leads to a very common practice of optimizing the cost of downloading it. Most sites cram all of the css for their whole site into a single download, so that parts that would apply to different page-views are present in only one downloaded file. With caching, your clients don't have to wait for it to download a second time. Maybe more importantly, you, as a content provider, don't have to pay the cost of uploading the content more than once; and you can even put the static css on a server that is better suited serving static content, which frees resources for actual dynamic content on your application servers.

This practice is so common, that many browsers just assume that the css is static; and are very reluctant to download CSS they already have; even if the users reloads the page. This special treatment applies only to CSS; other content types get reloaded as expected.

I wonder why the author did not use an Interface to represent the abstract type FileSystemElement? Isn't using an interface for this type correct?

It would be correct, in so far as a valid UML model, as would be using an abstract base class. The design decision depends on other factors, quite often tied to implementation language.

But an interface cannot have a abstract attribute, so I have to repeat name attribute in both Directory and File classes. Is there any better workaround for this problem?

An interface can have attributes, and they are assumed to be abstract. How these abstract attributes are translated to real code will use different idioms for each different implementation language, and often different idioms between different users of the same implementation language. At the UML level, it's not a restriction at all.

As we know, files and directories must have names with similar constraint (e.g. maximum length of 256 characters). Therefore, it would be nice if I model this in the FileSystemElement.

There is no reason why you cannot put a UML constraint on an attribute of the interface. { Name.Length <= 256 } can be put on an attribute owned by an interface just as well as you would an attribute owned by any other classifier. How it would get implemented will differ both in the implementation language and in implementation strategy - perhaps you have a validate function which takes an instance of the interface, asks it for the name and tests the length. Translating UML constraints to code doesn't necessarily follow the 'throw an exception if you try to call the getter' pattern, though it often does.

It is possible that the author of the OOSE book had some implementation strategy in mind, and therefore uses a concrete class. Quite what I'd do depends on what else the classes are for - for example, if they are just placeholders for path fragments, and rely on something else to create a stream which opens the file, they you can test them completely without having an interface to mock, so I'd not bother with the extra layer of abstraction. If they had direct operations to return streams or perform other file system operations, I may well use an interface so they can be mocked for testing. Neither is correct, and which is a better fit for the requirements can't be determined from two very small UML diagrams.

A quick scan through the OOSE book you link to confirms that it is talking about class diagrams much in the same terms as you would ER-Diagrams and considering representing relationships between nouns, not what the objects do. I would caution that if you are considering nouns in static relationship then you are talking procedural rather object oriented code - perhaps that is why you are finding that the model presented in the book is concentrating on concrete types with attributes rather than an interface of operations. Or perhaps it is just trying to demonstrate different types of associations and it's not worth looking too deeply at it!