{"id":22164,"date":"2023-02-22T07:18:43","date_gmt":"2023-02-22T07:18:43","guid":{"rendered":"https:\/\/www.booksofall.com\/?post_type=product&p=22164"},"modified":"2023-02-22T07:18:43","modified_gmt":"2023-02-22T07:18:43","slug":"building-skills-in-object-oriented-design","status":"publish","type":"product","link":"https:\/\/www.booksofall.com\/pt\/building-skills-in-object-oriented-design\/","title":{"rendered":"Building Skills in Object-Oriented Design"},"content":{"rendered":"

Why Read This Book?<\/h4>\n

The coffee-shop reason for reading this book is to provide the beginning designer with a sequence of interesting and moderately complex exercises in OO design.<\/p>\n

If that\u2019s all you needed to know, skip to the next chapter. It\u2019s okay. We don\u2019t mind.<\/p>\n

The Problem. Some software developers find themselves stalled when trying to do object-oriented (OO) design<\/a>. As programmers, they\u2019ve understood the syntax of a programming language, and pieced together small examples. However, it is often difficult to take the next step to become a designer. The transition from guided learning of language features to self-directed design work is often ignored. Programmers are left to struggle through their first design projects without appropriate skills or support.<\/p>\n

This may be you. You\u2019ve learned the language, but you can\u2019t take the next step.<\/p>\n

While it is critically important to read examples of good design, a finished product doesn\u2019t reveal the author\u2019s decision-making process that created the design. There\u2019s little support that helps a programmer come to understand the design process that leads to a final product.<\/p>\n

The most notable consequence of this skills gap is some n00b programmers will create of software that is far more complex than necessary to effectively solve a given problem. This, in turn, leads to software with high maintenance costs stemming from the low quality. It also leads to an unfair indictment of OO technology<\/a>; this is usually voiced as \u201cwe tried OO programming and it failed.\u201d<\/p>\n

Unrealistic Expectations<\/a>. As programming team leaders, educators and consultants, we find that software development training is focused on the programming tools, but does not expose the process of creating a design. We all start out building software designed by someone else. What\u2019s involved in design?<\/p>\n

In the building trades, we would neither expect nor allow apprentice plumbers to design the sanitary sewage system for an urban office building. Yet, in too many Information Technology (IT) departments<\/a>, software developers are expected to leap from basic training in their tools to application design.<\/p>\n

To continue this rant, we also find that some managers are entrusted with significant projects, but are uncomfortable with OO design on modern high-performance hardware. They tend to focus their design energies on the kinds of software architectures that were appropriate when the enterprise owned a single computer, when 64 megabytes of memory was all the enterprise would ever need, and centralized disk storage was charged back to end user departments at a rate of pennies per track per month. In some organizations, there are a few enduring symptoms of this mind set in some of the ways that \u201cend-user computing\u201d is separated from \u201centerprise computing\u201d; we relegate everything non-mainframe to second class status.<\/p>\n

Management discomfort with OO technology surfaces in many ways. One shocking comment was that \u201cno application needs more than six classes.\u201d A consequence of this management attitude is an unrealistic expectation for schedule and the evolution of the deliverables.<\/p>\n

Closing the Skills Gap. The deepeer answer on the intent of this book is to help you, the beginning designer, by giving you a sequence of interesting and moderately complex exercises in OO design. The exercises are not focused on a language, but on a design process. The exercises are not hypothetical, but must lead directly to working programs.<\/p>\n

The long answer is that this book will make you work.<\/p>\n

This book can also help managers develop a level of comfort with the process of OO software development<\/a>. The applications we will build are a step above trivial, and will require some careful thought and design. Further, because the applications are largely recreational in nature, they are interesting and engaging. This book allows the reader to explore the processes and artifacts of OO design before project deadlines make good design seem impossible.<\/p>\n

We hope to prevent managers from saying the following: \u201cWe had a good design, but were forced to compromise it to meet our schedule.\u201d As consultants, we find this to be a sad statement of management\u2019s emphasis of one near-term goal over long-term value. In one case, this was the result of a series of poorly-informed management decisions compounded on weak design skills. One of the root causes was the inability of the designers and managers to agree to a suitable course of action when a new kind of requirement made devastating changes to an existing design. We believe that more informed managers would have made a decision that created better long-term value.<\/p>\n","protected":false},"excerpt":{"rendered":"