Anti-Patterns part 1
•
8 gefällt mir•5,846 views
Part 1 of Anti-Patterns webinar by Dmitry Kochergin
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Anti-Patterns part 1
Ähnlich wie Anti-Patterns part 1 (20)
Mehr von Return on Intelligence
Mehr von Return on Intelligence (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Anti-Patterns part 1
- 1. Anti-patterns part 1 Dmitriy Kochergin, Developer Dnepropetrovsk, 2012 August 6, 2012 www.ExigenServices.com
- 2. Content • Root causes of anti-patterns • Organizational anti-patterns • Project management anti-patterns • Software design anti-patterns • Object-oriented design anti-patterns 2 2 www.ExigenServices.com
- 3. Goals • Learn common anti-patterns – their symptoms – and solutions • Have no fear to admit your mistakes • Will to improve your skills 3 3 www.ExigenServices.com
- 4. Anti-pattern Anti-pattern is a pattern that may be commonly used but is ineffective and/or counterproductive in practice Wikipedia “Something that looks like a good idea, but which backfires badly when applied” Jim Coplien “Commonly reinvented bad solutions to problems” 4 4 www.ExigenServices.com
- 5. Anti-pattern • 5/6 of software projects are regarded as failures • 1/3 of software projects are canceled • 2/3 of software projects are twice the expected budget and take twice as long as originally planned 5 5 www.ExigenServices.com
- 6. Why to learn Anti-patterns? • Why do we need to learn them? • real world examples of recurring problems with provided remedy • common vocabulary • developed to complement the existing fundamental software patterns (GoF, Buschmann, Analysis, CORBA) • helps to see the problem before they become a problem. • increase likelihood of project success • advance in your career • have more fun at work 6 6 www.ExigenServices.com
- 7. Pattern Antipattern 7 7 www.ExigenServices.com
- 8. Patterns and anti-patterns 8 8 www.ExigenServices.com
- 9. Part 1 Root causes of anti-patterns 9 9 www.ExigenServices.com
- 10. Root Cause of Anti-Patterns: Haste • Haste – aggressive project deadlines and budget – lower acceptance levels for code quality – insufficient testing – patches – accumulating technical debt 10 10 www.ExigenServices.com
- 11. Root Cause of Anti-Patterns: Apathy • Apathy: unwilling to find the proper solution; general lack of concern or care about solving a problem 11 11 www.ExigenServices.com
- 12. Root Cause of Anti-Patterns: Narrow-Mindedness • Narrow mindedness: refusal to practice solutions that are otherwise widely known to be effective 12 12 www.ExigenServices.com
- 13. Root Cause of Anti-Patterns: Sloth • Sloth: Poor decisions based upon an “easy answer” 13 13 www.ExigenServices.com
- 14. Root Cause of Anti-Patterns: Avarice • Avarice: modeling of excessive/insufficient abstraction adding accidental complexity 14 14 www.ExigenServices.com
- 15. Root Cause of Anti-Patterns: Ignorance • Ignorance: failure to seek a clear understanding of the problem or solution space (both intentional and non-intentional) 15 15 www.ExigenServices.com
- 16. Root Cause of Anti-Patterns: Ignorance 16 16 www.ExigenServices.com
- 17. Root Cause of Anti-Patterns: Pride • Pride: The sin of pride is the Not−Invented−Here syndrome 17 17 www.ExigenServices.com
- 18. Part 2 Organizational anti-patterns 18 18 www.ExigenServices.com
- 19. Analysis paralysis • Analysis paralysis: over-analyzing (or over- thinking) a situation, so that a decision or action is never taken, in effect paralyzing the outcome. • In software development it is exceedingly long phases of project planning, requirements gathering, program design and data modeling, with little or no extra value created by those steps. 19 19 www.ExigenServices.com
- 20. Analysis paralysis • Reason: – treating task as over-complicated – fear of making false decisions – trying to find ideal solution • Solution: – try something and change if a major problem arises – process should not be bureaucratic • In contrast: extinct by instinct (making a fatal decision based on hasty judgment or a gut-reaction) 20 20 www.ExigenServices.com
- 21. Design by committee • Design by committee: The result of having many contributors to a design, but no unifying vision • Reason: • poor architect leadership • programmers' ego • lack of knowledge • lack of code conventions • lack of knowledge of code conventions • lack of auto checking of code conventions • «Camel is a horse designed by committee» 21 21 www.ExigenServices.com
- 22. Design by committee • Results in: • internal inconsistency • needless complexity • logical errors • lack of a unifying vision • units that fit together poorly • Reuse is about people and education, not just architecture • know that it exists • know how to use it • are convinced that it‟s better than doing it themselves 22 22 www.ExigenServices.com
- 23. Escalation of commitment • Escalation of commitment: The phenomenon where people justify increased investment in a decision, based on the cumulative prior investment, despite new evidence suggesting that the cost, starting today, of continuing the decision outweighs the expected benefit. • Examples: • bidding wars • staying in a hand in poker • trying to revive inevitably dying project 23 23 www.ExigenServices.com
- 24. Vendor lock-in • Vendor lock-in: Makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs • Examples: • SIM locking • gift certificates • ICQ • Sony Memory Stick • external service or framework 24 24 www.ExigenServices.com
- 25. Vendor lock-in • Result in loss of control: • feature you need is always 6 month away • vendor may change the product and brake your software • May result in antitrust action against a monopoly • Solution: Isolation layer 25 25 www.ExigenServices.com
- 26. Other organizational anti- patterns • Cash cow: A profitable legacy product that often leads to complacency about new products • Management by perkele: Authoritarian style of management with no tolerance of dissent • Mushroom Management: company's staff being treated like mushrooms: kept in the dark, covered with dung, and, when grown big enough, canned (fired). • Bystander apathy: When a requirement or design decision is wrong, but the people who notice this do nothing because it affects a larger number of people 26 26 www.ExigenServices.com
- 27. Part 3 Project management anti-patterns 27 27 www.ExigenServices.com
- 28. Death march • Death march: Everyone knows that the project is going to be a disaster – so the truth is hidden to prevent immediate cancellation of the project • Project is artificially kept alive until the Day Zero finally comes ("Big Bang") • Alternative definition: Employees are pressured to work late nights and weekends on a project with an unreasonable deadline 28 28 www.ExigenServices.com
- 29. Death march • Solution: • train senior and project management • policy for monitoring and controlling projects • manage risks and issues • provide appropriate resources • constrain project scope 29 29 www.ExigenServices.com
- 30. Hero Mode • Hero Mode: the organization relies on the heroic efforts of a small number of capable individuals to achieve a successful outcome • Solution: • estimate properly • maintain and monitor a plan • distribute tasks • don‟t reward heroic behavior 30 30 www.ExigenServices.com
- 31. Seagull manager • “Seagull managers fly in, make a lot of noise, dump on everyone, then fly out.” (Ken Blanchard's 1985 “Leadership and the One Minute Manager book”) • Seagull manager interacts with employees only when a problem arises, making hasty decisions about things they have little understanding of, then leaving others to deal with the mess they leave behind 31 31 www.ExigenServices.com
- 32. Give Me Estimates Now • Give Me Estimates Now: Senior Management wants estimates at very short notice, forcing the project to estimate with insufficient supporting data • Solution: • educate management • record estimates and actuals 32 32 www.ExigenServices.com
- 33. Jekyll & Hyde Mr. Jekyll in private conversation, 8:01 AM: (gentle voice) “Yes, I think your idea is great, let’s talk it over in the lunch. It’s on me.” Mr. Hyde in project meeting with the subordinates and the big boss is listening, 8.03 AM (furious): “What the.. That’s a poor idea. And why no one has done anything to think about this beforehand? I can’t stand this kind of incompetence!” • Problem: A (typically opportunist) person whose behaviour is totally dependent on the audience. Jekyll transforms to and from Hyde in a nanosecond • Refactored solution: a good long talk in a proper and non- offending environment (pizza?); a transfer to other projects & departments 33 www.ExigenServices.com
- 34. Lonely Rider “Oh no we cannot do anything to the module before John comes back from his two-month holiday (in Bali)!” “I am a guru. I’d like to work alone, it’s just my way of doing things.” “I don’t know about it. Ask John, he has written the code for almost all of our key components.” • Problem: A seemingly irreplaceable person who intentionally or unintentionally becomes the single point of failure and bottleneck in the software project • Refactored solution: interaction between developers, constant peer reviews, competence transfer, mentoring help to less experienced and busy developers 34 www.ExigenServices.com
- 35. Metric Abuse • Metric Abuse: a malicious or ignorant misuse of measurement data, either to influence people or make management decisions • For example, code coverage • Solution: • collect metrics that relate to business goals • ensure measures have clear meaning 35 35 www.ExigenServices.com
- 36. Other project management anti- patterns • Groupthink: During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking • Overengineering: Spending resources making a project more robust and complex than is needed • Smoke and mirrors: Demonstrating unimplemented functions as if they were already implemented 36 36 www.ExigenServices.com
- 37. Part 4 Software design anti-patterns 37 37 www.ExigenServices.com
- 38. Software bloat • Software bloat: Successive versions of a system demand more and more resources. • Reason: increasing proportion of unnecessary features • Results: program use more system resources than necessary, while offering little or no benefit to its users • Example: • Windows • Delphi programs 38 38 www.ExigenServices.com
- 39. Software bloat • Solution: • use plug-ins, extensions or add-ons • use Unix philosophy: "Write programs that do one thing and do it well“ • Similar anti-patterns • functions for tick • feature creep - extra features go beyond the basic function of the product and so can result in over-complication • code bloat • spaghetti code • unused functions • recalculation rather reuse already calculated value • copy-paste rather than reuse subroutine 39 39 www.ExigenServices.com
- 40. Patterns Fetish • Patterns Fetish: Unreasonable and excessive use of design patterns • Designer looks for places to use patterns • Solution: • look at the design problem • favor simple solutions 40 40 www.ExigenServices.com
- 41. Abstraction inversion • Abstraction inversion: Not exposing implemented functionality required by users, so that they re- implement it using higher level functions • This is not complex modules with simple interface • Results: • copy-pasting of internal implementation is error-prone and may corrupt with new version of external module • manual reimplementation may cost • user is forced to obscure his implementation with complex details of external module • user may patch framework and be bound to patched version 41 41 www.ExigenServices.com
- 42. Big ball of mud • A big ball of mud is a software system that lacks a perceivable architecture. • Such systems are common in practice due to business pressures and developers rotation. • Symptoms • day-to-day patching the holes • maintenance nightmare 42 42 www.ExigenServices.com
- 43. Gold plating • Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value. • The customer might be disappointed with the result, and the extra effort by the developer might be futile. 43 43 www.ExigenServices.com
- 44. Other design anti-patterns • Input kludge: Failing to specify and implement the handling of possibly invalid input • Stovepipe system: a system that has the potential to share data or functionality with other systems but which does not. 44 44 www.ExigenServices.com
- 45. Part 4 Object-oriented design anti-patterns 45 45 www.ExigenServices.com
- 46. Anemic domain model • Anemic domain model: business logic is implemented outside the domain objects • This pattern is a common approach in enterprise Java applications (possibly encouraged by technologies such as early versions of EJB's Entity Beans) • Anemic domain model is the typical result of not applying the GRASP information expert principle, i.e. you can avoid an anemic domain model by trying to assign responsibilities to the same classes that contain the data 46 46 www.ExigenServices.com
- 47. Anemic domain model • Benefits • clear separation between logic and data • supports the Single responsibility principle by dividing the business data (changes very seldom) from business logic (changes often) • GRASP Pure Fabrication pattern: it‟s a class that doesn‟t represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion. This kind of class is called "Service" in Domain-driven design 47 47 www.ExigenServices.com
- 48. Anemic domain model • Liabilities • not truly object-oriented way • violation of the encapsulation and information hiding principles. • domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside • increased coupling • code duplication, reduced code reuse • need of service layer when sharing domain logic 48 48 www.ExigenServices.com
- 49. BaseBean • BaseBean is a utility object from which concrete entities are derived (via subclassing) • Class should not inherit from another class simply because the parent class contains functionality needed in the subclass • Derived class to rely on the internals of a base class which may be out of the control of the developer • Instead, delegation (has-a relationship) should be used • This is composition over inheritance case. 49 49 www.ExigenServices.com
- 50. Call super • Call super: user which overrides a method required to call back the overridden function at a particular point. • The overridden method may be intentionally incomplete, and reliant on the overriding method to augment its functionality in a prescribed manner. • The language itself may not be able to enforce all conditions prescribed on this call is what makes this an anti-pattern • Note that it is the requirement of calling the parent that is the anti-pattern. • Use the Template method pattern instead 50 50 www.ExigenServices.com
- 51. Circle-ellipse problem • Circle-ellipse problem (sometimes known as the square-rectangle problem) : This problem arises as a violation of Liskov substitution principle (This is the L in the acronym S.O.L.I.D. ) • Liskov's principle: if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering the clients. 51 51 www.ExigenServices.com
- 52. Circle-ellipse problem • Liskov's principle imposes some standard requirements on signatures • Contravariance of method arguments in the subtype. • Covariance of return types in the subtype. • No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype. • Additionally subtype must meet behavioral conditions: • preconditions cannot be strengthened in a subtype. • postconditions cannot be weakened in a subtype. • invariants of the supertype must be preserved in a subtype. 52 52 www.ExigenServices.com
- 53. Circular dependency • Circular dependency: relation between two or more modules which either directly or indirectly depend on each other • Problems: • tight coupling • can cause a domino effect when a small local change in one module spreads into other modules and has unwanted global effects • unclear modules‟ structure 53 53 www.ExigenServices.com
- 54. Circular dependency • Follow Acyclic Dependencies Principle (ADP): The dependency structure between packages must be a Directed Acyclic Graph (DAG) • To break cycles: • use Dependency Inversion Principle (DIP) • create a new package that both packages depend upon 54 54 www.ExigenServices.com
- 55. Constant interface • Constant interface: pattern describes the use of an interface solely to define constants, and having classes implement that interface in order to achieve convenient syntactic access to those constants. • Bloch, Joshua, Effective Java, 2nd Edition, p. 98 • Problems: • it pollutes the class namespace with read-only variables that may not be of use • not clear where constant comes from without IDE • its not part of implementing class API (purpose of interface is to extend that API) 55 55 www.ExigenServices.com
- 56. Constant interface • Alternatives: • convert the constants interface to a proper class with no instances • use Java 5 static imports 56 56 www.ExigenServices.com
- 57. Monster object • Monster object (or God object, or Blob) is an object that knows too much or does too much: • doesn„t follow SRP • hard to maintain • hard to refactor • global variables • testability problems 57 57 www.ExigenServices.com
- 58. Monster object • Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem • Every class should have only one purpose, which can be described by few words • Use a roles and responsibility model • This technique is occasionally used for tight programming environments (such as microcontrollers, mobile phones) 58 58 www.ExigenServices.com
- 59. Object cesspool • Object cesspool: when using object pools state of the objects returned to the pool should be reset • The pool is responsible for resetting the objects, not the clients • Reusing stale objects can cause bugs, security issues, personal information leaks. 59 59 www.ExigenServices.com
- 60. Sequential coupling • Sequential coupling refers to a class that requires its methods to be called in a particular sequence • Methods whose name starts with Init, Begin, Start, etc. may indicate sequential coupling • Client is required to know too much about the class which methods have predefined execution order. It‟s also error-prone. • Sequential coupling can be refactored with the Template method pattern 60 60 www.ExigenServices.com
- 61. Yo-yo problem • Yo-yo problem: occurs in a program whose inheritance graph is so long and complicated • Programmer has to keep flipping between many different class definitions in order to follow the control flow of the program • More generally, the yo-yo problem can also refer to any situation where a person must keep flipping between different sources 61 61 www.ExigenServices.com
- 62. Yo-yo problem • Solution: • Keep the inheritance graph as shallow as possible • Use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once • Hrair limit: The Magical Number Seven, Plus or Minus Two • meaningful method names 62 62 www.ExigenServices.com
- 63. THANKS FOR COMING!!! • My contacts: – e-mail: dmitriy.kochergin@exigenservices.com – Skype: dmitry.kochergin 63 63 www.ExigenServices.com
- 64. Questions Questions? 64 64 www.ExigenServices.com
Hinweis der Redaktion
- Design Patterns define an ideal solution to a problem, while the AntiPatterns describe two solutions:AntiPattern solution: the unwanted, problematic, existing solutionrefactored solution: the good solution (target of the AntiPattern)
- СпешкаHasteHasty decisions lead to compromises in software quality, as shown in Figure 2.3. Softwareprojects are often subjected to severe schedule−related stress. At project inception,managers are pressured to trim budgets and schedules to make unrealistic targets. Assuccessive project deadlines are missed, anything that appears to work is consideredacceptable, regardless of quality. The usual victim of a slip in project delivery is testing.12Figure 2.3 Haste makes waste.• Unit test coverage for each component.• Repeated testing of success paths and error states for integrated components.• Regression testing.In this environment, long−term architectural benefits are sacrificed for expedience.Quality, object−oriented architecture is the product of careful study, decision making, andexperimentation. At a minimum, the object−oriented architecture process includes farming ofrequirements, architecture mining, and hands−on experience. Ideally, object−orientedarchitecture comprises a set of high−quality design decisions that provide benefitsthroughout the life cycle of the system.Significant domain experience for the architect is essential as object−oriented architecturesare competently defined and defended. With appropriate domain experience and designpatterns, quality object−oriented architectures are defined rapidly. However, it’s always amistake to make object−oriented architectural decisions hastily.
- Апатия, безразличиеApathyApathy is not caring about solving known problems. That is not to say that all solutions areknown or fully achievable, but apathy is a basic unwillingness to attempt a solution (Figure2.4). Apathy about object−oriented architecture leads to a lack of partitioning. A key aspect ofobject−oriented architecture is proper partitioning. For example, object−oriented architecturepartitions the system into class categories and defines their interfaces and connections.Figure 2.4 Apathy is the worst form of flattery.13The critical partitioning decision in OO architecture is between stable reusable design andreplaceable design. The stable design remains with the system throughout its life cycle, asindividual software modules are modified, replaced, and added. Replaceable design detailsare best allocated to profiles, vertical specializations, and metadata.Neglecting the critical partitioning means that the core of the architecture must change inresponse to subsystem level changes. This means that subsystem−level changes impact allof the modules in the entire system. Thus, the sin of apathy leads to poor support for change.In addition, poorly partitioned architectures make application interoperability and reusedifficult.
- Ограниченностьума, узость мыслиNarrow−MindednessNarrow−mindedness is the refusal to practice solutions that are otherwise widely known to beeffective (Figure 2.5). An example of this is the use of metadata in software systems.Metadata is self−descriptive information in a software system that enables the system tochange dynamically.Figure 2.5 The Unteachables.Many object−oriented systems are built with virtually no metadata. Without metadata, theapplication software contains hard−coded bindings, relationships, and assumptions aboutsystem configuration. For example, the number of servers or clients and their locations canbe made transparently variable with straightforward use of metadata services. CORBAstandards include various public metadata services, such as the Naming Service, the TraderService, and the Interface Repository.
- ЛеньSlothSloth is the “healthy sign” of a lazy developer or manager, who makes poor decisions basedupon an “easy answer” (Figure 2.6). Distributed object technology enables applicationdevelopers to define system−level interfaces quickly using the ISO Interface DefinitionLanguage (ISO IDL). Automatically generated interface stubs and skeletons make the task ofconstructing a distributed system relatively easy. The ease of creating and changinginterfaces leads to the deadly sin of sloth—lack of configuration control.14Figure 2.6 Sloth usually ends with sudden clarity.Although sloth is more commonplace in small−scale, object−oriented projects, the habit offrequent interface change is difficult to overcome. The more interfaces change, the more theinterface semantics become unclear to developers. Ultimately, developers and maintainersspend more than half of their time performing system discovery—trying to understand howthe system works. The system loses any notion of architecture long before this point isreached.Proper configuration control starts with the first phase of prototyping. Ideally, system−levelinterfaces are kept stable during active software development and modified only infrequently.Stable interfaces enable parallel development, effective documentation, and reducedsoftware obsolescence.
- жадность, алчность, корыстолюбиеAvariceGreed can take many forms, but it leads to inappropriate software development decisions.Architectural avarice means the modeling of excessive details, which results in excessivecomplexity due to insufficient abstraction (Figure 2.7).Figure 2.7 Addicted to complexity.Excess complexity leads to many software problems and project challenges. Overly complexsystems are expensive to develop, integrate, test, document, maintain, and extend. In somecases, development steps are skipped (such as testing) in order to make up for the lost timeand money. This can lead very quickly to project failure.
- Невежество, незнание, неведение, неосведомленностьIgnoranceIgnorance is intellectual sloth. It’s the result of failing to seek understanding. It keeps peoplestupid (Figure 2.8), and eventually leads to long−term software problems. The sin ofignorance (implementation dependency) often occurs in the migration of applications todistributed architectures. In ignorance, one assumes that system−level interfaces areextracted from fine−grain definitions of existing application objects. For example, when anIDL interface is reverse−engineered from existing C++ header files,15implementation−dependent interfaces are created and promulgated throughout a system andits subsystems.Figure 2.8 Some people are too ignorant to change.If an object’s interface is unique and there are no other implementations that support thesame interface, then the interface is implementation−dependent. Every client or object thatuses this interface is dependent upon unique implementation details. When this occursrepeatedly on a systemwide scale, a brittle system is created. This sin is also evident whenvendor−proprietary interfaces are used without proper layering and wrapping for isolation
- Невежество, незнание, неведение, неосведомленность
- гордость, гордыняPrideThe sin of pride is the not−invented−here syndrome (Figure 2.9). Object technology supportsmany reuse opportunities through the integration of commercial packages, freeware, andwrappered legacy applications.Figure 2.9 Pride goeth before the fall.Often, developers unnecessarily invent new designs when knowledge from preexistingsystems, products, and standards are readily applied through architecture mining.Reinvention involves many unnecessary risks and costs. New software must be designed,coded, debugged, tested, and documented. New architecture must be prototyped andevolved before it is proven to provide software benefits
- Design by committee From Wikipedia, the free encyclopediaThe term is especially common in technical parlance, and it legitimizes the need and general acceptance of a unique systems architect. Often, when software is designed by a committee, the original motivation, specifications and technical criteria take a backseat and poor choices may be made merely to appease the egos of several individual committee members. Such products and standards end up doing too many things or having parts that fit together poorly (because the entities who produced those parts were unaware of each other's requirements for a good fit).One such example was the decision for an Asynchronous Transfer Mode (ATM) cell size of 53 bytes. The choice of 53 bytes was political rather than technical.[1] When the CCITT was standardizing ATM, parties from the United States wanted a 64-byte payload. Parties from Europe wanted 32-byte payloads. Most of the European parties eventually came around to the arguments made by the Americans, but France and a few others held out for a shorter cell length of 32 bytes. A 53-byte size (48 bytes plus 5 byte header) was the compromise chosen. Computer and network systems typically work in 32-byte and 64-byte sizes.The term is also common in other fields of design such as graphic design, architecture or industrial design. In automotive design this process is often attributed to poorly designed or unpopular cars.[2]One maxim is that a camel is a horse designed by committee; this has been attributed to Vogue magazine, July 1958, to Sir Alec Issigonis and also to University of Wisconsin philosophy professor Lester Hunt.[3]
- Design by committee From Wikipedia, the free encyclopediaThe term is especially common in technical parlance, and it legitimizes the need and general acceptance of a unique systems architect. Often, when software is designed by a committee, the original motivation, specifications and technical criteria take a backseat and poor choices may be made merely to appease the egos of several individual committee members. Such products and standards end up doing too many things or having parts that fit together poorly (because the entities who produced those parts were unaware of each other's requirements for a good fit).One such example was the decision for an Asynchronous Transfer Mode (ATM) cell size of 53 bytes. The choice of 53 bytes was political rather than technical.[1] When the CCITT was standardizing ATM, parties from the United States wanted a 64-byte payload. Parties from Europe wanted 32-byte payloads. Most of the European parties eventually came around to the arguments made by the Americans, but France and a few others held out for a shorter cell length of 32 bytes. A 53-byte size (48 bytes plus 5 byte header) was the compromise chosen. Computer and network systems typically work in 32-byte and 64-byte sizes.The term is also common in other fields of design such as graphic design, architecture or industrial design. In automotive design this process is often attributed to poorly designed or unpopular cars.[2]One maxim is that a camel is a horse designed by committee; this has been attributed to Vogue magazine, July 1958, to Sir Alec Issigonis and also to University of Wisconsin philosophy professor Lester Hunt.[3]===========================================================Reuse is about people and education, not just architectureYou might adopt the approach that a framework that is well designed, or an architecture that is carefully considered, and cleverly implemented will lend itself to re-use within your organization. The truth is that even the most beautiful, elegant and re-usable architecture, framework or system will only be re-used by people who: a) know it is there b) know how to use it c) are convinced that it is better than doing it themselves a) Know its there Within your organization, developers or designers need to know a design, framework, library, or fragments of code exists and where they can find all the critical information about these elements (e.g. documentation, versions, and compatibility) in order to reuse them. It is a simple, logical truth that people won't look for things that they don't believe to exist. You are more likely to succeed with reusable elements if the information about them is “pushed”. There are any number of methods for pushing information about reusable elements in an organization. These range from wiki pages with an RSS feed providing update information, useful in very large teams, to e-mail announcing version updates in the source repository. In a tiny team, the designer or lead developer can inform his colleagues in personal conversations or shouting it across the office. Ultimately, whatever your process for communicating about reusable elements... make sure you have one, don’t leave it up to chance. b) Know how to use it Understanding how to reuse an element depends on skills and training. Of course there are those people who (to use Donald Knuth’s terminology) "resonate" with coding and design. We have all worked with them, the gifted developers and architects whose speed and depth of understanding is impressive, even scary. But these people are rare. The rest of your team might be made up of good, solid, intelligent developers and designers. They need to be taught. Developers and designers might not know of the particular design pattern used in a design, or fully understand the inheritance model that the framework designer intended them to use. They need to be given easy access to that information in the form of up-to-date documentation, or even better, training. A little training goes a long way to ensuring that everyone is on the same page when it comes to reuse. c) Are convinced that its better than doing it themselves People, and particularly developers, tend to prefer to solve problems themselves rather than ask for help. Asking how something works is a sign of weakness, or even an indication of ignorance. This has a lot to do with the maturity and personality type of your individual team-members, “Better than doing it themselves” means different things to different people. The “young guns” on your team will always want to write things themselves because it appeases their ego, whereas your more experienced people are more likely to accept that someone else has given thought to the problem domain and has something to offer in terms of a solution. If your team doesn’t know where to find reusable artifacts or how to reuse them they will default to the natural, human position: they will build it themselves. And you will pay for it. (RMH Edited 7/13/2008) By Jeremy Meyer
- Escalation of commitment From Wikipedia, the free encyclopediaEscalation of commitment was first described by Barry M. Staw in his 1976 paper, "Knee deep in the big muddy: A study of escalating commitment to a chosen course of action".[1] More recently the term sunk cost fallacy has been used to describe the phenomenon where people justify increased investment in a decision, based on the cumulative prior investment, despite new evidence suggesting that the cost, starting today, of continuing the decision outweighs the expected benefit. Such investment may include money, time, or — in the case of military strategy — human lives. The phenomenon and the sentiment underlying it are reflected in such proverbial images as Throwing good money after bad and In for a dime, in for a dollar (or In for a penny, in for a pound).The term is also used to describe poor decision-making in business, government, information systems in general, softwareproject management in particular, politics, and gambling. The term has been used to describe the United States commitment to military conflicts including Vietnam in the 1960s - 1970s and in Iraq in the 2000s, where dollars spent and lives lost justify continued involvement.[2]Alternatively, irrational escalation (sometimes referred to as irrational escalation of commitment or commitment bias) is a term frequently used in psychology, philosophy, economics, and game theory[citation needed] to refer to a situation in which people can make irrational decisions based upon rational decisions in the past or to justify actions already taken. Examples are frequently seen when parties engage in a bidding war; the bidders can end up paying much more than the object is worth to justify the initial expenses associated with bidding (such as research), as well as part of a competitive instinct.Examples- The dollar auction is a thought exercise demonstrating the concept.- After a heated and aggressive bidding war, Robert Campeau ended up buying Bloomingdale's for an estimated 600 million dollars more than it was worth. The Wall Street Journal noted that "we're not dealing in price anymore but egos". Campeau was forced to declare bankruptcy soon afterwards.[3]- In Poker, the term "pot committed" refers to staying in a hand due to earlier bets, despite increasing likelihood that you will lose.
- Vendor lock-in From Wikipedia, the free encyclopediaIn economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs. Lock-in costs which create barriers to market entry may result in antitrust action against a monopoly.[edit] Examples of lock-inThis unreferenced section requires citations to ensure verifiability. [edit] SIM lockingMain article: SIM lockSIM locking may be considered a vendor lock-in tactic as phones purchased from the vendor will work with SIM cards only from the same network. This creates additional inconvenience to the buyer as the phone cannot use a prepaid SIM from a different vendor while on vacation (a common tactic used by Asian tourists visiting another Asian country) and as a result the subscriber must also sign up the often expensive roaming service offered by the vendor. Additionally, should the subscriber wish to take out a second line for any reason, he/she must also get the line from the same vendor, as the SIM card of a competing vendor will not work. Sometimes, even the SIM card from the same vendor will not work and the buyer will be forced into buying another phone.[citation needed][edit] AutomobilesAutomobiles are often made with certain parts, such as car stereos, which might be interchangeable. Sometimes the manufacturers will attempt to create lock-in by various means; in the case of a stereo, they might make the stereo unit an unusual size and shape instead of a standard one[dubious – discuss], or create a unique way for the dashboard part of the stereo to control a CD Changer in the trunk.Various standards organizations, such as the US Department of Transportation, regulate the design of certain automobile components to prevent vendor lock-in.[edit] Gift certificatesGift certificates are textbook examples of vendor lock-in as they can be used solely in the vendor's shops. Gift certificates typically only worth their face price (no bonus credit is added), so generally, they do not represent any advantage over money.Also, some vendors practice a store-credit/gift certificate refund policy in the time of warranty if they can't replace or repair the product. This is illegal in many jurisdictions as it forces the client to buy a different article in the same shop possibly for lower price/quality ratio. It's also possible that the client is forced to buy a completely different product if the original product line is no longer sold.This policy is different from the refund policy in case of dissatisfaction. In this case, the vendor offers to exchange the article in a typically short time frame. If the article is not faulty then the vendor has no obligation to exchange or refund it unless he's committed to do so in advance.[edit] Telephone equipmentThe Bell System monopoly initially refused to allow anyone to interconnection of their network to other networks or to non-Bell equipment, until the Hush-A-Phone v. United States federal court ruling and the Carterfone FCC regulatory ruling.The Bell System allowed interconnection to third-party equipment only through the added expense of protective acoustic coupler, while Bell equipment could be directly electrically connected to the network, until a later FCC order which led to standardized modular connectors.[edit] Other examplesMany printers manufacturers claim that if any ink cartridges, beyond those sold by themselves, are used in the printer, the warranty of the printer becomes void.The Filofax brand of personal organizers, for example, is not compatible with standard paper and ring-binder sizes, so users can buy additional and replacement supplies only from Filofax or a limited number of other suppliers. Costs are several times those of comparable stationery supplies in standard sizes and formats.The K-Cup single-use coffee pod system is patented and licensed by Keurig, which is a subsidiary of Green Mountain Coffee Roasters. All K-Cups are licensed, there are no generics. K-Cup brewers can be used only with K-Cups, with the alternative being the optional reusable filter for use with any coffee grounds other than brands or blends approved by Keurig. Other Single-serving coffee brands, such as Nespresso, also have proprietary systems.Many vacuum cleaners are only compatible with specific filter bags.The detachable heads of electric toothbrushes can often only be replaced by heads made by the same company.[edit] Lock-in for electronics and computersVendor lock-in is widespread in the computer and electronics industries.In the computer industry, both hardware and software, vendor lock-in can be used to describe situations in which there is a lack of compatibility or interoperability between equivalent components.This can make it difficult to switch systems at many levels; the application program, the file format, the operating system, or various pieces of computer hardware ranging from a video card to a whole computer or even an entire network of computers. Note that in many cases, there are no technical standards that would allow creation of interoperable systems. At nearly any level of systems architecture, lock-in may occur. This creates a situation where lock-in is often used as leverage to get market share, often leading to monopolies and antitrust actions.[edit] AdobeSee also: Adobe Flash#Vendor dependence and Use of Ogg formats in HTML5Adobe is accused of vendor lock-in because of their Flash Player. Adobe's browser plug-in is present in over 95% of computers worldwide and has been a cause of scrutiny against its privacy policies.[citation needed]In response to Flash Player's dominance as a video player, the HTML5 specification allows video playback without requiring the Adobe Flash plugin. In accordance with this standard, Mozilla Foundation has natively (no plug-in necessary) included Vorbis and Theora playback in its flagship browser Firefox starting from the version 3.5, as they say "to enable unencumbered, royalty-free, open-source friendly audio and video playback on the Web" and Firefox 4.0 and later versions supports native (no plug-in necessary) playback of WebM & VP8 in addition to Theora playback support.As of 13 December 2010, the biggest video website that has adopted HTML5 video playback is Daily Motion (with YouTube currently running a beta) although a sizable amount of videos aren't encoded with a royalty-free codec.[citation needed][edit] IBMMain article: History_of_IBM#1969:_Antitrust.2C_the_Unbundling_of_software_and_servicesThis unreferenced section requires citations to ensure verifiability. IBM was subject to a series of the longest and most complex monopoly antitrust actions in United States history, and presented the first significant model for understanding of how lock-in affected the computer industry. IBM had significant lock-in of the punched card industry from its earliest days; before computers as we recognize them today even existed. From dominance of the card punches, readers, tabulators, and printers, IBM extended to dominance of the mainframe computer market, and then to the operating systems and application programs for computers. Third party products existed for some areas, but customers then faced the prospect of having to prove which vendor was at fault if, say, a third party printer didn't work correctly with an IBM computer, and IBM's warranties and service agreements often stipulated that they would not support systems with non-IBM components attached. This put customers into an all-or-nothing situation.[edit] MicrosoftMain article: Criticism of Microsoft#Vendor lock-inSee also: Windows 8#Secure_bootMicrosoft software carries a high level of vendor lock-in, based on its extensive set of proprietary APIs. Their degree of lock-in combined with their market share has made them subject to a number of antitrust lawsuits.The European Commission, in its March 24, 2004 decision on Microsoft's business practices,[1] quotes, in paragraph 463, Microsoft general manager for C++ development Aaron Contorer as stating in a February 21, 1997 internal Microsoft memo drafted for Bill Gates:"The Windows API is so broad, so deep, and so functional that most ISVs would be crazy not to use it. And it is so deeply embedded in the source code of many Windows apps that there is a huge switching cost to using a different operating system instead... "It is this switching cost that has given the customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO, our lack of a sexy vision at times, and many other difficulties [...] Customers constantly evaluate other desktop platforms, [but] it would be so much work to move over that they hope we just improve Windows rather than force them to move. "In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago." Microsoft's application software also exhibits lock-in through the use of proprietary file formats. Microsoft Outlook uses a proprietary datastore file and interface which are impossible to read without being parsed, and such parsers may in turn not be able to exist legally without performing reverse engineering. For example, to access data contained in Outlook's '.PST' files, the application must process the request through Outlook instead of directly handling the file. Present versions of Microsoft Word have introduced a new format MS-OOXML. This may make it easier for competitors to write documents compatible with Microsoft Office in the future by reducing lock-in. Microsoft released full descriptions of the file formats for earlier versions of Word, Excel and PowerPoint in February 2008.[2][edit] Apple Inc.Main article: Criticism_of_Apple_Inc.#Accusations_of_anti-competitive_behaviorApple Inc. has historically been well known for its lock-in practices. For a long time their market share has been small enough that their anti-trust exposure has been substantially less than that of Microsoft or IBM.Apple often makes use of new or unusual hardware systems; they were the first vendor to make widespread use of Sony's 3.5" floppy drive, and they devised their own Apple Desktop Bus system for keyboards and mice, their own LocalTalk networking system, the high-speed FireWire serial interface for storage and video transfer, the 30-pin iPod dock connector, and non-standard display interfaces such as ADC, Mini-DVI, and Mini DisplayPort. Due to Apple's smaller market share the number of third-party providers was more limited than for the competing IBM PC platform (though larger than for the Amiga, which had similarly unusual components), and third-party providers sometimes had to license elements of the interface technology, meaning that Apple made money on every peripheral sold, even if they did not manufacture it.Prior to March 2009 digital music files with digital rights management were available for purchase from the iTunes music store encoded in a proprietary derivative of the .AAC format that used Apple's FairPlay DRM system. These files are compatible only with Apple's iTunes media player software on Macs and Windows, their iPod portable digital music players, iPhonesmartphones, iPadtablet computers, and the MotorolaROKR E1 and SLVR mobile phones. As a result, that music was locked into this ecosystem and available for portable use only through the purchase of one of the above devices,[3] or by burning to CD and optionally re-ripping to a DRM-free format such as MP3 or WAV.In January, 2005, an iPod purchaser named Thomas Slattery filed a suit against Apple for the "unlawful bundling" of their iTunes Music Store and iPod device. He stated in his brief: "Apple has turned an open and interactive standard into an artifice that prevents consumers from using the portable hard drive digital music player of their choice." At the time Apple was stated to have an 80% market share of digital music sales and a 90% share of sales of new music players, which he claimed allowed Apple to horizontally leverage its dominant positions in both markets to lock consumers into its complementary offerings.[4] In September 2005, U.S. District Judge James Ware approved Slattery v. Apple Computer Inc. to proceed with monopoly charges against Apple in violation of the Sherman Antitrust Act.[5]On June 7, 2006, the Norwegian Consumer Ombudsman Bjørn Erik Thon stated that Apple's iTunes Music Store violates Norwegian law. The contract conditions were vague and "clearly unbalanced to disfavor the customer".[6] The retroactive changes to the Digital Rights Management conditions and the incompatibility with other music players are the major points of concern.As of 29 May 2007, tracks on the EMI label became available in a DRM-free format called iTunes Plus. These files are unprotected and are encoded in the AAC format at 256 kilobits per second, twice the bitrate of standard tracks bought through the service. iTunes accounts can be set to display either standard or iTunes Plus formats for tracks where both formats exist.[7] These files can be used with any player that supports the AAC file format and are not locked to Apple hardware. They can be converted to MP3 format if desired.As of January 6, 2009, all 4 big music studios (Warner Bros., Sony BMG, Universal, and EMI) have signed up to remove the DRM from their tracks, at no extra cost. However, Apple charges consumers to have previously purchased DRM music restrictions removed.[8]As of the end of March, 2009, all music available on iTunes is DRM-free,[8] however, digital downloads of television shows, movies, and iOSmobile apps through iTunes are still DRM-protected (at the insistence of the content producers who make it a prerequisite for distribution on most systems including Apple's).[edit] SonyThis unreferenced section requires citations to ensure verifiability. Probably Sony's most famous example of lock-in was the BetamaxVCR system. Since then, Sony has also used lock-in as a business tool in many other applications, and has a long history of engineering proprietary solutions to enforce lock-in. For many cases Sony licenses its technology to a limited number of other vendors, which creates a situation in which it controls a cartel that collectively has lock-in on the product. Sony is frequently at the heart of format wars, in which two or more such cartels battle to capture a market and win the lock.Examples of Sony's formats include:Audio ElcasetAudio or computer data Minidisc and the related ATRAC3 encoding systemSuper Audio CDBetamax, Video-8, Hi8, Digital8, and MicroMV videotape formatsPlayStation PortableUniversal Media DiscMemory Sticks, used for a wide variety of applications in Sony productsAs of 2006, Sonydigital cameras and a number of other Sony products typically use Memory Stick cards that can be manufactured only by Sony, co-developer SanDisk, and select licensees. This memory can be more expensive in some markets when compared to alternative memory types that exhibit similar characteristics such as data transfer speeds. This is an example of vendor lock-in, as existing users of Sony products are less likely to purchase a competitors product that uses a different storage medium due to the extra cost of acquiring a differing storage media. Similarly this can discourage consumers with non-Sony merchandise from purchasing Sony products.In contrast, Blu-ray Disc was developed by the Blu-ray Disc Association where Sony is a member, but does not have a controlling position.[edit] Connector conspiracyThis unreferenced section requires citations to ensure verifiability. Manufacturers of computer hardware sometimes design unusual or proprietary connectors. The reasons for such designs vary; some are intended to quietly force customers into a vendor lock-in situation, or force upgrading customers to replace more components than would otherwise be necessary; others are the result of practical considerations such as cost, packaging, ease of design, unusual or enhanced features; and still others result from an ignorance of standards, or even an absence of standards. There may be little immediate financial incentive for a vendor to provide backward compatibility or interoperability.The term Connector Conspiracy[9] was coined to describe this situation, and implies the worst case scenario of a cabal of manufacturers colluding in secret to sell incompatible connectors. Yet actual lock-in attempts can fail, if adapters can be purchased or manufactured to make the components compatible.[edit] Avoiding vendor lock-in for computer softwareIn the 1980s and 1990s, public, royalty-free standards were hailed as the best solution to vendor lock-in. But there is still a possibility that one software vendor could use "embrace, extend and extinguish" (EEE) tactics to achieve a dominant market share, which could render the standard obsolete. The history of SQL is an archetypal example.Since the late 1990s, the use of free and open source software (FOSS) has arisen as a stronger solution. Because FOSS can be modified and distributed by anyone, the availability of functionality usually cannot tie a user to one distributor. The ineffectiveness of distributor lock-in means there's no incentive for FOSS developers to invent redundant new data formats if usable (royalty-free) standards exist.In particular, copylefted FOSS is in some respects particularly resistant to the above mentioned "EEE" tactics since anyone distributing modified versions cannot legally prevent free or competing redistribution of the modifications and their source code. It is also, however, particularly well suited to those tactics in other respects, such as in competition with non-copyleft free and open source software.[10][edit] Similar models[edit] Razor and bladeMain article: Freebie marketingThe razor and blades business model involves products which regularly consume some material, part, or supply. In this system, a reusable or durable product is inexpensive, and the company draws its profits from the sale of consumable parts that the product uses. To ensure the original company alone receives the profits from the sales of consumable, they use a proprietary approach to exclude other companies. Inkjet computer printers are a common example of this model.[edit] Loyalty programsMain article: Loyalty programOne way to create artificial lock-in for items without it is to create loyalty schemes. Examples include frequent flier miles or points systems associated with credit card offers that can be used only with the original company, creating a perceived loss or cost when switching to a competitor.Vendor lock-inМатериал из Википедии — свободной энциклопедииПерейти к: навигация, поиск«Vendor lock-in» (также «proprietary lock-in», «customer lock-in», «привязка к поставщику», «замыкание на одном поставщике», «барьер для смены поставщика»), в экономике — зависимость потребителя от продуктов и сервисов одного поставщика, невозможность сменить поставщика из‑за высоких затрат на переход.Поставщики заинтересованы намеренно создавать замыкание для завоевания большой доли рынка, что иногда приводит к появлению монополии и «стандартов де-факто».Содержание1 Совместимость2 Примеры замыкания2.1 ICQ2.2 Sony Memory Stick2.3 Фотоаппараты2.4 Microsoft2.4.1 Microsoft Office3 Примечания4 См. также5 СсылкиСовместимостьКак естественное, так и намеренное замыкание может возникнуть в результате появления несовместимых с другими «стандартов де-факто», обеспечивать совместимость с которыми для конкурентов оказывается дорого, трудно или невозможно по лицензионным причинам.Дорого — из‑за отсутствия конструктивной совместимости массово производимых деталей.Трудно — из‑за недокументированных форматов, используемых собственническим программным обеспечением.Незаконно — из‑за патентов, коммерческой тайны, DRM; лицензий, прямо запрещающих использование продукта в конкурирующих средах (пример — некоторые лицензии Microsoft shared source).Даже при отсутствии (снятии) правовых ограничений и тайн обеспечение совместимости со «стандартом де-факто» может не нести никакой иной пользы.Иногда компании добавляют к открытым стандартам собственные расширения[1] (как полезные, так и бесполезные или дублирующие существующие), не раскрывая их или патентуя. Такая тактика называется Embrace, Extend, and Extinguish («Поддержать, надстроить и уничтожить»).Примеры замыканияЭтот раздел не завершён. Вы поможете проекту, исправив и дополнив его.ICQAOL иногда меняла протокол ICQнесовместимым образом, что затрудняло использование «неофициальных» клиентов, таких как Miranda и другие. Отдельно стоит отметить, что «официальный» клиент существует только для Microsoft Windows и Mac OS X[2]. Бета-версия для операционных системLinux появилась только в мае 2011[3], а ICQ-клиент для телефонов и прочих устройств с поддержкой J2ME был выпущен лишь в 2010 году.Sony Memory StickПрактически все мобильные устройства используют карты памяти стандарта SD, miniSD и microSD.Устройства фирмы Sony используют флэш-память стандарта Memory Stick. Значительная часть устройств Sony при этом не поддерживает память, отличную от Memory Stick. Таким образом, купив устройство фирмы Sony, покупатель вынужден докупать к нему карты памяти, которые в среднем в полтора-два раза дороже SD и к тому же в большинстве случаев не могут быть использованы с уже имеющимся оборудованием.Однако, давно появились адаптеры с SD в Memory Stick. Для PSP существует адаптер, исполненный в корпусе стандартной Memory Stick, позволяющий использовать одновременно две карты MicroSD и таким образом получать объём в 32 ГБ. [4]ФотоаппаратыВ фотоаппаратах есть всего три открытых стандарта для аксессуаров: штативный винт диаметром 1/4 дюйма, горячий башмак и резьба M42. Последние два плохи тем, что они «глупы» — в них нет управления диафрагмой, фокусировкой и ведущим числом фотовспышки. Поэтому разные производители делают свои собственные форматы объективов, вспышек и пультов дистанционного спуска, и при смене производителя приходится менять все аксессуары (кроме разве что штатива).Существуют всевозможные переходники для объективов, которые стоят достаточно дёшево — во много раз меньше, чем хороший объектив. Они широко используются для крепления объективов «доцифровой» эры на современные фотоаппараты — впрочем, фокусировка или автоматика диафрагмы на них зачастую работает с ограничениями.MicrosoftОсновная статья: MicrosoftMicrosoft OfficeТекстовый процессорMicrosoft Word и табличный процессорMicrosoft Excel, входящие в пакет Microsoft Office, в течение многих лет[5] по умолчанию сохраняли документы в формате, описание которого можно было получить только за деньги и подписку о неразглашении, что препятствовало реализации качественной поддержки этого формата в конкурирующих программах. Позже условия доступа к описанию изменились, но возник вопрос о том, подходят ли они для свободного ПО, которое не приемлет патентных ограничений. Эти новые условия также распространяются на новый формат, основанный на предыдущих — сделанный стандартом ISO и Ecma вскоре после принятия ISO и OASIS менее спорного по своей открытости аналога.[6]Microsoft предоставляет программу для Windows «Microsoft Word Viewer», которая позволяет просматривать файлы в форматах Word. Документы с помощью Microsoft Office Word Viewer 2003 разрешено только просматривать и «screen print».[7]Спустя 10 лет Microsoft Office Word 2007 Service Pack 2 обеспечивает неполную[3] поддержку открытого формата .odf, а в OpenOffice.org реализована ограниченная поддержка формата .docx, «родного» для Microsoft Word 2007.Примечания↑Amy Cortese; John Verity in New York, Kathy Rebello, Rob Hof; bureau reportsThe Software Revolution--Part 2 (англ.). The McGraw-Hill Companies Inc. (4 декабря 1995). Архивировано из первоисточника 19 марта 2012. Проверено 24 апреля 2009.↑ICQ for Mac — ICQ.com↑ICQ for Linux(beta) — ICQ.com↑[1][2]↑ * Спецификация формата Microsoft Word 97-2007 (англ.)↑Илья Щуров VoyagerСтандарт, еще стандарт. Компьютерра–Онлайн (10 марта 2008). Проверено 4 октября 2008.↑LICENSE TERMS FOR MICROSOFT SOFTWARE - Excel - Office.comСм. такжеОткрытый форматСвободное программное обеспечениеUser Agent#Подделка User-agentСсылкиИлья Щуров VoyagerВ первый класс — с чистой совестью. Компьютерра–Онлайн (21 августа 2007). Проверено 4 октября 2008.
- Vendor lock-in From Wikipedia, the free encyclopediaIn economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs. Lock-in costs which create barriers to market entry may result in antitrust action against a monopoly.[edit] Examples of lock-inThis unreferenced section requires citations to ensure verifiability. [edit] SIM lockingMain article: SIM lockSIM locking may be considered a vendor lock-in tactic as phones purchased from the vendor will work with SIM cards only from the same network. This creates additional inconvenience to the buyer as the phone cannot use a prepaid SIM from a different vendor while on vacation (a common tactic used by Asian tourists visiting another Asian country) and as a result the subscriber must also sign up the often expensive roaming service offered by the vendor. Additionally, should the subscriber wish to take out a second line for any reason, he/she must also get the line from the same vendor, as the SIM card of a competing vendor will not work. Sometimes, even the SIM card from the same vendor will not work and the buyer will be forced into buying another phone.[citation needed][edit] AutomobilesAutomobiles are often made with certain parts, such as car stereos, which might be interchangeable. Sometimes the manufacturers will attempt to create lock-in by various means; in the case of a stereo, they might make the stereo unit an unusual size and shape instead of a standard one[dubious – discuss], or create a unique way for the dashboard part of the stereo to control a CD Changer in the trunk.Various standards organizations, such as the US Department of Transportation, regulate the design of certain automobile components to prevent vendor lock-in.[edit] Gift certificatesGift certificates are textbook examples of vendor lock-in as they can be used solely in the vendor's shops. Gift certificates typically only worth their face price (no bonus credit is added), so generally, they do not represent any advantage over money.Also, some vendors practice a store-credit/gift certificate refund policy in the time of warranty if they can't replace or repair the product. This is illegal in many jurisdictions as it forces the client to buy a different article in the same shop possibly for lower price/quality ratio. It's also possible that the client is forced to buy a completely different product if the original product line is no longer sold.This policy is different from the refund policy in case of dissatisfaction. In this case, the vendor offers to exchange the article in a typically short time frame. If the article is not faulty then the vendor has no obligation to exchange or refund it unless he's committed to do so in advance.[edit] Telephone equipmentThe Bell System monopoly initially refused to allow anyone to interconnection of their network to other networks or to non-Bell equipment, until the Hush-A-Phone v. United States federal court ruling and the Carterfone FCC regulatory ruling.The Bell System allowed interconnection to third-party equipment only through the added expense of protective acoustic coupler, while Bell equipment could be directly electrically connected to the network, until a later FCC order which led to standardized modular connectors.[edit] Other examplesMany printers manufacturers claim that if any ink cartridges, beyond those sold by themselves, are used in the printer, the warranty of the printer becomes void.The Filofax brand of personal organizers, for example, is not compatible with standard paper and ring-binder sizes, so users can buy additional and replacement supplies only from Filofax or a limited number of other suppliers. Costs are several times those of comparable stationery supplies in standard sizes and formats.The K-Cup single-use coffee pod system is patented and licensed by Keurig, which is a subsidiary of Green Mountain Coffee Roasters. All K-Cups are licensed, there are no generics. K-Cup brewers can be used only with K-Cups, with the alternative being the optional reusable filter for use with any coffee grounds other than brands or blends approved by Keurig. Other Single-serving coffee brands, such as Nespresso, also have proprietary systems.Many vacuum cleaners are only compatible with specific filter bags.The detachable heads of electric toothbrushes can often only be replaced by heads made by the same company.[edit] Lock-in for electronics and computersVendor lock-in is widespread in the computer and electronics industries.In the computer industry, both hardware and software, vendor lock-in can be used to describe situations in which there is a lack of compatibility or interoperability between equivalent components.This can make it difficult to switch systems at many levels; the application program, the file format, the operating system, or various pieces of computer hardware ranging from a video card to a whole computer or even an entire network of computers. Note that in many cases, there are no technical standards that would allow creation of interoperable systems. At nearly any level of systems architecture, lock-in may occur. This creates a situation where lock-in is often used as leverage to get market share, often leading to monopolies and antitrust actions.[edit] AdobeSee also: Adobe Flash#Vendor dependence and Use of Ogg formats in HTML5Adobe is accused of vendor lock-in because of their Flash Player. Adobe's browser plug-in is present in over 95% of computers worldwide and has been a cause of scrutiny against its privacy policies.[citation needed]In response to Flash Player's dominance as a video player, the HTML5 specification allows video playback without requiring the Adobe Flash plugin. In accordance with this standard, Mozilla Foundation has natively (no plug-in necessary) included Vorbis and Theora playback in its flagship browser Firefox starting from the version 3.5, as they say "to enable unencumbered, royalty-free, open-source friendly audio and video playback on the Web" and Firefox 4.0 and later versions supports native (no plug-in necessary) playback of WebM & VP8 in addition to Theora playback support.As of 13 December 2010, the biggest video website that has adopted HTML5 video playback is Daily Motion (with YouTube currently running a beta) although a sizable amount of videos aren't encoded with a royalty-free codec.[citation needed][edit] IBMMain article: History_of_IBM#1969:_Antitrust.2C_the_Unbundling_of_software_and_servicesThis unreferenced section requires citations to ensure verifiability. IBM was subject to a series of the longest and most complex monopoly antitrust actions in United States history, and presented the first significant model for understanding of how lock-in affected the computer industry. IBM had significant lock-in of the punched card industry from its earliest days; before computers as we recognize them today even existed. From dominance of the card punches, readers, tabulators, and printers, IBM extended to dominance of the mainframe computer market, and then to the operating systems and application programs for computers. Third party products existed for some areas, but customers then faced the prospect of having to prove which vendor was at fault if, say, a third party printer didn't work correctly with an IBM computer, and IBM's warranties and service agreements often stipulated that they would not support systems with non-IBM components attached. This put customers into an all-or-nothing situation.[edit] MicrosoftMain article: Criticism of Microsoft#Vendor lock-inSee also: Windows 8#Secure_bootMicrosoft software carries a high level of vendor lock-in, based on its extensive set of proprietary APIs. Their degree of lock-in combined with their market share has made them subject to a number of antitrust lawsuits.The European Commission, in its March 24, 2004 decision on Microsoft's business practices,[1] quotes, in paragraph 463, Microsoft general manager for C++ development Aaron Contorer as stating in a February 21, 1997 internal Microsoft memo drafted for Bill Gates:"The Windows API is so broad, so deep, and so functional that most ISVs would be crazy not to use it. And it is so deeply embedded in the source code of many Windows apps that there is a huge switching cost to using a different operating system instead... "It is this switching cost that has given the customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO, our lack of a sexy vision at times, and many other difficulties [...] Customers constantly evaluate other desktop platforms, [but] it would be so much work to move over that they hope we just improve Windows rather than force them to move. "In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago." Microsoft's application software also exhibits lock-in through the use of proprietary file formats. Microsoft Outlook uses a proprietary datastore file and interface which are impossible to read without being parsed, and such parsers may in turn not be able to exist legally without performing reverse engineering. For example, to access data contained in Outlook's '.PST' files, the application must process the request through Outlook instead of directly handling the file. Present versions of Microsoft Word have introduced a new format MS-OOXML. This may make it easier for competitors to write documents compatible with Microsoft Office in the future by reducing lock-in. Microsoft released full descriptions of the file formats for earlier versions of Word, Excel and PowerPoint in February 2008.[2][edit] Apple Inc.Main article: Criticism_of_Apple_Inc.#Accusations_of_anti-competitive_behaviorApple Inc. has historically been well known for its lock-in practices. For a long time their market share has been small enough that their anti-trust exposure has been substantially less than that of Microsoft or IBM.Apple often makes use of new or unusual hardware systems; they were the first vendor to make widespread use of Sony's 3.5" floppy drive, and they devised their own Apple Desktop Bus system for keyboards and mice, their own LocalTalk networking system, the high-speed FireWire serial interface for storage and video transfer, the 30-pin iPod dock connector, and non-standard display interfaces such as ADC, Mini-DVI, and Mini DisplayPort. Due to Apple's smaller market share the number of third-party providers was more limited than for the competing IBM PC platform (though larger than for the Amiga, which had similarly unusual components), and third-party providers sometimes had to license elements of the interface technology, meaning that Apple made money on every peripheral sold, even if they did not manufacture it.Prior to March 2009 digital music files with digital rights management were available for purchase from the iTunes music store encoded in a proprietary derivative of the .AAC format that used Apple's FairPlay DRM system. These files are compatible only with Apple's iTunes media player software on Macs and Windows, their iPod portable digital music players, iPhonesmartphones, iPadtablet computers, and the MotorolaROKR E1 and SLVR mobile phones. As a result, that music was locked into this ecosystem and available for portable use only through the purchase of one of the above devices,[3] or by burning to CD and optionally re-ripping to a DRM-free format such as MP3 or WAV.In January, 2005, an iPod purchaser named Thomas Slattery filed a suit against Apple for the "unlawful bundling" of their iTunes Music Store and iPod device. He stated in his brief: "Apple has turned an open and interactive standard into an artifice that prevents consumers from using the portable hard drive digital music player of their choice." At the time Apple was stated to have an 80% market share of digital music sales and a 90% share of sales of new music players, which he claimed allowed Apple to horizontally leverage its dominant positions in both markets to lock consumers into its complementary offerings.[4] In September 2005, U.S. District Judge James Ware approved Slattery v. Apple Computer Inc. to proceed with monopoly charges against Apple in violation of the Sherman Antitrust Act.[5]On June 7, 2006, the Norwegian Consumer Ombudsman Bjørn Erik Thon stated that Apple's iTunes Music Store violates Norwegian law. The contract conditions were vague and "clearly unbalanced to disfavor the customer".[6] The retroactive changes to the Digital Rights Management conditions and the incompatibility with other music players are the major points of concern.As of 29 May 2007, tracks on the EMI label became available in a DRM-free format called iTunes Plus. These files are unprotected and are encoded in the AAC format at 256 kilobits per second, twice the bitrate of standard tracks bought through the service. iTunes accounts can be set to display either standard or iTunes Plus formats for tracks where both formats exist.[7] These files can be used with any player that supports the AAC file format and are not locked to Apple hardware. They can be converted to MP3 format if desired.As of January 6, 2009, all 4 big music studios (Warner Bros., Sony BMG, Universal, and EMI) have signed up to remove the DRM from their tracks, at no extra cost. However, Apple charges consumers to have previously purchased DRM music restrictions removed.[8]As of the end of March, 2009, all music available on iTunes is DRM-free,[8] however, digital downloads of television shows, movies, and iOSmobile apps through iTunes are still DRM-protected (at the insistence of the content producers who make it a prerequisite for distribution on most systems including Apple's).[edit] SonyThis unreferenced section requires citations to ensure verifiability. Probably Sony's most famous example of lock-in was the BetamaxVCR system. Since then, Sony has also used lock-in as a business tool in many other applications, and has a long history of engineering proprietary solutions to enforce lock-in. For many cases Sony licenses its technology to a limited number of other vendors, which creates a situation in which it controls a cartel that collectively has lock-in on the product. Sony is frequently at the heart of format wars, in which two or more such cartels battle to capture a market and win the lock.Examples of Sony's formats include:Audio ElcasetAudio or computer data Minidisc and the related ATRAC3 encoding systemSuper Audio CDBetamax, Video-8, Hi8, Digital8, and MicroMV videotape formatsPlayStation PortableUniversal Media DiscMemory Sticks, used for a wide variety of applications in Sony productsAs of 2006, Sonydigital cameras and a number of other Sony products typically use Memory Stick cards that can be manufactured only by Sony, co-developer SanDisk, and select licensees. This memory can be more expensive in some markets when compared to alternative memory types that exhibit similar characteristics such as data transfer speeds. This is an example of vendor lock-in, as existing users of Sony products are less likely to purchase a competitors product that uses a different storage medium due to the extra cost of acquiring a differing storage media. Similarly this can discourage consumers with non-Sony merchandise from purchasing Sony products.In contrast, Blu-ray Disc was developed by the Blu-ray Disc Association where Sony is a member, but does not have a controlling position.[edit] Connector conspiracyThis unreferenced section requires citations to ensure verifiability. Manufacturers of computer hardware sometimes design unusual or proprietary connectors. The reasons for such designs vary; some are intended to quietly force customers into a vendor lock-in situation, or force upgrading customers to replace more components than would otherwise be necessary; others are the result of practical considerations such as cost, packaging, ease of design, unusual or enhanced features; and still others result from an ignorance of standards, or even an absence of standards. There may be little immediate financial incentive for a vendor to provide backward compatibility or interoperability.The term Connector Conspiracy[9] was coined to describe this situation, and implies the worst case scenario of a cabal of manufacturers colluding in secret to sell incompatible connectors. Yet actual lock-in attempts can fail, if adapters can be purchased or manufactured to make the components compatible.[edit] Avoiding vendor lock-in for computer softwareIn the 1980s and 1990s, public, royalty-free standards were hailed as the best solution to vendor lock-in. But there is still a possibility that one software vendor could use "embrace, extend and extinguish" (EEE) tactics to achieve a dominant market share, which could render the standard obsolete. The history of SQL is an archetypal example.Since the late 1990s, the use of free and open source software (FOSS) has arisen as a stronger solution. Because FOSS can be modified and distributed by anyone, the availability of functionality usually cannot tie a user to one distributor. The ineffectiveness of distributor lock-in means there's no incentive for FOSS developers to invent redundant new data formats if usable (royalty-free) standards exist.In particular, copylefted FOSS is in some respects particularly resistant to the above mentioned "EEE" tactics since anyone distributing modified versions cannot legally prevent free or competing redistribution of the modifications and their source code. It is also, however, particularly well suited to those tactics in other respects, such as in competition with non-copyleft free and open source software.[10][edit] Similar models[edit] Razor and bladeMain article: Freebie marketingThe razor and blades business model involves products which regularly consume some material, part, or supply. In this system, a reusable or durable product is inexpensive, and the company draws its profits from the sale of consumable parts that the product uses. To ensure the original company alone receives the profits from the sales of consumable, they use a proprietary approach to exclude other companies. Inkjet computer printers are a common example of this model.[edit] Loyalty programsMain article: Loyalty programOne way to create artificial lock-in for items without it is to create loyalty schemes. Examples include frequent flier miles or points systems associated with credit card offers that can be used only with the original company, creating a perceived loss or cost when switching to a competitor.Vendor lock-inМатериал из Википедии — свободной энциклопедииПерейти к: навигация, поиск«Vendor lock-in» (также «proprietary lock-in», «customer lock-in», «привязка к поставщику», «замыкание на одном поставщике», «барьер для смены поставщика»), в экономике — зависимость потребителя от продуктов и сервисов одного поставщика, невозможность сменить поставщика из‑за высоких затрат на переход.Поставщики заинтересованы намеренно создавать замыкание для завоевания большой доли рынка, что иногда приводит к появлению монополии и «стандартов де-факто».Содержание1 Совместимость2 Примеры замыкания2.1 ICQ2.2 Sony Memory Stick2.3 Фотоаппараты2.4 Microsoft2.4.1 Microsoft Office3 Примечания4 См. также5 СсылкиСовместимостьКак естественное, так и намеренное замыкание может возникнуть в результате появления несовместимых с другими «стандартов де-факто», обеспечивать совместимость с которыми для конкурентов оказывается дорого, трудно или невозможно по лицензионным причинам.Дорого — из‑за отсутствия конструктивной совместимости массово производимых деталей.Трудно — из‑за недокументированных форматов, используемых собственническим программным обеспечением.Незаконно — из‑за патентов, коммерческой тайны, DRM; лицензий, прямо запрещающих использование продукта в конкурирующих средах (пример — некоторые лицензии Microsoft shared source).Даже при отсутствии (снятии) правовых ограничений и тайн обеспечение совместимости со «стандартом де-факто» может не нести никакой иной пользы.Иногда компании добавляют к открытым стандартам собственные расширения[1] (как полезные, так и бесполезные или дублирующие существующие), не раскрывая их или патентуя. Такая тактика называется Embrace, Extend, and Extinguish («Поддержать, надстроить и уничтожить»).Примеры замыканияЭтот раздел не завершён. Вы поможете проекту, исправив и дополнив его.ICQAOL иногда меняла протокол ICQнесовместимым образом, что затрудняло использование «неофициальных» клиентов, таких как Miranda и другие. Отдельно стоит отметить, что «официальный» клиент существует только для Microsoft Windows и Mac OS X[2]. Бета-версия для операционных системLinux появилась только в мае 2011[3], а ICQ-клиент для телефонов и прочих устройств с поддержкой J2ME был выпущен лишь в 2010 году.Sony Memory StickПрактически все мобильные устройства используют карты памяти стандарта SD, miniSD и microSD.Устройства фирмы Sony используют флэш-память стандарта Memory Stick. Значительная часть устройств Sony при этом не поддерживает память, отличную от Memory Stick. Таким образом, купив устройство фирмы Sony, покупатель вынужден докупать к нему карты памяти, которые в среднем в полтора-два раза дороже SD и к тому же в большинстве случаев не могут быть использованы с уже имеющимся оборудованием.Однако, давно появились адаптеры с SD в Memory Stick. Для PSP существует адаптер, исполненный в корпусе стандартной Memory Stick, позволяющий использовать одновременно две карты MicroSD и таким образом получать объём в 32 ГБ. [4]ФотоаппаратыВ фотоаппаратах есть всего три открытых стандарта для аксессуаров: штативный винт диаметром 1/4 дюйма, горячий башмак и резьба M42. Последние два плохи тем, что они «глупы» — в них нет управления диафрагмой, фокусировкой и ведущим числом фотовспышки. Поэтому разные производители делают свои собственные форматы объективов, вспышек и пультов дистанционного спуска, и при смене производителя приходится менять все аксессуары (кроме разве что штатива).Существуют всевозможные переходники для объективов, которые стоят достаточно дёшево — во много раз меньше, чем хороший объектив. Они широко используются для крепления объективов «доцифровой» эры на современные фотоаппараты — впрочем, фокусировка или автоматика диафрагмы на них зачастую работает с ограничениями.MicrosoftОсновная статья: MicrosoftMicrosoft OfficeТекстовый процессорMicrosoft Word и табличный процессорMicrosoft Excel, входящие в пакет Microsoft Office, в течение многих лет[5] по умолчанию сохраняли документы в формате, описание которого можно было получить только за деньги и подписку о неразглашении, что препятствовало реализации качественной поддержки этого формата в конкурирующих программах. Позже условия доступа к описанию изменились, но возник вопрос о том, подходят ли они для свободного ПО, которое не приемлет патентных ограничений. Эти новые условия также распространяются на новый формат, основанный на предыдущих — сделанный стандартом ISO и Ecma вскоре после принятия ISO и OASIS менее спорного по своей открытости аналога.[6]Microsoft предоставляет программу для Windows «Microsoft Word Viewer», которая позволяет просматривать файлы в форматах Word. Документы с помощью Microsoft Office Word Viewer 2003 разрешено только просматривать и «screen print».[7]Спустя 10 лет Microsoft Office Word 2007 Service Pack 2 обеспечивает неполную[3] поддержку открытого формата .odf, а в OpenOffice.org реализована ограниченная поддержка формата .docx, «родного» для Microsoft Word 2007.Примечания↑Amy Cortese; John Verity in New York, Kathy Rebello, Rob Hof; bureau reportsThe Software Revolution--Part 2 (англ.). The McGraw-Hill Companies Inc. (4 декабря 1995). Архивировано из первоисточника 19 марта 2012. Проверено 24 апреля 2009.↑ICQ for Mac — ICQ.com↑ICQ for Linux(beta) — ICQ.com↑[1][2]↑ * Спецификация формата Microsoft Word 97-2007 (англ.)↑Илья Щуров VoyagerСтандарт, еще стандарт. Компьютерра–Онлайн (10 марта 2008). Проверено 4 октября 2008.↑LICENSE TERMS FOR MICROSOFT SOFTWARE - Excel - Office.comСм. такжеОткрытый форматСвободное программное обеспечениеUser Agent#Подделка User-agentСсылкиИлья Щуров VoyagerВ первый класс — с чистой совестью. Компьютерра–Онлайн (21 августа 2007). Проверено 4 октября 2008.
- Death march (project management) From Wikipedia, the free encyclopediaThis article is about the use of the term in project management (originally and especially in software development). For real death marches, see death march.In project management, a death march is any of several types of pathologic projects involving a dysphemistic, dark-humor analogy to real death marches, such as being gruelingly overworked, and (often and most especially) being gruelingly overworked for ill-founded reasons on a project that is obviously at high risk of bad outcome (i.e., project failure, and possibly threat of personal and group reputation damage). Thus the name "death march" may be applied to a project that is ultimately successful but involves a home stretch of unsustainable overwork, or (perhaps more often) to a project that any intelligent, informed member can see is destined to fail (or is at very high risk of failure) but that the members are nevertheless forced to act out by their superiors anyway. Both of these themes have metaphorical parallel in real death marches.The fields whose project management practice first named these related phenomena are software development and software engineering. Other fields have since recognized the same occurrence in their own spheres and have naturally adopted the name.Death marches of the destined-to-fail type usually are a result of unrealistic or overly optimistic expectations in scheduling, feature scope, or both, and often include lack of appropriate documentation or relevant training and outside expertise that would be needed to do the task successfully. The knowledge of the doomed nature of the project weighs heavily on the psyche of its participants, as if they are helplessly watching themselves and their coworkers being forced to torture themselves and march toward death. Often, the death march will involve desperate attempts to right the course of the project by asking team members to work especially grueling hours (14-hour days, 7-day weeks, etc.) or by attempting to "throw (enough) bodies at the problem", often causing burnout.Often, the discomfort is heightened by the knowledge that "it didn't have to be this way," that is, that if the company wanted to achieve the goal of the project, it could have done so in a successful way if it had been managed competently (such as by devoting the obviously required resources, including bringing all relevant expertise, technology, or applied science to the task rather than just whatever incomplete knowledge a few employees happened to know already). Patent underresourcing is especially offensive at a large corporation with sufficiently deep pockets; at least at small companies, a gap between resources and needs is understandable, but at large, profitable, cash-rich companies, underresourcing is not a necessity and thus feels to most workers like stupidity. Business culture pressures, such as the long-noted phenomenon of corporations pursuing short-term maximization of profits via cost cutting or avoidance that is damaging to long-term best interest, may play a role in addition to mere incompetence.The term "death march" in this context was discussed at length in Edward Yourdon's book Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects (ISBN 0130146595), which has a second edition simply titled Death March (ISBN 013143635X). Yourdon's definition: "Quite simply, a death march project is one whose 'project parameters' exceed the norm by at least 50 percent." [1]
- Death march (project management) From Wikipedia, the free encyclopediaThis article is about the use of the term in project management (originally and especially in software development). For real death marches, see death march.In project management, a death march is any of several types of pathologic projects involving a dysphemistic, dark-humor analogy to real death marches, such as being gruelingly overworked, and (often and most especially) being gruelingly overworked for ill-founded reasons on a project that is obviously at high risk of bad outcome (i.e., project failure, and possibly threat of personal and group reputation damage). Thus the name "death march" may be applied to a project that is ultimately successful but involves a home stretch of unsustainable overwork, or (perhaps more often) to a project that any intelligent, informed member can see is destined to fail (or is at very high risk of failure) but that the members are nevertheless forced to act out by their superiors anyway. Both of these themes have metaphorical parallel in real death marches.The fields whose project management practice first named these related phenomena are software development and software engineering. Other fields have since recognized the same occurrence in their own spheres and have naturally adopted the name.Death marches of the destined-to-fail type usually are a result of unrealistic or overly optimistic expectations in scheduling, feature scope, or both, and often include lack of appropriate documentation or relevant training and outside expertise that would be needed to do the task successfully. The knowledge of the doomed nature of the project weighs heavily on the psyche of its participants, as if they are helplessly watching themselves and their coworkers being forced to torture themselves and march toward death. Often, the death march will involve desperate attempts to right the course of the project by asking team members to work especially grueling hours (14-hour days, 7-day weeks, etc.) or by attempting to "throw (enough) bodies at the problem", often causing burnout.Often, the discomfort is heightened by the knowledge that "it didn't have to be this way," that is, that if the company wanted to achieve the goal of the project, it could have done so in a successful way if it had been managed competently (such as by devoting the obviously required resources, including bringing all relevant expertise, technology, or applied science to the task rather than just whatever incomplete knowledge a few employees happened to know already). Patent underresourcing is especially offensive at a large corporation with sufficiently deep pockets; at least at small companies, a gap between resources and needs is understandable, but at large, profitable, cash-rich companies, underresourcing is not a necessity and thus feels to most workers like stupidity. Business culture pressures, such as the long-noted phenomenon of corporations pursuing short-term maximization of profits via cost cutting or avoidance that is damaging to long-term best interest, may play a role in addition to mere incompetence.The term "death march" in this context was discussed at length in Edward Yourdon's book Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects (ISBN 0130146595), which has a second edition simply titled Death March (ISBN 013143635X). Yourdon's definition: "Quite simply, a death march project is one whose 'project parameters' exceed the norm by at least 50 percent." [1]
- Software bloat From Wikipedia, the free encyclopedia[edit] CausesSoftware developers involved in the industry during the 1970s had severe limitations on disk space and memory. Every byte and clock cycle counted, and much work went into fitting the programs into available resources. Achieving this efficiency was one of the highest values of computer programmers, and the best programs were often called "elegant;" —seen as a form of high art.This situation has now reversed. Resources are perceived as cheap, and rapidity of coding and headline features for marketing are seen as priorities.[1] In part, this is because technological advances have since increased processing capacity and storage density by orders of magnitude, while reducing the relative costs by similar orders of magnitude (see Moore's Law). Additionally, the spread of computers through all levels of business and home life has produced a software industry many times larger than it was in the 1970s. Programs are now usually churned out by teams, directed by committees in software factories where each programmer works on only a part of the whole, on one or more subroutine. Thus today; the highest value is often the adherence to a predetermined structure that makes it compliant, —with subroutines as interchangeable as piston rods. Inelegant, even sloppy code is to some degree hidden from the end users by the increasing brute force and speed of modern computers. (There is little payoff to say, ...increase the speed of a sloppy five-millisecond subroutine —even by a factor of 100.)Finally, software development tools and approaches often result in changes throughout a program to accommodate each feature, leading to a large-scale inclusion of code which affects the main operation of the software, and is required in order to support functions that themselves may be only rarely used. In particular, the advances in resources available have led to tools which allow easier development of code, again; with less priority given to end efficiency.Another cause of bloat is independently competing standards and products, which can create a demand for integration. There are now more operating systems, browsers, protocols, and storage formats than there were before, causing bloat in programs due to interoperability issues. For example, a program that once could only save in text format is now demanded to save in HTML, XML, XLS, CSV, PDF, DOC, and other formats.Niklaus Wirth has summed up the situation in Wirth's Law, which states that software speed is decreasing more quickly than hardware speed is increasing.In his 2001 essay Strategy Letter IV: Bloatware and the 80/20 Myth,[2]Joel Spolsky argues that while 80% of the users only use 20% of the features (a variant on the Pareto principle), each one uses different features. Thus, "lite" software editions turn out to be useless for most, as they miss the one or two special features that are present in the "bloated" version. Spolsky sums the article with a quote by Jamie Zawinski referring to the Mozilla Application Suite (which later became Netscape):"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. But being a shining jewel of perfection was not a goal when we wrote Mozilla."[3]Software bloat may also be a symptom of the second-system effect, described by Fred Brooks in The Mythical Man-Month.[edit] ExamplesComparison of Microsoft Windows minimum hardware requirements (for x86 versions). Windows version Processor Memory Hard disk Windows 95[4] 25 MHz 4 MB ~50 MB Windows 98[5] 66 MHz 16 MB ~200 MB Windows 2000[6] 133 MHz 32 MB 650 MB Windows XP[7] (2001) 233 MHz 64 MB 1.5 GB Windows Vista[8] (2007) 800 MHz 512 MB 15 GB Windows 7[9] (2009) 1 GHz 1 GB 16 GB Apple's iTunes has been accused of being bloated as part of its efforts to turn it from a program that plays media to an e-commerce and advertising platform,[10][11] with former PC World editor Ed Bott, author of 25 books on Microsoft Windows and Office[12], accusing the company of hypocrisy in its advertising attacks on Windows for similar practices.[13]Microsoft Windows has also been criticized as being bloated - with reference to Windows Vista, Microsoft engineer Eric Traut commented that "A lot of people think of Windows as this large, bloated operating system, and that's maybe a fair characterization, I have to admit. ... But at its core, the kernel, and the components that make up the very core of the operating system, is actually pretty streamlined." [14][15] Former PC World editor Ed Bott has expressed skepticism, noting that almost every single operating system that Microsoft has ever sold had been criticized as 'bloated' when it first came out; even those now regarded as the exact opposite, such as MS-DOS.[16]CD- and DVD-burning applications such as Nero Burning ROM have become criticized for being bloated.[17] Superfluous features not specifically tailored to the end user are sometimes installed by default through express setups.A number of technology blogs have also covered the issue of increased bloatware on cell phones. However, they refer to a different issue, specifically that of wireless carriers loading phones with software that, in many cases, cannot be easily deleted, if at all. This has been most frequently cited with respect to Android devices, although this phenomenon exists on phones running many other operating systems.[18][19][edit] Alternatives to software bloatSome applications, such as Mozilla Firefox and Winamp, package additional functionality in plug-ins, extensions or add-ons which are downloaded separately from the main application. These can be created by the software developer and often by third parties. Plug-ins enable extra functionality which might have otherwise been packaged in the main program.Allowing extensions reduces the space used on any one machine, because even though the application plus the "plug-in interface" plus all the plug-ins is larger than the same functionality compiled into one monolithic application, it allows each user to install only the particular add-on features required by that user, rather than force every user to install a much larger monolithic application that includes 100% of the available features.Open source software may use a similar technique using preprocessor directives to selectively include features at compile time. This is easier to implement than a plugin system, but has the disadvantage that a user who wants a specific set of features must compile the program from source.Sometimes software becomes bloated because of "creeping featurism"[20] (Zawinski's Law of Software Envelopment), also called bullet-point engineering. One way to reduce that kind of bloat is described by the Unix philosophy: "Write programs that do one thing and do it well".[edit] See alsoCode bloatComputing minimalismFeature creepZawinski's Law of Software EnvelopmentBullet-point engineeringEnhanced remake
- Software bloat From Wikipedia, the free encyclopedia[edit] CausesSoftware developers involved in the industry during the 1970s had severe limitations on disk space and memory. Every byte and clock cycle counted, and much work went into fitting the programs into available resources. Achieving this efficiency was one of the highest values of computer programmers, and the best programs were often called "elegant;" —seen as a form of high art.This situation has now reversed. Resources are perceived as cheap, and rapidity of coding and headline features for marketing are seen as priorities.[1] In part, this is because technological advances have since increased processing capacity and storage density by orders of magnitude, while reducing the relative costs by similar orders of magnitude (see Moore's Law). Additionally, the spread of computers through all levels of business and home life has produced a software industry many times larger than it was in the 1970s. Programs are now usually churned out by teams, directed by committees in software factories where each programmer works on only a part of the whole, on one or more subroutine. Thus today; the highest value is often the adherence to a predetermined structure that makes it compliant, —with subroutines as interchangeable as piston rods. Inelegant, even sloppy code is to some degree hidden from the end users by the increasing brute force and speed of modern computers. (There is little payoff to say, ...increase the speed of a sloppy five-millisecond subroutine —even by a factor of 100.)Finally, software development tools and approaches often result in changes throughout a program to accommodate each feature, leading to a large-scale inclusion of code which affects the main operation of the software, and is required in order to support functions that themselves may be only rarely used. In particular, the advances in resources available have led to tools which allow easier development of code, again; with less priority given to end efficiency.Another cause of bloat is independently competing standards and products, which can create a demand for integration. There are now more operating systems, browsers, protocols, and storage formats than there were before, causing bloat in programs due to interoperability issues. For example, a program that once could only save in text format is now demanded to save in HTML, XML, XLS, CSV, PDF, DOC, and other formats.Niklaus Wirth has summed up the situation in Wirth's Law, which states that software speed is decreasing more quickly than hardware speed is increasing.In his 2001 essay Strategy Letter IV: Bloatware and the 80/20 Myth,[2]Joel Spolsky argues that while 80% of the users only use 20% of the features (a variant on the Pareto principle), each one uses different features. Thus, "lite" software editions turn out to be useless for most, as they miss the one or two special features that are present in the "bloated" version. Spolsky sums the article with a quote by Jamie Zawinski referring to the Mozilla Application Suite (which later became Netscape):"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. But being a shining jewel of perfection was not a goal when we wrote Mozilla."[3]Software bloat may also be a symptom of the second-system effect, described by Fred Brooks in The Mythical Man-Month.[edit] ExamplesComparison of Microsoft Windows minimum hardware requirements (for x86 versions). Windows version Processor Memory Hard disk Windows 95[4] 25 MHz 4 MB ~50 MB Windows 98[5] 66 MHz 16 MB ~200 MB Windows 2000[6] 133 MHz 32 MB 650 MB Windows XP[7] (2001) 233 MHz 64 MB 1.5 GB Windows Vista[8] (2007) 800 MHz 512 MB 15 GB Windows 7[9] (2009) 1 GHz 1 GB 16 GB Apple's iTunes has been accused of being bloated as part of its efforts to turn it from a program that plays media to an e-commerce and advertising platform,[10][11] with former PC World editor Ed Bott, author of 25 books on Microsoft Windows and Office[12], accusing the company of hypocrisy in its advertising attacks on Windows for similar practices.[13]Microsoft Windows has also been criticized as being bloated - with reference to Windows Vista, Microsoft engineer Eric Traut commented that "A lot of people think of Windows as this large, bloated operating system, and that's maybe a fair characterization, I have to admit. ... But at its core, the kernel, and the components that make up the very core of the operating system, is actually pretty streamlined." [14][15] Former PC World editor Ed Bott has expressed skepticism, noting that almost every single operating system that Microsoft has ever sold had been criticized as 'bloated' when it first came out; even those now regarded as the exact opposite, such as MS-DOS.[16]CD- and DVD-burning applications such as Nero Burning ROM have become criticized for being bloated.[17] Superfluous features not specifically tailored to the end user are sometimes installed by default through express setups.A number of technology blogs have also covered the issue of increased bloatware on cell phones. However, they refer to a different issue, specifically that of wireless carriers loading phones with software that, in many cases, cannot be easily deleted, if at all. This has been most frequently cited with respect to Android devices, although this phenomenon exists on phones running many other operating systems.[18][19][edit] Alternatives to software bloatSome applications, such as Mozilla Firefox and Winamp, package additional functionality in plug-ins, extensions or add-ons which are downloaded separately from the main application. These can be created by the software developer and often by third parties. Plug-ins enable extra functionality which might have otherwise been packaged in the main program.Allowing extensions reduces the space used on any one machine, because even though the application plus the "plug-in interface" plus all the plug-ins is larger than the same functionality compiled into one monolithic application, it allows each user to install only the particular add-on features required by that user, rather than force every user to install a much larger monolithic application that includes 100% of the available features.Open source software may use a similar technique using preprocessor directives to selectively include features at compile time. This is easier to implement than a plugin system, but has the disadvantage that a user who wants a specific set of features must compile the program from source.Sometimes software becomes bloated because of "creeping featurism"[20] (Zawinski's Law of Software Envelopment), also called bullet-point engineering. One way to reduce that kind of bloat is described by the Unix philosophy: "Write programs that do one thing and do it well".[edit] See alsoCode bloatComputing minimalismFeature creepZawinski's Law of Software EnvelopmentBullet-point engineeringEnhanced remake
- Software bloat From Wikipedia, the free encyclopedia[edit] CausesSoftware developers involved in the industry during the 1970s had severe limitations on disk space and memory. Every byte and clock cycle counted, and much work went into fitting the programs into available resources. Achieving this efficiency was one of the highest values of computer programmers, and the best programs were often called "elegant;" —seen as a form of high art.This situation has now reversed. Resources are perceived as cheap, and rapidity of coding and headline features for marketing are seen as priorities.[1] In part, this is because technological advances have since increased processing capacity and storage density by orders of magnitude, while reducing the relative costs by similar orders of magnitude (see Moore's Law). Additionally, the spread of computers through all levels of business and home life has produced a software industry many times larger than it was in the 1970s. Programs are now usually churned out by teams, directed by committees in software factories where each programmer works on only a part of the whole, on one or more subroutine. Thus today; the highest value is often the adherence to a predetermined structure that makes it compliant, —with subroutines as interchangeable as piston rods. Inelegant, even sloppy code is to some degree hidden from the end users by the increasing brute force and speed of modern computers. (There is little payoff to say, ...increase the speed of a sloppy five-millisecond subroutine —even by a factor of 100.)Finally, software development tools and approaches often result in changes throughout a program to accommodate each feature, leading to a large-scale inclusion of code which affects the main operation of the software, and is required in order to support functions that themselves may be only rarely used. In particular, the advances in resources available have led to tools which allow easier development of code, again; with less priority given to end efficiency.Another cause of bloat is independently competing standards and products, which can create a demand for integration. There are now more operating systems, browsers, protocols, and storage formats than there were before, causing bloat in programs due to interoperability issues. For example, a program that once could only save in text format is now demanded to save in HTML, XML, XLS, CSV, PDF, DOC, and other formats.Niklaus Wirth has summed up the situation in Wirth's Law, which states that software speed is decreasing more quickly than hardware speed is increasing.In his 2001 essay Strategy Letter IV: Bloatware and the 80/20 Myth,[2]Joel Spolsky argues that while 80% of the users only use 20% of the features (a variant on the Pareto principle), each one uses different features. Thus, "lite" software editions turn out to be useless for most, as they miss the one or two special features that are present in the "bloated" version. Spolsky sums the article with a quote by Jamie Zawinski referring to the Mozilla Application Suite (which later became Netscape):"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. But being a shining jewel of perfection was not a goal when we wrote Mozilla."[3]Software bloat may also be a symptom of the second-system effect, described by Fred Brooks in The Mythical Man-Month.[edit] ExamplesComparison of Microsoft Windows minimum hardware requirements (for x86 versions). Windows version Processor Memory Hard disk Windows 95[4] 25 MHz 4 MB ~50 MB Windows 98[5] 66 MHz 16 MB ~200 MB Windows 2000[6] 133 MHz 32 MB 650 MB Windows XP[7] (2001) 233 MHz 64 MB 1.5 GB Windows Vista[8] (2007) 800 MHz 512 MB 15 GB Windows 7[9] (2009) 1 GHz 1 GB 16 GB Apple's iTunes has been accused of being bloated as part of its efforts to turn it from a program that plays media to an e-commerce and advertising platform,[10][11] with former PC World editor Ed Bott, author of 25 books on Microsoft Windows and Office[12], accusing the company of hypocrisy in its advertising attacks on Windows for similar practices.[13]Microsoft Windows has also been criticized as being bloated - with reference to Windows Vista, Microsoft engineer Eric Traut commented that "A lot of people think of Windows as this large, bloated operating system, and that's maybe a fair characterization, I have to admit. ... But at its core, the kernel, and the components that make up the very core of the operating system, is actually pretty streamlined." [14][15] Former PC World editor Ed Bott has expressed skepticism, noting that almost every single operating system that Microsoft has ever sold had been criticized as 'bloated' when it first came out; even those now regarded as the exact opposite, such as MS-DOS.[16]CD- and DVD-burning applications such as Nero Burning ROM have become criticized for being bloated.[17] Superfluous features not specifically tailored to the end user are sometimes installed by default through express setups.A number of technology blogs have also covered the issue of increased bloatware on cell phones. However, they refer to a different issue, specifically that of wireless carriers loading phones with software that, in many cases, cannot be easily deleted, if at all. This has been most frequently cited with respect to Android devices, although this phenomenon exists on phones running many other operating systems.[18][19][edit] Alternatives to software bloatSome applications, such as Mozilla Firefox and Winamp, package additional functionality in plug-ins, extensions or add-ons which are downloaded separately from the main application. These can be created by the software developer and often by third parties. Plug-ins enable extra functionality which might have otherwise been packaged in the main program.Allowing extensions reduces the space used on any one machine, because even though the application plus the "plug-in interface" plus all the plug-ins is larger than the same functionality compiled into one monolithic application, it allows each user to install only the particular add-on features required by that user, rather than force every user to install a much larger monolithic application that includes 100% of the available features.Open source software may use a similar technique using preprocessor directives to selectively include features at compile time. This is easier to implement than a plugin system, but has the disadvantage that a user who wants a specific set of features must compile the program from source.Sometimes software becomes bloated because of "creeping featurism"[20] (Zawinski's Law of Software Envelopment), also called bullet-point engineering. One way to reduce that kind of bloat is described by the Unix philosophy: "Write programs that do one thing and do it well".[edit] See alsoCode bloatComputing minimalismFeature creepZawinski's Law of Software EnvelopmentBullet-point engineeringEnhanced remake
- Software bloat From Wikipedia, the free encyclopedia[edit] CausesSoftware developers involved in the industry during the 1970s had severe limitations on disk space and memory. Every byte and clock cycle counted, and much work went into fitting the programs into available resources. Achieving this efficiency was one of the highest values of computer programmers, and the best programs were often called "elegant;" —seen as a form of high art.This situation has now reversed. Resources are perceived as cheap, and rapidity of coding and headline features for marketing are seen as priorities.[1] In part, this is because technological advances have since increased processing capacity and storage density by orders of magnitude, while reducing the relative costs by similar orders of magnitude (see Moore's Law). Additionally, the spread of computers through all levels of business and home life has produced a software industry many times larger than it was in the 1970s. Programs are now usually churned out by teams, directed by committees in software factories where each programmer works on only a part of the whole, on one or more subroutine. Thus today; the highest value is often the adherence to a predetermined structure that makes it compliant, —with subroutines as interchangeable as piston rods. Inelegant, even sloppy code is to some degree hidden from the end users by the increasing brute force and speed of modern computers. (There is little payoff to say, ...increase the speed of a sloppy five-millisecond subroutine —even by a factor of 100.)Finally, software development tools and approaches often result in changes throughout a program to accommodate each feature, leading to a large-scale inclusion of code which affects the main operation of the software, and is required in order to support functions that themselves may be only rarely used. In particular, the advances in resources available have led to tools which allow easier development of code, again; with less priority given to end efficiency.Another cause of bloat is independently competing standards and products, which can create a demand for integration. There are now more operating systems, browsers, protocols, and storage formats than there were before, causing bloat in programs due to interoperability issues. For example, a program that once could only save in text format is now demanded to save in HTML, XML, XLS, CSV, PDF, DOC, and other formats.Niklaus Wirth has summed up the situation in Wirth's Law, which states that software speed is decreasing more quickly than hardware speed is increasing.In his 2001 essay Strategy Letter IV: Bloatware and the 80/20 Myth,[2]Joel Spolsky argues that while 80% of the users only use 20% of the features (a variant on the Pareto principle), each one uses different features. Thus, "lite" software editions turn out to be useless for most, as they miss the one or two special features that are present in the "bloated" version. Spolsky sums the article with a quote by Jamie Zawinski referring to the Mozilla Application Suite (which later became Netscape):"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. But being a shining jewel of perfection was not a goal when we wrote Mozilla."[3]Software bloat may also be a symptom of the second-system effect, described by Fred Brooks in The Mythical Man-Month.[edit] ExamplesComparison of Microsoft Windows minimum hardware requirements (for x86 versions). Windows version Processor Memory Hard disk Windows 95[4] 25 MHz 4 MB ~50 MB Windows 98[5] 66 MHz 16 MB ~200 MB Windows 2000[6] 133 MHz 32 MB 650 MB Windows XP[7] (2001) 233 MHz 64 MB 1.5 GB Windows Vista[8] (2007) 800 MHz 512 MB 15 GB Windows 7[9] (2009) 1 GHz 1 GB 16 GB Apple's iTunes has been accused of being bloated as part of its efforts to turn it from a program that plays media to an e-commerce and advertising platform,[10][11] with former PC World editor Ed Bott, author of 25 books on Microsoft Windows and Office[12], accusing the company of hypocrisy in its advertising attacks on Windows for similar practices.[13]Microsoft Windows has also been criticized as being bloated - with reference to Windows Vista, Microsoft engineer Eric Traut commented that "A lot of people think of Windows as this large, bloated operating system, and that's maybe a fair characterization, I have to admit. ... But at its core, the kernel, and the components that make up the very core of the operating system, is actually pretty streamlined." [14][15] Former PC World editor Ed Bott has expressed skepticism, noting that almost every single operating system that Microsoft has ever sold had been criticized as 'bloated' when it first came out; even those now regarded as the exact opposite, such as MS-DOS.[16]CD- and DVD-burning applications such as Nero Burning ROM have become criticized for being bloated.[17] Superfluous features not specifically tailored to the end user are sometimes installed by default through express setups.A number of technology blogs have also covered the issue of increased bloatware on cell phones. However, they refer to a different issue, specifically that of wireless carriers loading phones with software that, in many cases, cannot be easily deleted, if at all. This has been most frequently cited with respect to Android devices, although this phenomenon exists on phones running many other operating systems.[18][19][edit] Alternatives to software bloatSome applications, such as Mozilla Firefox and Winamp, package additional functionality in plug-ins, extensions or add-ons which are downloaded separately from the main application. These can be created by the software developer and often by third parties. Plug-ins enable extra functionality which might have otherwise been packaged in the main program.Allowing extensions reduces the space used on any one machine, because even though the application plus the "plug-in interface" plus all the plug-ins is larger than the same functionality compiled into one monolithic application, it allows each user to install only the particular add-on features required by that user, rather than force every user to install a much larger monolithic application that includes 100% of the available features.Open source software may use a similar technique using preprocessor directives to selectively include features at compile time. This is easier to implement than a plugin system, but has the disadvantage that a user who wants a specific set of features must compile the program from source.Sometimes software becomes bloated because of "creeping featurism"[20] (Zawinski's Law of Software Envelopment), also called bullet-point engineering. One way to reduce that kind of bloat is described by the Unix philosophy: "Write programs that do one thing and do it well".[edit] See alsoCode bloatComputing minimalismFeature creepZawinski's Law of Software EnvelopmentBullet-point engineeringEnhanced remake
- Software bloat From Wikipedia, the free encyclopedia[edit] CausesSoftware developers involved in the industry during the 1970s had severe limitations on disk space and memory. Every byte and clock cycle counted, and much work went into fitting the programs into available resources. Achieving this efficiency was one of the highest values of computer programmers, and the best programs were often called "elegant;" —seen as a form of high art.This situation has now reversed. Resources are perceived as cheap, and rapidity of coding and headline features for marketing are seen as priorities.[1] In part, this is because technological advances have since increased processing capacity and storage density by orders of magnitude, while reducing the relative costs by similar orders of magnitude (see Moore's Law). Additionally, the spread of computers through all levels of business and home life has produced a software industry many times larger than it was in the 1970s. Programs are now usually churned out by teams, directed by committees in software factories where each programmer works on only a part of the whole, on one or more subroutine. Thus today; the highest value is often the adherence to a predetermined structure that makes it compliant, —with subroutines as interchangeable as piston rods. Inelegant, even sloppy code is to some degree hidden from the end users by the increasing brute force and speed of modern computers. (There is little payoff to say, ...increase the speed of a sloppy five-millisecond subroutine —even by a factor of 100.)Finally, software development tools and approaches often result in changes throughout a program to accommodate each feature, leading to a large-scale inclusion of code which affects the main operation of the software, and is required in order to support functions that themselves may be only rarely used. In particular, the advances in resources available have led to tools which allow easier development of code, again; with less priority given to end efficiency.Another cause of bloat is independently competing standards and products, which can create a demand for integration. There are now more operating systems, browsers, protocols, and storage formats than there were before, causing bloat in programs due to interoperability issues. For example, a program that once could only save in text format is now demanded to save in HTML, XML, XLS, CSV, PDF, DOC, and other formats.Niklaus Wirth has summed up the situation in Wirth's Law, which states that software speed is decreasing more quickly than hardware speed is increasing.In his 2001 essay Strategy Letter IV: Bloatware and the 80/20 Myth,[2]Joel Spolsky argues that while 80% of the users only use 20% of the features (a variant on the Pareto principle), each one uses different features. Thus, "lite" software editions turn out to be useless for most, as they miss the one or two special features that are present in the "bloated" version. Spolsky sums the article with a quote by Jamie Zawinski referring to the Mozilla Application Suite (which later became Netscape):"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. But being a shining jewel of perfection was not a goal when we wrote Mozilla."[3]Software bloat may also be a symptom of the second-system effect, described by Fred Brooks in The Mythical Man-Month.[edit] ExamplesComparison of Microsoft Windows minimum hardware requirements (for x86 versions). Windows version Processor Memory Hard disk Windows 95[4] 25 MHz 4 MB ~50 MB Windows 98[5] 66 MHz 16 MB ~200 MB Windows 2000[6] 133 MHz 32 MB 650 MB Windows XP[7] (2001) 233 MHz 64 MB 1.5 GB Windows Vista[8] (2007) 800 MHz 512 MB 15 GB Windows 7[9] (2009) 1 GHz 1 GB 16 GB Apple's iTunes has been accused of being bloated as part of its efforts to turn it from a program that plays media to an e-commerce and advertising platform,[10][11] with former PC World editor Ed Bott, author of 25 books on Microsoft Windows and Office[12], accusing the company of hypocrisy in its advertising attacks on Windows for similar practices.[13]Microsoft Windows has also been criticized as being bloated - with reference to Windows Vista, Microsoft engineer Eric Traut commented that "A lot of people think of Windows as this large, bloated operating system, and that's maybe a fair characterization, I have to admit. ... But at its core, the kernel, and the components that make up the very core of the operating system, is actually pretty streamlined." [14][15] Former PC World editor Ed Bott has expressed skepticism, noting that almost every single operating system that Microsoft has ever sold had been criticized as 'bloated' when it first came out; even those now regarded as the exact opposite, such as MS-DOS.[16]CD- and DVD-burning applications such as Nero Burning ROM have become criticized for being bloated.[17] Superfluous features not specifically tailored to the end user are sometimes installed by default through express setups.A number of technology blogs have also covered the issue of increased bloatware on cell phones. However, they refer to a different issue, specifically that of wireless carriers loading phones with software that, in many cases, cannot be easily deleted, if at all. This has been most frequently cited with respect to Android devices, although this phenomenon exists on phones running many other operating systems.[18][19][edit] Alternatives to software bloatSome applications, such as Mozilla Firefox and Winamp, package additional functionality in plug-ins, extensions or add-ons which are downloaded separately from the main application. These can be created by the software developer and often by third parties. Plug-ins enable extra functionality which might have otherwise been packaged in the main program.Allowing extensions reduces the space used on any one machine, because even though the application plus the "plug-in interface" plus all the plug-ins is larger than the same functionality compiled into one monolithic application, it allows each user to install only the particular add-on features required by that user, rather than force every user to install a much larger monolithic application that includes 100% of the available features.Open source software may use a similar technique using preprocessor directives to selectively include features at compile time. This is easier to implement than a plugin system, but has the disadvantage that a user who wants a specific set of features must compile the program from source.Sometimes software becomes bloated because of "creeping featurism"[20] (Zawinski's Law of Software Envelopment), also called bullet-point engineering. One way to reduce that kind of bloat is described by the Unix philosophy: "Write programs that do one thing and do it well".[edit] See alsoCode bloatComputing minimalismFeature creepZawinski's Law of Software EnvelopmentBullet-point engineeringEnhanced remake
- Abstraction inversion From Wikipedia, the free encyclopediaJump to: navigation, searchThis article may contain excessive, poor or irrelevant examples. You can improve the article by adding more descriptive text and removing less pertinent examples. See Wikipedia's guide to writing better articles for further suggestions. This article may contain original research. Please improve it by verifying the claims made and adding references. Statements consisting only of original research may be removed. More details may be available on the talk page. (May 2009) In computer programming, abstraction inversion is an anti-pattern arising when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.Possible ill-effects are:The user of such a re-implemented function may seriously underestimate its running-costs.The user of the construct is forced to obscure his implementation with complex mechanical details.Many users attempt to solve the same problem, increasing the risk of error.Contents [hide] 1 Abstraction inversion in practice2 Examples3 See also4 References5 External links[edit] Abstraction inversion in practiceThis unreferenced section requires citations to ensure verifiability. Ways to avoid this anti-pattern include:For designers of lower-level software: If your system offers formally equivalent functions, choose carefully which to implement in terms of the other.Do not force unnecessarily weak constructs on your users.For implementers of higher-level software: Choose your infrastructure carefully.[edit] ExamplesAlleged examples from professional programming circles include:In Ada, choice of the rendezvous construct as a synchronisation primitive forced programmers to implement simpler constructs such as semaphores on the more complex basis.[1]In Applesoft BASIC, integer arithmetic was implemented on top of floating-point arithmetic, and there were no bitwise operators and no support for blitting of raster graphics (even though the language supported vector graphics on the Apple II's raster hardware). This caused games and other programs written in BASIC to run more slowly.Like Applesoft BASIC, Lua has a floating-point type as its sole numeric type[2] when configured for desktop computers,[3] though it has no bitwise operators.A body of opinion holds the microkernel design to be an abstraction inversion (see the links). It is interesting that microkernels are also alleged to commit the design error of oversimplifying the components so as to overcomplicate their relationships.[4][5]Creating an object to represent a function is cumbersome in object-oriented languages such as Java and C++, in which functions are not first-class objects. In C++ it is possible to make an object 'callable' by overloading the () operator, but it is still often necessary to implement a new class, such as the Functors in the STL.Tom Lord has suggested that Subversion version control system pays for the abstraction inversion of implementing a write-only database on a read/write database with poor performance.[6]Examples that are common outside professional programming circles include:Using spreadsheet lookup functions to replicate the functionality of a databaseUsing variant data types as loop counters in Microsoft Visual Basic where an integer type is also available.[edit] See alsoLeaky abstraction
- Abstraction inversion From Wikipedia, the free encyclopediaJump to: navigation, searchThis article may contain excessive, poor or irrelevant examples. You can improve the article by adding more descriptive text and removing less pertinent examples. See Wikipedia's guide to writing better articles for further suggestions. This article may contain original research. Please improve it by verifying the claims made and adding references. Statements consisting only of original research may be removed. More details may be available on the talk page. (May 2009) In computer programming, abstraction inversion is an anti-pattern arising when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.Possible ill-effects are:The user of such a re-implemented function may seriously underestimate its running-costs.The user of the construct is forced to obscure his implementation with complex mechanical details.Many users attempt to solve the same problem, increasing the risk of error.Contents [hide] 1 Abstraction inversion in practice2 Examples3 See also4 References5 External links[edit] Abstraction inversion in practiceThis unreferenced section requires citations to ensure verifiability. Ways to avoid this anti-pattern include:For designers of lower-level software: If your system offers formally equivalent functions, choose carefully which to implement in terms of the other.Do not force unnecessarily weak constructs on your users.For implementers of higher-level software: Choose your infrastructure carefully.[edit] ExamplesAlleged examples from professional programming circles include:In Ada, choice of the rendezvous construct as a synchronisation primitive forced programmers to implement simpler constructs such as semaphores on the more complex basis.[1]In Applesoft BASIC, integer arithmetic was implemented on top of floating-point arithmetic, and there were no bitwise operators and no support for blitting of raster graphics (even though the language supported vector graphics on the Apple II's raster hardware). This caused games and other programs written in BASIC to run more slowly.Like Applesoft BASIC, Lua has a floating-point type as its sole numeric type[2] when configured for desktop computers,[3] though it has no bitwise operators.A body of opinion holds the microkernel design to be an abstraction inversion (see the links). It is interesting that microkernels are also alleged to commit the design error of oversimplifying the components so as to overcomplicate their relationships.[4][5]Creating an object to represent a function is cumbersome in object-oriented languages such as Java and C++, in which functions are not first-class objects. In C++ it is possible to make an object 'callable' by overloading the () operator, but it is still often necessary to implement a new class, such as the Functors in the STL.Tom Lord has suggested that Subversion version control system pays for the abstraction inversion of implementing a write-only database on a read/write database with poor performance.[6]Examples that are common outside professional programming circles include:Using spreadsheet lookup functions to replicate the functionality of a databaseUsing variant data types as loop counters in Microsoft Visual Basic where an integer type is also available.[edit] See alsoLeaky abstraction
- Big ball of mud From Wikipedia, the free encyclopediaJump to: navigation, searchA big ball of mud is a software system that lacks a perceivable architecture. Although undesirable from an engineering point of view, such systems are common in practice due to business pressures and developer turnover. They have therefore been declared a design anti-pattern.Contents1 In computer programs2 In programming languages3 See also4 Notes5 ReferencesIn computer programsThe term was popularized in Brian Foote and Joseph Yoder's 1997 paper of the same name, which defines the term thus:“ A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.” —Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997"Big ball of mud" systems have usually been developed over a long period of time, with different individuals working on various pieces and parts. Systems developed by people with no formal architecture or programming training often fall into this pattern.Foote and Yoder do not universally condemn "big ball of mud" programming, pointing out that this pattern is most prevalent because it works — at least at the moment it is developed. However, programs of this pattern become maintenance nightmares.Programmers in control of a big ball of mud project are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it. Technology shifts – such as client-server to web-based or file-based to database-based – may provide good reasons to start over from scratch.In programming languagesIn discussion of the Lisp programming language the term big ball of mud is used differently, in this case to describe the malleability of a Lisp system. In Lisp, it is generally possible to:Easily write macros that give you control over the language syntax, so that the notation looks closer to the problem's domainUse a data-directed programming styleExecute parts of a program at compile time rather than runtimeSave a system image of a modified Lisp implementation for future useThe programming language Forth has also been described as a ball of mud because it too has many of these properties.Joel Moses may have coined the phrase in the 1970s:[1]"APL is like a beautiful diamond - flawless, beautifully symmetrical. But you can't add anything to it. If you try to glue on another diamond, you don't get a bigger diamond. Lisp is like a ball of mud. Add more and it's still a ball of mud - it still looks like Lisp." Joel Moses strongly denies saying this, claiming he instead called Lisp a bean bag because it always returns to its original shape.[2]See alsoDesign patternSpaghetti codeTechnical debtDorodangoNotes^Richard P. Gabriel and Guy L. Steele (1996). "The Evolution of Lisp". ACM History of programming languages—II28 (3): 233–330. doi:10.1145/155360.155373.^ Thomas J. Bergin and Richard J. Gibson (1996). "Supplemental material from HOPL II". ACM SIGPLAN Notices: 9–20. doi:10.1145/240964.1198155.ReferencesGuy L. Steele, Jr. & Richard P. Gabriel The Evolution of Lisp[1], note on reference 128Brian Foote and Joseph Yoder, Big Ball of Mud Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997
- Gold plating (software engineering) From Wikipedia, the free encyclopedia (Redirected from Gold plating (analogy))Jump to: navigation, searchGold plating in software engineering (or time management in general) refers to continuing to work on a project or task well past the point where the extra effort is worth the value it adds (if any). After having met the requirements, the developer works on further enhancing the product, thinking the customer would be delighted to see additional or more polished features, rather than what was asked for or expected. The customer might be disappointed in the results, and the extra effort by the developer might be futile.[1][2][3][4][5]Gold plating is also considered as a bad project management practice for different project management best practices and methodologies such as: Project Management Body of Knowledge (PMBoK) and Prince 2. In this case, gold plating refers to the addition of any feature not considered in the original scope plan (PMBoK) or business case (Prince2) at any point of the project since it introduces a new source of risks to the original planning i.e. additional testing, documentation, costs, timelines, etc. However, gold plating does not prevent new features from being added to the project, they can be added at any time as long as they follow the official change procedure and the impact of the change in all the areas of the project is taken into consideration.See alsoSecond-system effectScope creepProject Management Body of KnowledgePrince 2
- Input kludge From Wikipedia, the free encyclopediaJump to: navigation, searchThis article does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (December 2009)This article is an orphan, as few or no other articles link to it. Please introduce links to this page from related articles; suggestions may be available. (December 2009) In computer programming, an input kludge is type of failure in software (an anti-pattern) where simple user input is not handled. For example, if a computer program accepts free text input from the user, an ad hoc algorithm will mishandle many combinations of legal and illegal input strings. Input kludges are usually difficult for a programmer to detect in a unit test, but very easy for the end user to find. The evidence exists that the end user can easily crash software that fails to correctly handle user input. Indeed, the buffer overflow security hole is an example of the problems caused.To remedy input kludges, one may use input validation algorithms to handle user input. A monkey test can be used to detect an input kludge problem. A common first test to discover this problem is to roll one's hand across the computer keyboard or to 'mash' the keyboard to produce a large junk input, but such an action often lacks reproducibility. Greater systematicity and reproducibility may be obtained by using fuzz testing software.Stovepipe system From Wikipedia, the free encyclopediaJump to: navigation, searchIn engineering and computing, a pejorative term for a system that has the potential to share data or functionality with other systems but which does not. The term evokes the image of stovepipes rising above buildings, each functioning individually. A simple example of a stovepipe system is one that implements its own user IDs and passwords, instead of relying on a common user ID and password shared with other systems.Stovepipes are "systems procured and developed to solve a specific problem, characterized by a limited focus and functionality, and containing data that cannot be easily shared with other systems."DOE 1999[1]A stovepipe system is an example of an anti-patternlegacy system and demonstrates software brittleness.
- Anemic domain model From Wikipedia, the free encyclopedia (Redirected from Anemic Domain Model)Jump to: navigation, searchThis article may be confusing or unclear to readers. Please help clarify the article; suggestions may be found on the talk page. (March 2007)Anemic domain model is a term used to describe the use of a software domain model where the business logic is implemented outside the domain objects.Contents1 Overview2 Benefit3 Liabilities4 See also5 References6 External linksOverviewThis pattern was first described by Martin Fowler, who considers the practice an anti-pattern. With this pattern, logic is typically implemented in separate classes which transform the state of the domain objects. Fowler calls such external classes transaction scripts. This pattern is a common approach in enterprise Java applications, possibly encouraged by technologies such as early versions of EJB's Entity Beans,[1] as well as in .NET applications following the Three-Layered Services Application architecture where such objects fall into the category of "Business Entities" (although Business Entities can also contain behavior).[2]BenefitClear separation between logic and data (Procedural programming).Supports the Single responsibility principle by dividing the business data (changes very seldom) from business logic (changes often). A rich domain model needs to be changed if any of them changes. The anemic domain model may separate the changes and keep the interface between the data and the domain model containing the logic stable.LiabilitiesLogic cannot be implemented in a truly object-oriented way unless wrappers are used, which hide the anemic data structure.Violation of the encapsulation and information hiding principles.Necessitates a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).Necessitates a global access to internals of shared business entities increasing coupling and fragility.Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.Necessitates a service layer when sharing domain logic across differing consumers of an object model.Makes a model less expressive and harder to understand.See alsoDomain-driven designPlain Old Java ObjectGRASP information expert, an anemic domain model is the typical result of not applying the information expert principle, i.e. you can avoid an anemic domain model by trying to assign responsibilities to the same classes that contain the dataReferences^http://www.martinfowler.com/bliki/AnemicDomainModel.html^http://msdn2.microsoft.com/en-us/library/ms954595.aspxExternal linksAnemic Domain Model by Martin FowlerThree-Layered Services ApplicationApplication Architecture for .NET: Designing Applications and Services
- Anemic domain model From Wikipedia, the free encyclopedia (Redirected from Anemic Domain Model)Jump to: navigation, searchThis article may be confusing or unclear to readers. Please help clarify the article; suggestions may be found on the talk page. (March 2007)Anemic domain model is a term used to describe the use of a software domain model where the business logic is implemented outside the domain objects.Contents1 Overview2 Benefit3 Liabilities4 See also5 References6 External linksOverviewThis pattern was first described by Martin Fowler, who considers the practice an anti-pattern. With this pattern, logic is typically implemented in separate classes which transform the state of the domain objects. Fowler calls such external classes transaction scripts. This pattern is a common approach in enterprise Java applications, possibly encouraged by technologies such as early versions of EJB's Entity Beans,[1] as well as in .NET applications following the Three-Layered Services Application architecture where such objects fall into the category of "Business Entities" (although Business Entities can also contain behavior).[2]BenefitClear separation between logic and data (Procedural programming).Supports the Single responsibility principle by dividing the business data (changes very seldom) from business logic (changes often). A rich domain model needs to be changed if any of them changes. The anemic domain model may separate the changes and keep the interface between the data and the domain model containing the logic stable.LiabilitiesLogic cannot be implemented in a truly object-oriented way unless wrappers are used, which hide the anemic data structure.Violation of the encapsulation and information hiding principles.Necessitates a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).Necessitates a global access to internals of shared business entities increasing coupling and fragility.Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.Necessitates a service layer when sharing domain logic across differing consumers of an object model.Makes a model less expressive and harder to understand.See alsoDomain-driven designPlain Old Java ObjectGRASP information expert, an anemic domain model is the typical result of not applying the information expert principle, i.e. you can avoid an anemic domain model by trying to assign responsibilities to the same classes that contain the dataReferences^http://www.martinfowler.com/bliki/AnemicDomainModel.html^http://msdn2.microsoft.com/en-us/library/ms954595.aspxExternal linksAnemic Domain Model by Martin FowlerThree-Layered Services ApplicationApplication Architecture for .NET: Designing Applications and Services
- Anemic domain model From Wikipedia, the free encyclopedia (Redirected from Anemic Domain Model)Jump to: navigation, searchThis article may be confusing or unclear to readers. Please help clarify the article; suggestions may be found on the talk page. (March 2007)Anemic domain model is a term used to describe the use of a software domain model where the business logic is implemented outside the domain objects.Contents1 Overview2 Benefit3 Liabilities4 See also5 References6 External linksOverviewThis pattern was first described by Martin Fowler, who considers the practice an anti-pattern. With this pattern, logic is typically implemented in separate classes which transform the state of the domain objects. Fowler calls such external classes transaction scripts. This pattern is a common approach in enterprise Java applications, possibly encouraged by technologies such as early versions of EJB's Entity Beans,[1] as well as in .NET applications following the Three-Layered Services Application architecture where such objects fall into the category of "Business Entities" (although Business Entities can also contain behavior).[2]BenefitClear separation between logic and data (Procedural programming).Supports the Single responsibility principle by dividing the business data (changes very seldom) from business logic (changes often). A rich domain model needs to be changed if any of them changes. The anemic domain model may separate the changes and keep the interface between the data and the domain model containing the logic stable.LiabilitiesLogic cannot be implemented in a truly object-oriented way unless wrappers are used, which hide the anemic data structure.Violation of the encapsulation and information hiding principles.Necessitates a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).Necessitates a global access to internals of shared business entities increasing coupling and fragility.Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.Necessitates a service layer when sharing domain logic across differing consumers of an object model.Makes a model less expressive and harder to understand.See alsoDomain-driven designPlain Old Java ObjectGRASP information expert, an anemic domain model is the typical result of not applying the information expert principle, i.e. you can avoid an anemic domain model by trying to assign responsibilities to the same classes that contain the dataReferences^http://www.martinfowler.com/bliki/AnemicDomainModel.html^http://msdn2.microsoft.com/en-us/library/ms954595.aspxExternal linksAnemic Domain Model by Martin FowlerThree-Layered Services ApplicationApplication Architecture for .NET: Designing Applications and Services
- BaseBean From Wikipedia, the free encyclopediaJump to: navigation, searchThis article has multiple issues. Please help improve it or discuss these issues on the talk page.It does not cite any references or sources. Please help improve it by adding citations to reliable sources. Tagged since December 2009.The notability of this article's subject is in question. If notability cannot be established, it may be listed for deletion or removed. Tagged since January 2009.In object-oriented programming, a BaseBean is a utility object from which concrete entities are derived (via subclassing). Proper design suggests that the inherited functionality should be provided via delegation instead. The BaseBean is an example of an anti-pattern (where the "Bean" part of the name comes from the standard Java naming convention for a generic entity object, or JavaBean).Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class. For example, an order is not a vector, although an order may contain a vector of line items.A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance. In some cases a static utility class can be created to contain necessary functionality. Object-oriented programming emphasizes that objects should be meaningful and should communicate with each other in the way that resembles the real-world entities they are emulating. A "BaseBean" is not a real-world object, nor is it descriptive. Likely, it needs to be refactored as a more meaningful class and referenced rather than extended.This pattern is somewhat related to the CallSuper anti-pattern, in which a derived class has the requirement to call into the parent class to complete its work.
- Call super From Wikipedia, the free encyclopediaJump to: navigation, searchThis article relies largely or entirely upon a single source. Please help improve this article by introducing citations to additional sources. Discussion about the problems with the sole source used may be found on the talk page. (August 2010)Call super is a code smell or anti-pattern of object-oriented programming. Call super is a design pattern in which a particular class stipulates that in a derived subclass, the user is required to override a method and call back the overridden function itself at a particular point. The overridden method may be intentionally incomplete, and reliant on the overriding method to augment its functionality in a prescribed manner. However, the fact that the language itself may not be able to enforce all conditions prescribed on this call is what makes this an anti-pattern.Contents1 Description1.1 Language variation2 Example3 ReferencesDescriptionIn object-oriented programming, users can inherit the properties and behaviour of a superclass in subclasses. A subclass can override methods of its superclass, substituting its own implementation of the method for the superclass's implementation. Sometimes the overriding method will completely replace the corresponding functionality in the superclass, while in other cases the superclass's method must still be called from the overriding method. Therefore most programming languages require that an overriding method must explicitly call the overridden method on the superclass for it to be executed.The call super anti-pattern relies on the users of an interface or framework to derive a subclass from a particular class, override a certain method and require the overridden method to call the original method from the overriding method[1]:This is often required, since the superclass must perform some setup tasks for the class or framework to work correctly, or since the superclass's main task (which is performed by this method) is only augmented by the subclass.Note that it is the requirement of calling the parent that is the anti-pattern. There are many examples in real code where the method in the subclass may still want the superclass's functionality, usually where it is only augmenting the parent functionality. If it still has to call the parent class even if it is fully replacing the functionality, we have the anti-pattern in force.A better approach to solve these issues is instead to use the template method pattern, where the superclass includes a purely abstract method that must be implemented by the subclasses and have the original method call that method[1]:Language variationThe appearance of this anti-pattern in programs is usually because few programming languages provide a feature to contractually ensure that a super method is called from a derived class. One language that does have this feature, in a quite radical fashion, is BETA. The feature is found in a limited way in for instance Java and C++, where a child class constructor always calls the parent class constructor.Languages that support before and after methods, such as Common Lisp, provide a different way to avoid this anti-pattern. The programmer can, instead of overriding the superclass's method, supply an additional method which will be executed before or after the superclass's method.ExampleSuppose there is a class for generating a report about the inventory of a video rental store. Each particular store has a different way of tabulating the videos currently available, but the algorithm for generating the final report is the same for all stores. A framework that uses the call super anti-pattern may provide the following abstract class (in C#):abstract class ReportGenerator { public virtual Report CreateReport() { // Generate the general report object // ... return new Report(...); } } A user of the class is expected to implement a subclass like this:class ConcreteReportGenerator : ReportGenerator { public override Report CreateReport() { // Tabulate data in the store-specific way // ... // Design of this class requires the parent CreateReport() function to be called at the // end of the overridden function. But note this line could easily be left out, or the // returned report could be further modified after the call, violating the class design // and possibly also the company-wide report format. return base.CreateReport(); } } A preferable interface looks like this:abstract class ReportGenerator { public Report CreateReport() { Tabulate(); // Generate the general report object // ... return new Report(...); } protected abstract void Tabulate(); } An implementation would override this class like this:class ConcreteReportGenerator : ReportGenerator { protected override void Tabulate() { // Tabulate data in the store-specific way // ... } } References^ abFowler, Martin. "MF Bliki: CallSuper".
- Circle-ellipse problem From Wikipedia, the free encyclopediaJump to: navigation, searchThis article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (January 2010) The circle-ellipse problem in software development (sometimes known as the square-rectangle problem) illustrates a number of pitfalls which can arise when using subtype polymorphism in object modelling. The issues are most commonly encountered when using object-oriented programming.This is the L in the acronym S.O.L.I.D. which is known as the Liskov substitution principle. This problem arises as a violation of that principle.The problem concerns which subtyping or inheritance relationship should exist between classes which represent circles and ellipses (or, similarly, squares and rectangles). More generally, the problem illustrates the difficulties which can occur when a base class contains methods which mutate an object in a manner which might invalidate a (stronger) invariant found in a derived class, causing the Liskov substitution principle to be violated.The existence of the circle-ellipse problem is sometimes used to criticize object-oriented programming. It may also imply that hierarchical taxonomies are difficult to make universal, implying that situational classification systems may be more practical.Contents1 The problem2 Possible solutions2.1 Change the model2.1.1 Return success or failure value2.1.2 Return the new value of X2.1.3 Allow for a weaker contract on Ellipse2.1.4 Convert the Circle into an Ellipse2.1.5 Make all instances constant2.1.6 Factor out modifiers2.1.7 Impose preconditions on modifiers2.1.8 Factor out common functionality into an abstract base class2.1.9 Drop all inheritance relationships2.1.10 Combine class Circle into class Ellipse2.1.11 Inverse inheritance2.2 Change the programming language2.3 Challenge the premise of the problem3 References4 External linksThe problemIt is a central tenet of object-oriented analysis and design that subtype polymorphism, which is implemented in most OO languages via inheritance, should be used to model object types which are subsets of each other; this is commonly referred to as the is-a relationship. In the present example, the set of circles is a subset of the set of ellipses; circles can be defined as ellipses whose major and minor axes are the same length. Thus, code written in an OOPL which models shapes will frequently choose to make class Circle as a sub-class of class Ellipse (i.e., inheriting from it).If the classes are immutable, there is no problem with this state of affairs. Circles satisfy all invariants of ellipses; and an (immutable) circle can be used in any context where an immutable ellipse is expected. The relationship satisfies the Liskov substitution principle. Ellipse could have a method stretchX (integer Factor) which alters the length of one of its axes, but not the other, and returns the result in a new Ellipse object. This would cause no problem for Circle.stretchX, as it could return a new Ellipse just as the Ellipse.stretchX does (whilst remaining unaltered itself).But some OO designs encourage the use of mutators, methods which modify instances of the class. A sub-class has to provide support for all behaviour supported by the super-class; subclasses must implement any mutators defined in a base class. In the present case, the method Ellipse.stretchX alters the length of one of its axes in place. If Circle inherits from Ellipse, it must also have a method stretchX, but the result of this method would be to change a circle into something which is no longer a circle. The Circle class cannot simultaneously satisfy its own invariant and the behavioural requirements of the Ellipse.stretchX method.A related problem with this inheritance arises when we consider the implementation. An ellipse requires more state to describe than a circle does, as the former needs attributes to specify the length and rotation of the major and minor axes; whereas a circle needs only a radius. It may be possible to avoid this if the language (such as Eiffel) makes constant values of a class, functions without arguments and data members interchangeable.Some authors have suggested reversing the relationship between circle and ellipse, on the grounds that an ellipse is a circle with additional capabilities. Unfortunately, ellipses fail to satisfy many of the invariants of circles; if Circle has a method radius, Ellipse will now have to provide it as well.The problem is sometimes expressed in statements such as "a Circle is not a sort of Ellipse". This looks confusingly like the absurd "a circle is not a sort of ellipse", and sounds identical, so it is unhelpful. What is actually meant is "an OO-model of a circle should not be a sort of OO-model of an ellipse"Possible solutionsOne may solve the problem by changing one's model, or perhaps using a different language, which could be a (not yet implemented) extension of an existing language, or by using a different paradigm. Exactly which option is appropriate will depend on who wrote Circle and who wrote Ellipse. If the same author is designing them both from scratch, then the author will be able to define the interface to handle this situation. If the Ellipse object was already written, and cannot be changed, then the options are more limited.Change the modelReturn success or failure valueAllow the objects to return a "success" or "failure" value for each modifier. This is usually done in the case of file I/O, but can also be helpful here. Now, Ellipse.stretchX works, and returns 'true', while Circle.stretchX simply returns 'false'. This is in general good practice, but may require that the original author of Ellipse anticipated such a problem, and defined the mutators as returning a value. In addition it requires the client code to test the return value for support of the stretch function, which in effect is just the same as testing whether the referenced object is either a circle or an ellipse. Another way of looking at this is that it is like putting in the contract that the contract may or may not be lived up to depending on the object actually implementing the interface. Eventually it is just a clever way of bypassing the Liskov constraint by just stating up-front that the post condition might or might not be valid.Alternately, Circle.stretchX could throw an exception (but depending on the language, this may also require that the original author of Ellipse declare that it may throw an exception).Return the new value of XThis is a similar solution to the above, but is slightly more powerful. Ellipse.stretchX now returns the new value of its X dimension. Now, Circle.stretchX can simply return its current radius. All modifications must be done through Circle.stretch, which preserves the circle invariant.Allow for a weaker contract on EllipseIf the interface contract for Ellipse states only that "stretchX modifies the X axis", and does not state "and nothing else will change", then Circle could simply force the X and Y dimensions to be the same. Circle.stretchX and Circle.stretchY both modify both the X and Y size.Circle::stretchX(x) {xSize = ySize = x;} Circle::stretchY(y) {xSize = ySize = y;} Convert the Circle into an EllipseIf Circle.stretchX is called, then Circle changes itself into an Ellipse. For example, in Common Lisp, this can be done via the CHANGE-CLASS method. This may be dangerous, however, if some other function is expecting it to be a Circle. Some languages don't allow this type of change at all, and others impose restrictions on the Ellipse class to be an acceptable replacement for Circle.Make all instances constantOne can change the model so that instances of the classes represent constant values (i.e. they are immutable). This is exactly the implementation that is used in purely functional programming.In this case methods such as stretchX must be changed to yield a new instance, rather than modifying the instance they act on. This means that it is no longer a problem to define Circle.stretchX, and the inheritance reflects the mathematical relationship between circles and ellipses.A disadvantage is that changing the value of an instance then requires an assignment, which is inconvenient and prone to programming errors, e.g.Orbit(planet[i]) := Orbit(planet[i]).stretchX.A second disadvantage is that such an assignment conceptually involves a temporary value, which could reduce performance and be difficult to optimise.Factor out modifiersOne can define a new class MutableEllipse, and put the modifiers from Ellipse in it. The Circle only inherits queries from Ellipse.This has a disadvantage of introducing an extra class where all we really want to do is specify that Circle does not inherit modifiers from Ellipse.Impose preconditions on modifiersOne can specify that Ellipse.stretchX is only allowed on instances satisfying Ellipse.stretchable, and will otherwise throw an exception. This requires anticipation of the problem when Ellipse is defined.Factor out common functionality into an abstract base classCreate an abstract base class called RoundObject and put methods that work with both Circles and Ellipses in this class. Functions that can deal with either type of object will expect a RoundObject, and functions that call Ellipse or Circle-specific requirements will use the descendant classes.Drop all inheritance relationshipsThis solves the problem at a stroke, and may sometimes be a reasonable approach.The disadvantage is that one can no longer use circles where ellipses are expected.However, an acceptable workaround may be to add a method Circle.toEllipse() which would instantiate and return a mutable ellipse object using the circle's current state. The caveat is that mutations performed on this new ellipse would not affect the original circle, and vice versa.Alternatively, one may provide a method Circle.asEllipse, which returns a mutable Ellipse "view" of the Circle object: an Ellipse instance initialized with the circle's current state, that "redirects" all messages to the Circle object it was obtained from. The "view" is an interface which a client that requires an ellipse may use to work with a circle, even if there is no actual subtyping relationship between the two classes. For example, the ellipse 's stretchXAxis method would be implemented to invoke stretchRadius on the Circle.Combine class Circle into class EllipseThen, wherever a circle was used before, use an ellipse.A circle can already be represented by an ellipse. There is no reason to have class Circle unless it needs some circle-specific methods that can't be applied to an ellipse, or unless the programmer wishes to benefit from conceptual and/or performance advantages of the circle's simpler model.Inverse inheritanceMajorinc proposed a model that divides methods on modifiers, selectors and general methods. Only selectors can be automatically inherited from superclass, while modifiers should be inherited from subclass to superclass. In general case, the methods must be explicitly inherited. The model can be emulated in languages with multiple inheritance, using abstract classes.[1]Change the programming languageThis problem has straightforward solutions in a sufficiently powerful OO programming system. Essentially, the Circle-Ellipse problem is one of synchronizing two representations of type: the de-facto type based on the properties of the object, and the formal type associated with the object by the object system. If these two pieces of information, which are ultimately just bits in the machine, are kept synchronized so that they say the same thing, everything is fine. It is clear that a circle cannot satisfy the invariants required of it while its base ellipse methods allow mutation of parameters. However, the possibility exists that when a circle cannot meet the circle invariants, its type can be updated so that it becomes an ellipse. If a circle which has become a de facto ellipse doesn't change type, then its type is a piece of information which is now out of date, reflecting the history of the object (how it was once constructed) and not its present reality (what it has since mutated into).Many object systems in popular use are based on a design which takes it for granted that an object carries the same type over its entire lifetime, from construction to finalization. This is not a limitation of OOP, but rather of particular implementations only.The following example uses the Common Lisp Object System (CLOS) in which objects can change class without losing their identity. All variables or other storage locations which hold a reference to an object continue to hold a reference to that same object after it changes class.The circle and ellipse models are deliberately simplified to avoid distracting details which are not relevant to the Circle-Ellipse Problem. An ellipse has two semi-axes called h-axis and v-axis in the code. Being an ellipse, a circle inherits these, and also has a radius property, whose value is equal to that of the axes (which must, of course, be equal).(defclass ellipse () ((h-axis :type real :accessor h-axis :initarg :h-axis) (v-axis :type real :accessor v-axis :initarg :v-axis))) (defclass circle (ellipse) ((radius :type real :accessor radius :initarg :radius))) ;;; ;;; A circle has a radius, but also a h-axis and v-axis that ;;; it inherits from an ellipse. These must be kept in sync ;;; with the radius when the object is initialized and ;;; when those values change. ;;; (defmethod initialize-instance ((c circle) &key radius) (setf (radius c) radius)) ;; via the setf method below (defmethod (setf radius) :after ((new-value real) (c circle)) (setf (slot-value c 'h-axis) new-value (slot-value c 'v-axis) new-value)) ;;; ;;; After an assignment is made to the circle's ;;; h-axis or v-axis, a change of type is necessary, ;;; unless the new value is the same as the radius. ;;; (defmethod (setf h-axis) :after ((new-value real) (c circle)) (unless (eql (radius c) new-value) (change-class c 'ellipse))) (defmethod (setf v-axis) :after ((new-value real) (c circle)) (unless (eql (radius c) new-value) (change-class c 'ellipse))) ;;; ;;; Ellipse changes to a circle if accessors ;;; mutate it such that the axes are equal, ;;; or if an attempt is made to construct it that way. ;;; ;;; EQL equality is used, under which 0 /= 0.0. ;;; ;;; The SUBTYPEP checks are needed because these methods ;;; apply to circles too, which are ellipses!!! ;;; (defmethod initialize-instance :after ((e ellipse) &key h-axis v-axis) (if (eql h-axis v-axis) (change-class e 'circle))) (defmethod (setf h-axis) :after ((new-value real) (e ellipse)) (unless (subtypep (class-of e) 'circle) (if (eql (h-axis e) (v-axis e)) (change-class e 'circle)))) (defmethod (setf v-axis) :after ((new-value real) (e ellipse)) (unless (subtypep (class-of e) 'circle) (if (eql (v-axis e) (v-axis e)) (change-class e 'circle)))) ;;; ;;; Method for an ellipse becoming a circle. In this metamorphosis, ;;; the object acquires a radius, which we must initialize. ;;; There is a "sanity check" here to signal an error if an attempt ;;; is made to convert an ellipse whose axes are not equal ;;; with an explicit change-class call. ;;; The handling strategy here is to just base the radius off the ;;; h-axis and signal an error. ;;; This doesn't prevent the class change; the damage is already done. ;;; (defmethod update-instance-for-different-class :after ((old-e ellipse) (new-c circle) &key) (setf (radius new-c) (h-axis old-e)) (unless (eql (h-axis old-e) (v-axis old-e)) (error "ellipse ~s can't change into a circle because it's not one!" old-e))) This code can be demonstrated with an interactive session, using the CLISP implementation of Common Lisp.$ clisp -q -i circle-ellipse.lisp [1]> (make-instance 'ellipse :v-axis 3 :h-axis 3) #<CIRCLE #x218AB566> [2]> (make-instance 'ellipse :v-axis 3 :h-axis 4) #<ELLIPSE #x218BF56E> [3]> (defvar obj (make-instance 'ellipse :v-axis 3 :h-axis 4)) OBJ [4]> (class-of obj) #<STANDARD-CLASS ELLIPSE> [5]> (radius obj) *** - NO-APPLICABLE-METHOD: When calling #<STANDARD-GENERIC-FUNCTION RADIUS> with arguments (#<ELLIPSE #x2188C5F6>), no method is applicable. The following restarts are available: RETRY :R1 try calling RADIUS again RETURN :R2 specify return values ABORT :R3 Abort main loop Break 1 [6]> :a [7]> (setf (v-axis obj) 4) 4 [8]> (radius obj) 4 [9]> (class-of obj) #<STANDARD-CLASS CIRCLE> [10]> (setf (radius obj) 9) 9 [11]> (v-axis obj) 9 [12]> (h-axis obj) 9 [13]> (setf (h-axis obj) 8) 8 [14]> (class-of obj) #<STANDARD-CLASS ELLIPSE> [15]> (radius obj) *** - NO-APPLICABLE-METHOD: When calling #<STANDARD-GENERIC-FUNCTION RADIUS> with arguments (#<ELLIPSE #x2188C5F6>), no method is applicable. The following restarts are available: RETRY :R1 try calling RADIUS again RETURN :R2 specify return values ABORT :R3 Abort main loop Break 1 [16]> :a [17]> Challenge the premise of the problemWhile at first glance it may seem obvious that a Circle is-an Ellipse, consider the following alternate representation of essentially the same problem, stated in terms of Java code.class Person { void walkNorth( int meters ) {...} // No failure or exception allowed void walkEast( int meters ) {...} // No failure or exception allowed } Now, a prisoner is obviously a person. So we could logically create a sub-class:class Prisoner extends Person { void walkNorth( int meters ) {...} // No failure or exception allowed void walkEast( int meters ) {...} // No failure or exception allowed } Just as obviously, this leads us into trouble, since a prisoner is not free to move an arbitrary distance in any direction, yet the contract of the Person class states that a Person can.So, in fact, the class Person could better be named FreePerson. If that were the case, then the idea that class Prisoner extends FreePerson is clearly wrong.By analogy, then, a Circle, is not an Ellipse, because it lacks the same degrees of freedom as an Ellipse.This strongly suggests that inheritance should never be used when the sub-class restricts the freedom implicit in the base class, but should only be used when the sub-class adds extra detail to the concept represented by the base class as in 'Monkey' is-a 'Animal'.ReferencesRobert C. Martin, The Liskov Substitution Principle, C++ Report, March 1996.^ Kazimir Majorinc, Ellipse-Circle Dilemma and Inverse Inheritance, ITI 98, Proceedings of the 20th International Conference of Information Technology Interfaces, Pula, 1998External linkshttp://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.6 A popular C++ FAQ site by Marshall Cline. States and explains the problem.Constructive Deconstruction of Subtyping by Alistair Cockburn on his own web-site. Technical/mathematical discussion of typing and subtyping, with applications to this problem.Henney, Kevlin (2003-04-15). "From Mechanism to Method: Total Ellipse". Dr. Dobb's.Date, Christopher J. (2004-06-30). "More on Type Inheritance". Database Debunkings. Retrieved 2010-01-27.http://www.dbdebunk.com/page/page/1409199.htmMore on Cure for Madness by C.J. Date from Database Debunkings 24 September 2004 Some implications of the problem for SQL.http://orafaq.com/usenet/comp.databases.theory/2001/10/01/0001.htm Beginning of a long thread (follow the Maybe reply: links) on Oracle FAQ discussing the issue. Refers to writings of C.J. Date. Some bias towards Smalltalk.LiskovSubstitutionPrinciple at WikiWikiWebSubtyping, Subclassing, and Trouble with OOP, an essay discussing a related problem, whether sets should inherit from bags.Subtyping by Constraints in Object-Oriented Databases, an essay dicussing an extended version of the circle-elipse problem in the environment of object-oriented databases.
- Circle-ellipse problem From Wikipedia, the free encyclopediaJump to: navigation, searchThis article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (January 2010) The circle-ellipse problem in software development (sometimes known as the square-rectangle problem) illustrates a number of pitfalls which can arise when using subtype polymorphism in object modelling. The issues are most commonly encountered when using object-oriented programming.This is the L in the acronym S.O.L.I.D. which is known as the Liskov substitution principle. This problem arises as a violation of that principle.The problem concerns which subtyping or inheritance relationship should exist between classes which represent circles and ellipses (or, similarly, squares and rectangles). More generally, the problem illustrates the difficulties which can occur when a base class contains methods which mutate an object in a manner which might invalidate a (stronger) invariant found in a derived class, causing the Liskov substitution principle to be violated.The existence of the circle-ellipse problem is sometimes used to criticize object-oriented programming. It may also imply that hierarchical taxonomies are difficult to make universal, implying that situational classification systems may be more practical.Contents1 The problem2 Possible solutions2.1 Change the model2.1.1 Return success or failure value2.1.2 Return the new value of X2.1.3 Allow for a weaker contract on Ellipse2.1.4 Convert the Circle into an Ellipse2.1.5 Make all instances constant2.1.6 Factor out modifiers2.1.7 Impose preconditions on modifiers2.1.8 Factor out common functionality into an abstract base class2.1.9 Drop all inheritance relationships2.1.10 Combine class Circle into class Ellipse2.1.11 Inverse inheritance2.2 Change the programming language2.3 Challenge the premise of the problem3 References4 External linksThe problemIt is a central tenet of object-oriented analysis and design that subtype polymorphism, which is implemented in most OO languages via inheritance, should be used to model object types which are subsets of each other; this is commonly referred to as the is-a relationship. In the present example, the set of circles is a subset of the set of ellipses; circles can be defined as ellipses whose major and minor axes are the same length. Thus, code written in an OOPL which models shapes will frequently choose to make class Circle as a sub-class of class Ellipse (i.e., inheriting from it).If the classes are immutable, there is no problem with this state of affairs. Circles satisfy all invariants of ellipses; and an (immutable) circle can be used in any context where an immutable ellipse is expected. The relationship satisfies the Liskov substitution principle. Ellipse could have a method stretchX (integer Factor) which alters the length of one of its axes, but not the other, and returns the result in a new Ellipse object. This would cause no problem for Circle.stretchX, as it could return a new Ellipse just as the Ellipse.stretchX does (whilst remaining unaltered itself).But some OO designs encourage the use of mutators, methods which modify instances of the class. A sub-class has to provide support for all behaviour supported by the super-class; subclasses must implement any mutators defined in a base class. In the present case, the method Ellipse.stretchX alters the length of one of its axes in place. If Circle inherits from Ellipse, it must also have a method stretchX, but the result of this method would be to change a circle into something which is no longer a circle. The Circle class cannot simultaneously satisfy its own invariant and the behavioural requirements of the Ellipse.stretchX method.A related problem with this inheritance arises when we consider the implementation. An ellipse requires more state to describe than a circle does, as the former needs attributes to specify the length and rotation of the major and minor axes; whereas a circle needs only a radius. It may be possible to avoid this if the language (such as Eiffel) makes constant values of a class, functions without arguments and data members interchangeable.Some authors have suggested reversing the relationship between circle and ellipse, on the grounds that an ellipse is a circle with additional capabilities. Unfortunately, ellipses fail to satisfy many of the invariants of circles; if Circle has a method radius, Ellipse will now have to provide it as well.The problem is sometimes expressed in statements such as "a Circle is not a sort of Ellipse". This looks confusingly like the absurd "a circle is not a sort of ellipse", and sounds identical, so it is unhelpful. What is actually meant is "an OO-model of a circle should not be a sort of OO-model of an ellipse"Possible solutionsOne may solve the problem by changing one's model, or perhaps using a different language, which could be a (not yet implemented) extension of an existing language, or by using a different paradigm. Exactly which option is appropriate will depend on who wrote Circle and who wrote Ellipse. If the same author is designing them both from scratch, then the author will be able to define the interface to handle this situation. If the Ellipse object was already written, and cannot be changed, then the options are more limited.Change the modelReturn success or failure valueAllow the objects to return a "success" or "failure" value for each modifier. This is usually done in the case of file I/O, but can also be helpful here. Now, Ellipse.stretchX works, and returns 'true', while Circle.stretchX simply returns 'false'. This is in general good practice, but may require that the original author of Ellipse anticipated such a problem, and defined the mutators as returning a value. In addition it requires the client code to test the return value for support of the stretch function, which in effect is just the same as testing whether the referenced object is either a circle or an ellipse. Another way of looking at this is that it is like putting in the contract that the contract may or may not be lived up to depending on the object actually implementing the interface. Eventually it is just a clever way of bypassing the Liskov constraint by just stating up-front that the post condition might or might not be valid.Alternately, Circle.stretchX could throw an exception (but depending on the language, this may also require that the original author of Ellipse declare that it may throw an exception).Return the new value of XThis is a similar solution to the above, but is slightly more powerful. Ellipse.stretchX now returns the new value of its X dimension. Now, Circle.stretchX can simply return its current radius. All modifications must be done through Circle.stretch, which preserves the circle invariant.Allow for a weaker contract on EllipseIf the interface contract for Ellipse states only that "stretchX modifies the X axis", and does not state "and nothing else will change", then Circle could simply force the X and Y dimensions to be the same. Circle.stretchX and Circle.stretchY both modify both the X and Y size.Circle::stretchX(x) {xSize = ySize = x;} Circle::stretchY(y) {xSize = ySize = y;} Convert the Circle into an EllipseIf Circle.stretchX is called, then Circle changes itself into an Ellipse. For example, in Common Lisp, this can be done via the CHANGE-CLASS method. This may be dangerous, however, if some other function is expecting it to be a Circle. Some languages don't allow this type of change at all, and others impose restrictions on the Ellipse class to be an acceptable replacement for Circle.Make all instances constantOne can change the model so that instances of the classes represent constant values (i.e. they are immutable). This is exactly the implementation that is used in purely functional programming.In this case methods such as stretchX must be changed to yield a new instance, rather than modifying the instance they act on. This means that it is no longer a problem to define Circle.stretchX, and the inheritance reflects the mathematical relationship between circles and ellipses.A disadvantage is that changing the value of an instance then requires an assignment, which is inconvenient and prone to programming errors, e.g.Orbit(planet[i]) := Orbit(planet[i]).stretchX.A second disadvantage is that such an assignment conceptually involves a temporary value, which could reduce performance and be difficult to optimise.Factor out modifiersOne can define a new class MutableEllipse, and put the modifiers from Ellipse in it. The Circle only inherits queries from Ellipse.This has a disadvantage of introducing an extra class where all we really want to do is specify that Circle does not inherit modifiers from Ellipse.Impose preconditions on modifiersOne can specify that Ellipse.stretchX is only allowed on instances satisfying Ellipse.stretchable, and will otherwise throw an exception. This requires anticipation of the problem when Ellipse is defined.Factor out common functionality into an abstract base classCreate an abstract base class called RoundObject and put methods that work with both Circles and Ellipses in this class. Functions that can deal with either type of object will expect a RoundObject, and functions that call Ellipse or Circle-specific requirements will use the descendant classes.Drop all inheritance relationshipsThis solves the problem at a stroke, and may sometimes be a reasonable approach.The disadvantage is that one can no longer use circles where ellipses are expected.However, an acceptable workaround may be to add a method Circle.toEllipse() which would instantiate and return a mutable ellipse object using the circle's current state. The caveat is that mutations performed on this new ellipse would not affect the original circle, and vice versa.Alternatively, one may provide a method Circle.asEllipse, which returns a mutable Ellipse "view" of the Circle object: an Ellipse instance initialized with the circle's current state, that "redirects" all messages to the Circle object it was obtained from. The "view" is an interface which a client that requires an ellipse may use to work with a circle, even if there is no actual subtyping relationship between the two classes. For example, the ellipse 's stretchXAxis method would be implemented to invoke stretchRadius on the Circle.Combine class Circle into class EllipseThen, wherever a circle was used before, use an ellipse.A circle can already be represented by an ellipse. There is no reason to have class Circle unless it needs some circle-specific methods that can't be applied to an ellipse, or unless the programmer wishes to benefit from conceptual and/or performance advantages of the circle's simpler model.Inverse inheritanceMajorinc proposed a model that divides methods on modifiers, selectors and general methods. Only selectors can be automatically inherited from superclass, while modifiers should be inherited from subclass to superclass. In general case, the methods must be explicitly inherited. The model can be emulated in languages with multiple inheritance, using abstract classes.[1]Change the programming languageThis problem has straightforward solutions in a sufficiently powerful OO programming system. Essentially, the Circle-Ellipse problem is one of synchronizing two representations of type: the de-facto type based on the properties of the object, and the formal type associated with the object by the object system. If these two pieces of information, which are ultimately just bits in the machine, are kept synchronized so that they say the same thing, everything is fine. It is clear that a circle cannot satisfy the invariants required of it while its base ellipse methods allow mutation of parameters. However, the possibility exists that when a circle cannot meet the circle invariants, its type can be updated so that it becomes an ellipse. If a circle which has become a de facto ellipse doesn't change type, then its type is a piece of information which is now out of date, reflecting the history of the object (how it was once constructed) and not its present reality (what it has since mutated into).Many object systems in popular use are based on a design which takes it for granted that an object carries the same type over its entire lifetime, from construction to finalization. This is not a limitation of OOP, but rather of particular implementations only.The following example uses the Common Lisp Object System (CLOS) in which objects can change class without losing their identity. All variables or other storage locations which hold a reference to an object continue to hold a reference to that same object after it changes class.The circle and ellipse models are deliberately simplified to avoid distracting details which are not relevant to the Circle-Ellipse Problem. An ellipse has two semi-axes called h-axis and v-axis in the code. Being an ellipse, a circle inherits these, and also has a radius property, whose value is equal to that of the axes (which must, of course, be equal).(defclass ellipse () ((h-axis :type real :accessor h-axis :initarg :h-axis) (v-axis :type real :accessor v-axis :initarg :v-axis))) (defclass circle (ellipse) ((radius :type real :accessor radius :initarg :radius))) ;;; ;;; A circle has a radius, but also a h-axis and v-axis that ;;; it inherits from an ellipse. These must be kept in sync ;;; with the radius when the object is initialized and ;;; when those values change. ;;; (defmethod initialize-instance ((c circle) &key radius) (setf (radius c) radius)) ;; via the setf method below (defmethod (setf radius) :after ((new-value real) (c circle)) (setf (slot-value c 'h-axis) new-value (slot-value c 'v-axis) new-value)) ;;; ;;; After an assignment is made to the circle's ;;; h-axis or v-axis, a change of type is necessary, ;;; unless the new value is the same as the radius. ;;; (defmethod (setf h-axis) :after ((new-value real) (c circle)) (unless (eql (radius c) new-value) (change-class c 'ellipse))) (defmethod (setf v-axis) :after ((new-value real) (c circle)) (unless (eql (radius c) new-value) (change-class c 'ellipse))) ;;; ;;; Ellipse changes to a circle if accessors ;;; mutate it such that the axes are equal, ;;; or if an attempt is made to construct it that way. ;;; ;;; EQL equality is used, under which 0 /= 0.0. ;;; ;;; The SUBTYPEP checks are needed because these methods ;;; apply to circles too, which are ellipses!!! ;;; (defmethod initialize-instance :after ((e ellipse) &key h-axis v-axis) (if (eql h-axis v-axis) (change-class e 'circle))) (defmethod (setf h-axis) :after ((new-value real) (e ellipse)) (unless (subtypep (class-of e) 'circle) (if (eql (h-axis e) (v-axis e)) (change-class e 'circle)))) (defmethod (setf v-axis) :after ((new-value real) (e ellipse)) (unless (subtypep (class-of e) 'circle) (if (eql (v-axis e) (v-axis e)) (change-class e 'circle)))) ;;; ;;; Method for an ellipse becoming a circle. In this metamorphosis, ;;; the object acquires a radius, which we must initialize. ;;; There is a "sanity check" here to signal an error if an attempt ;;; is made to convert an ellipse whose axes are not equal ;;; with an explicit change-class call. ;;; The handling strategy here is to just base the radius off the ;;; h-axis and signal an error. ;;; This doesn't prevent the class change; the damage is already done. ;;; (defmethod update-instance-for-different-class :after ((old-e ellipse) (new-c circle) &key) (setf (radius new-c) (h-axis old-e)) (unless (eql (h-axis old-e) (v-axis old-e)) (error "ellipse ~s can't change into a circle because it's not one!" old-e))) This code can be demonstrated with an interactive session, using the CLISP implementation of Common Lisp.$ clisp -q -i circle-ellipse.lisp [1]> (make-instance 'ellipse :v-axis 3 :h-axis 3) #<CIRCLE #x218AB566> [2]> (make-instance 'ellipse :v-axis 3 :h-axis 4) #<ELLIPSE #x218BF56E> [3]> (defvar obj (make-instance 'ellipse :v-axis 3 :h-axis 4)) OBJ [4]> (class-of obj) #<STANDARD-CLASS ELLIPSE> [5]> (radius obj) *** - NO-APPLICABLE-METHOD: When calling #<STANDARD-GENERIC-FUNCTION RADIUS> with arguments (#<ELLIPSE #x2188C5F6>), no method is applicable. The following restarts are available: RETRY :R1 try calling RADIUS again RETURN :R2 specify return values ABORT :R3 Abort main loop Break 1 [6]> :a [7]> (setf (v-axis obj) 4) 4 [8]> (radius obj) 4 [9]> (class-of obj) #<STANDARD-CLASS CIRCLE> [10]> (setf (radius obj) 9) 9 [11]> (v-axis obj) 9 [12]> (h-axis obj) 9 [13]> (setf (h-axis obj) 8) 8 [14]> (class-of obj) #<STANDARD-CLASS ELLIPSE> [15]> (radius obj) *** - NO-APPLICABLE-METHOD: When calling #<STANDARD-GENERIC-FUNCTION RADIUS> with arguments (#<ELLIPSE #x2188C5F6>), no method is applicable. The following restarts are available: RETRY :R1 try calling RADIUS again RETURN :R2 specify return values ABORT :R3 Abort main loop Break 1 [16]> :a [17]> Challenge the premise of the problemWhile at first glance it may seem obvious that a Circle is-an Ellipse, consider the following alternate representation of essentially the same problem, stated in terms of Java code.class Person { void walkNorth( int meters ) {...} // No failure or exception allowed void walkEast( int meters ) {...} // No failure or exception allowed } Now, a prisoner is obviously a person. So we could logically create a sub-class:class Prisoner extends Person { void walkNorth( int meters ) {...} // No failure or exception allowed void walkEast( int meters ) {...} // No failure or exception allowed } Just as obviously, this leads us into trouble, since a prisoner is not free to move an arbitrary distance in any direction, yet the contract of the Person class states that a Person can.So, in fact, the class Person could better be named FreePerson. If that were the case, then the idea that class Prisoner extends FreePerson is clearly wrong.By analogy, then, a Circle, is not an Ellipse, because it lacks the same degrees of freedom as an Ellipse.This strongly suggests that inheritance should never be used when the sub-class restricts the freedom implicit in the base class, but should only be used when the sub-class adds extra detail to the concept represented by the base class as in 'Monkey' is-a 'Animal'.ReferencesRobert C. Martin, The Liskov Substitution Principle, C++ Report, March 1996.^ Kazimir Majorinc, Ellipse-Circle Dilemma and Inverse Inheritance, ITI 98, Proceedings of the 20th International Conference of Information Technology Interfaces, Pula, 1998External linkshttp://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.6 A popular C++ FAQ site by Marshall Cline. States and explains the problem.Constructive Deconstruction of Subtyping by Alistair Cockburn on his own web-site. Technical/mathematical discussion of typing and subtyping, with applications to this problem.Henney, Kevlin (2003-04-15). "From Mechanism to Method: Total Ellipse". Dr. Dobb's.Date, Christopher J. (2004-06-30). "More on Type Inheritance". Database Debunkings. Retrieved 2010-01-27.http://www.dbdebunk.com/page/page/1409199.htmMore on Cure for Madness by C.J. Date from Database Debunkings 24 September 2004 Some implications of the problem for SQL.http://orafaq.com/usenet/comp.databases.theory/2001/10/01/0001.htm Beginning of a long thread (follow the Maybe reply: links) on Oracle FAQ discussing the issue. Refers to writings of C.J. Date. Some bias towards Smalltalk.LiskovSubstitutionPrinciple at WikiWikiWebSubtyping, Subclassing, and Trouble with OOP, an essay discussing a related problem, whether sets should inherit from bags.Subtyping by Constraints in Object-Oriented Databases, an essay dicussing an extended version of the circle-elipse problem in the environment of object-oriented databases.
- Circular dependency From Wikipedia, the free encyclopediaJump to: navigation, searchThis article may be confusing or unclear to readers. Please help clarify the article; suggestions may be found on the talk page. (December 2006) In software engineering, a circular dependency is a relation between two or more modules which either directly or indirectly depend on each other to function properly.Contents1 Overview2 Problems of circular dependencies3 Causes and solutions4 Example of circular dependencies in C++4.1 Self-reference example5 References6 External linksOverviewCircular dependencies are natural in many domain models where certain objects of the same domain depend on each other. However, in software design circular dependencies between larger software modules are considered an anti-pattern because of their negative effects.Problems of circular dependenciesCircular dependencies can cause many unwanted effects in software programs. Most problematic from a software design point of view is the tight coupling of the mutually dependent modules which reduces or makes impossible the separate re-use of a single module.Circular dependencies can cause a domino effect when a small local change in one module spreads into other modules and has unwanted global effects (program errors, compile errors). Circular dependencies can also result in infinite recursions or other unexpected failures.Circular dependencies may also cause memory leaks by preventing certain very primitive automatic garbage collectors (those that use reference counting) from deallocating unused objects.Causes and solutionsIn very large software designs, software engineers may lose the context and inadvertently introduce circular dependencies. There are tools to analyze software and find unwanted circular dependencies[1][2].Circular dependencies are often introduced by inexperienced programmers who need to implement some kind of callback functionality. Experienced programmers avoid such unnecessary circular dependencies by applying design patterns like the observer pattern.Example of circular dependencies in C++Implementation of circular dependencies in C/C++ can be a bit tricky, because any class or structure definition must be placed above its usage in the same file. A circular dependency between classes A and B will thus both require the definition of A to be placed above B, and the definition of B to be placed above A, which of course is impossible. A forward declaration trick is therefore needed to accomplish this.The following example illustrates how this is done.File a.h:#ifndef A_H #define A_H class B; //forward declaration class A { public: B* b; }; #endif //A_H File b.h:#ifndef B_H #define B_H class A; //forward declaration class B { public: A* a; }; #endif //B_H File main.cpp:#include "a.h" #include "b.h" int main() { A a; B b; a.b = &b; b.a = &a; } Note that although a name (e.g. A) can be declared multiple times, such as in forward declarations, it can only be defined once (the One Definition Rule).Self-reference exampleThis section contains instructions, advice, or how-to content. The purpose of Wikipedia is to present facts, not to train. Please help improve this article either by rewriting the how-to content or by moving it to Wikiversity or Wikibooks. (October 2009) Following is another example of forward declaration, which might be useful if the application needs a self-sustaining array of objects which is able to add and remove objects from itself during run-time:File a.h:class A { public: static A *first, *last; A *previous, *next; A(); ~A(); }; The static variables first and last have to be defined, because their declaration does not reserve memory space for them. Note: static variables do not change from object to object and stay the same for this given class.They should also be initialized to 0, or NULL, so we know what they are to start with.File a.cpp:#include "a.h" A *A::first=0, *A::last=0; // don't put the word static here, that will cause an error A::A() { if(first==0) first=this; //first A created previous=last; if(previous != 0) previous->next=this; last=this; next=0; } A::~A() { if(previous != 0) previous->next=next; if(next != 0) next->previous=previous; } References^JDepend for Java^Code Analysis Plugin (CAP) for JavaExternal linksThe Circular Dependency Rule : Abstract definition as applied to Symbolic Model Verification languageWhy Are Circular Dependencies Considered Harmful? : On stackoverflow.com
- Circular dependency From Wikipedia, the free encyclopediaJump to: navigation, searchThis article may be confusing or unclear to readers. Please help clarify the article; suggestions may be found on the talk page. (December 2006) In software engineering, a circular dependency is a relation between two or more modules which either directly or indirectly depend on each other to function properly.Contents1 Overview2 Problems of circular dependencies3 Causes and solutions4 Example of circular dependencies in C++4.1 Self-reference example5 References6 External linksOverviewCircular dependencies are natural in many domain models where certain objects of the same domain depend on each other. However, in software design circular dependencies between larger software modules are considered an anti-pattern because of their negative effects.Problems of circular dependenciesCircular dependencies can cause many unwanted effects in software programs. Most problematic from a software design point of view is the tight coupling of the mutually dependent modules which reduces or makes impossible the separate re-use of a single module.Circular dependencies can cause a domino effect when a small local change in one module spreads into other modules and has unwanted global effects (program errors, compile errors). Circular dependencies can also result in infinite recursions or other unexpected failures.Circular dependencies may also cause memory leaks by preventing certain very primitive automatic garbage collectors (those that use reference counting) from deallocating unused objects.Causes and solutionsIn very large software designs, software engineers may lose the context and inadvertently introduce circular dependencies. There are tools to analyze software and find unwanted circular dependencies[1][2].Circular dependencies are often introduced by inexperienced programmers who need to implement some kind of callback functionality. Experienced programmers avoid such unnecessary circular dependencies by applying design patterns like the observer pattern.Example of circular dependencies in C++Implementation of circular dependencies in C/C++ can be a bit tricky, because any class or structure definition must be placed above its usage in the same file. A circular dependency between classes A and B will thus both require the definition of A to be placed above B, and the definition of B to be placed above A, which of course is impossible. A forward declaration trick is therefore needed to accomplish this.The following example illustrates how this is done.File a.h:#ifndef A_H #define A_H class B; //forward declaration class A { public: B* b; }; #endif //A_H File b.h:#ifndef B_H #define B_H class A; //forward declaration class B { public: A* a; }; #endif //B_H File main.cpp:#include "a.h" #include "b.h" int main() { A a; B b; a.b = &b; b.a = &a; } Note that although a name (e.g. A) can be declared multiple times, such as in forward declarations, it can only be defined once (the One Definition Rule).Self-reference exampleThis section contains instructions, advice, or how-to content. The purpose of Wikipedia is to present facts, not to train. Please help improve this article either by rewriting the how-to content or by moving it to Wikiversity or Wikibooks. (October 2009) Following is another example of forward declaration, which might be useful if the application needs a self-sustaining array of objects which is able to add and remove objects from itself during run-time:File a.h:class A { public: static A *first, *last; A *previous, *next; A(); ~A(); }; The static variables first and last have to be defined, because their declaration does not reserve memory space for them. Note: static variables do not change from object to object and stay the same for this given class.They should also be initialized to 0, or NULL, so we know what they are to start with.File a.cpp:#include "a.h" A *A::first=0, *A::last=0; // don't put the word static here, that will cause an error A::A() { if(first==0) first=this; //first A created previous=last; if(previous != 0) previous->next=this; last=this; next=0; } A::~A() { if(previous != 0) previous->next=next; if(next != 0) next->previous=previous; } References^JDepend for Java^Code Analysis Plugin (CAP) for JavaExternal linksThe Circular Dependency Rule : Abstract definition as applied to Symbolic Model Verification languageWhy Are Circular Dependencies Considered Harmful? : On stackoverflow.com
- Constant interface From Wikipedia, the free encyclopediaJump to: navigation, searchIn the Java programming language, the constant interface pattern describes the use of an interface solely to define constants, and having classes implement that interface in order to achieve convenient syntactic access to those constants. However, since constants are very often merely an implementation detail, and the interfaces implemented by a class are part of its exported API, this practice amounts to putting implementations details into the API, which is considered inappropriate. [1][2] In general, collecting system constants into classes independent of behaviour, might create a poor object-oriented design, because it is often a sign of low cohesion. It is for these reasons that implementing constants interfaces is considered to be an anti-pattern.Use of this anti-pattern has a few other downsides:It pollutes the class namespace with read-only variables that may not be of use.Contrary to the compile-time tactical utility of implementing a constants interface, the incidental run-time artifacts have little practical purpose (cf. marker interfaces which also have no methods but are useful at run-time).If binary code compatibility is required in future releases, the constants interface must remain forever an interface (it cannot be converted into a class), even though it has not been used as an interface in the conventional sense.Without an IDE that resolves where the constant are coming from, tracking it back to its containing class or interface can be time consuming.A variable (representing an instance) of the interface is syntactically no more useful than the interface name itself (since it has no methods).Examplepublic interface Constants { public static final double PI = 3.14159; public static final double PLANCK_CONSTANT = 6.62606896e-34; } public class Calculations implements Constants { public double getReducedPlanckConstant() { return PLANCK_CONSTANT / (2 * PI); } } AlternativesMany of the pitfalls of the anti-pattern can be avoided by converting the constants interface to a proper class with no instances:public final class Constants { private Constants() { // restrict instantiation } public static final double PI = 3.14159; public static final double PLANCK_CONSTANT = 6.62606896e-34; } This still leaves the original intent of the pattern mostly un-addressed (i.e. there is no syntax for accessing the constants unqualified). However, since Java 5, consider using static import[2] to achieve the same goal:import static Constants.PLANCK_CONSTANT; import static Constants.PI; public class Calculations { public double getReducedPlanckConstant() { return PLANCK_CONSTANT / (2 * PI); } } To varying degrees, the issues listed above have now been addressed:Because static members can be imported specifically, the class namespace need not be polluted with all members of the constants interface.Run-time and compile-time semantics are more closely aligned when using static imports instead of constants interfaces.The compiled code has one less binary compatibility constraint (that "class Calculations implements Constants").Because static imports apply only to the current file (and not the whole class hierarchy) it is easier to discover where each static member is declared.There is less need to declare variables of the constants interface type, and it is potentially clearer that no concrete instances actually exist.Note however, the changes do nothing to improve the cohesion of the Constants class, so static imports should not be considered to be a panacea.References^ Bloch, Joshua, Effective Java, 2nd Edition, p. 98^ ab Sun Microsystems, Inc. (2004). "Static Import".
- Constant interface From Wikipedia, the free encyclopediaJump to: navigation, searchIn the Java programming language, the constant interface pattern describes the use of an interface solely to define constants, and having classes implement that interface in order to achieve convenient syntactic access to those constants. However, since constants are very often merely an implementation detail, and the interfaces implemented by a class are part of its exported API, this practice amounts to putting implementations details into the API, which is considered inappropriate. [1][2] In general, collecting system constants into classes independent of behaviour, might create a poor object-oriented design, because it is often a sign of low cohesion. It is for these reasons that implementing constants interfaces is considered to be an anti-pattern.Use of this anti-pattern has a few other downsides:It pollutes the class namespace with read-only variables that may not be of use.Contrary to the compile-time tactical utility of implementing a constants interface, the incidental run-time artifacts have little practical purpose (cf. marker interfaces which also have no methods but are useful at run-time).If binary code compatibility is required in future releases, the constants interface must remain forever an interface (it cannot be converted into a class), even though it has not been used as an interface in the conventional sense.Without an IDE that resolves where the constant are coming from, tracking it back to its containing class or interface can be time consuming.A variable (representing an instance) of the interface is syntactically no more useful than the interface name itself (since it has no methods).Examplepublic interface Constants { public static final double PI = 3.14159; public static final double PLANCK_CONSTANT = 6.62606896e-34; } public class Calculations implements Constants { public double getReducedPlanckConstant() { return PLANCK_CONSTANT / (2 * PI); } } AlternativesMany of the pitfalls of the anti-pattern can be avoided by converting the constants interface to a proper class with no instances:public final class Constants { private Constants() { // restrict instantiation } public static final double PI = 3.14159; public static final double PLANCK_CONSTANT = 6.62606896e-34; } This still leaves the original intent of the pattern mostly un-addressed (i.e. there is no syntax for accessing the constants unqualified). However, since Java 5, consider using static import[2] to achieve the same goal:import static Constants.PLANCK_CONSTANT; import static Constants.PI; public class Calculations { public double getReducedPlanckConstant() { return PLANCK_CONSTANT / (2 * PI); } } To varying degrees, the issues listed above have now been addressed:Because static members can be imported specifically, the class namespace need not be polluted with all members of the constants interface.Run-time and compile-time semantics are more closely aligned when using static imports instead of constants interfaces.The compiled code has one less binary compatibility constraint (that "class Calculations implements Constants").Because static imports apply only to the current file (and not the whole class hierarchy) it is easier to discover where each static member is declared.There is less need to declare variables of the constants interface type, and it is potentially clearer that no concrete instances actually exist.Note however, the changes do nothing to improve the cohesion of the Constants class, so static imports should not be considered to be a panacea.References^ Bloch, Joshua, Effective Java, 2nd Edition, p. 98^ ab Sun Microsystems, Inc. (2004). "Static Import".
- God object From Wikipedia, the free encyclopediaJump to: navigation, searchThis article includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. Please improve this article by introducing more precise citations. (March 2012)This article should be divided into sections by topic, to make it more accessible. Please help by adding section headings in accordance with Wikipedia's Manual of Style. (March 2012) In object-oriented programming, a God object is an object that knows too much or does too much. The God object is an example of an anti-pattern.The basic idea behind structured programming is that a big problem is broken down into several smaller problems (a divide and conquer strategy) and solutions are created for each of them. Once the small problems have been solved, the big problem as a whole has been solved. Therefore there is only one object about which an object needs to know everything: itself. Likewise, there is only one set of problems an object needs to solve: its own.God object–based code does not follow this approach. Instead, most of a program's overall functionality is coded into a single "all-knowing" object, which maintains most of the information about the entire program and provides most of the methods for manipulating this data. Because this object holds so much data and requires so many methods, its role in the program becomes God-like (all-encompassing). Instead of program objects communicating amongst themselves directly, the other objects within the program rely on the God object for most of their information and interaction. Since the God object is referenced by so much of the other code, maintenance becomes more difficult than it would in a more evenly divided programming design.A God object is the object-oriented analogue of failing to use subroutines in procedural programming languages, or of using far too many global variables to store state information.While creating a God object is typically considered bad programming practice, this technique is occasionally used for tight programming environments (such as microcontrollers), where the slight performance increase and centralization of control is more important than maintainability and programming elegance.See alsoRavioli code, the opposite patternFurther readingRiel, Arthur J. (1996). "Chapter 3: Topologies of Action-Oriented Vs. Object-Oriented Applications". Object-Oriented Design Heuristics. Boston, MA: Addison-Wesley. ISBN 020163385X. "3.2: Do not create god classes/objects in your system. Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem."Anti-Patterns and Worst Practices – Monster Objects
- God object From Wikipedia, the free encyclopediaJump to: navigation, searchThis article includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. Please improve this article by introducing more precise citations. (March 2012)This article should be divided into sections by topic, to make it more accessible. Please help by adding section headings in accordance with Wikipedia's Manual of Style. (March 2012) In object-oriented programming, a God object is an object that knows too much or does too much. The God object is an example of an anti-pattern.The basic idea behind structured programming is that a big problem is broken down into several smaller problems (a divide and conquer strategy) and solutions are created for each of them. Once the small problems have been solved, the big problem as a whole has been solved. Therefore there is only one object about which an object needs to know everything: itself. Likewise, there is only one set of problems an object needs to solve: its own.God object–based code does not follow this approach. Instead, most of a program's overall functionality is coded into a single "all-knowing" object, which maintains most of the information about the entire program and provides most of the methods for manipulating this data. Because this object holds so much data and requires so many methods, its role in the program becomes God-like (all-encompassing). Instead of program objects communicating amongst themselves directly, the other objects within the program rely on the God object for most of their information and interaction. Since the God object is referenced by so much of the other code, maintenance becomes more difficult than it would in a more evenly divided programming design.A God object is the object-oriented analogue of failing to use subroutines in procedural programming languages, or of using far too many global variables to store state information.While creating a God object is typically considered bad programming practice, this technique is occasionally used for tight programming environments (such as microcontrollers), where the slight performance increase and centralization of control is more important than maintainability and programming elegance.See alsoRavioli code, the opposite patternFurther readingRiel, Arthur J. (1996). "Chapter 3: Topologies of Action-Oriented Vs. Object-Oriented Applications". Object-Oriented Design Heuristics. Boston, MA: Addison-Wesley. ISBN 020163385X. "3.2: Do not create god classes/objects in your system. Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem."Anti-Patterns and Worst Practices – Monster Objects
- PitfallsWhen writing an object pool, the programmer has to be careful to make sure the state of the objects returned to the pool is reset back to a sensible state for the next use of the object. If this is not observed, the object will often be in some state that was unexpected by the client program and may cause the client program to fail. The pool is responsible for resetting the objects, not the clients. Object pools full of objects with dangerously stale state are sometimes called object cesspools and regarded as an anti-pattern.The presence of stale state is not always an issue; it becomes dangerous when the presence of stale state causes the object to behave differently. For example, an object that represents authentication details may break if the "successfully authenticated" flag is not reset before it is passed out, since it will indicate that a user is correctly authenticated (possibly as someone else) when they haven't yet attempted to authenticate. However, it will work just fine if you fail to reset some value only used for debugging, such as the identity of the last authentication server used.Inadequate resetting of objects may also cause an information leak. If an object contains confidential data (e.g. a user's credit card numbers) that isn't cleared before the object is passed to a new client, a malicious or buggy client may disclose the data to an unauthorized party.If the pool is used by multiple threads, it may need means to prevent parallel threads from grabbing and trying to reuse the same object in parallel. This is not necessary if the pooled objects are immutable or otherwise thread-safe.
- Sequential coupling From Wikipedia, the free encyclopediaJump to: navigation, searchIn object-oriented programming, sequential coupling refers to a class that requires its methods to be called in a particular sequence. This may be an anti-pattern, depending on context.Methods whose name starts with Init, Begin, Start, etc. may indicate the existence of sequential coupling.Using a car as an analogy, if the user steps on the gas without first starting the engine, the car does not crash, fail, or throw an exception - it simply fails to accelerate.Side Note: Exceptions are acceptable some of the time because programs (especially large ones) need the feedback to determine why an object is not performing the expected behavior when one of its methods is called. Object initialization is not always possible at construction and may need to be delayed to a later time. The programmer using a class may not be the same programmer who wrote it.Sequential coupling can be refactored with the Template method pattern to overcome the problems posed by the usage of this anti-pattern.[1]References^ Andriy, Buday. "Refactor: Sequential Coupling => Template Method". The Code Project. Retrieved 23 April 2011.
- Yo-yo problem From Wikipedia, the free encyclopediaJump to: navigation, searchThis article does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (July 2009) In computer science, the yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.Most practices of object-oriented programming recommend keeping the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once.More generally, the yo-yo problem can also refer to any situation where a person must keep flipping between different sources of information in order to understand a concept. See Design Patterns, Chapter 1 summary, for additional information.Object-oriented design techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.See alsoComplexity What it means for a system (of any sort) to be complexHrair limit The suggestion that humans can entertain at most approximately seven concepts at onceImplementation inheritanceInheritance semanticsVirtual Inheritance (object-oriented programming)The Magical Number Seven, Plus or Minus Two From Wikipedia, the free encyclopedia (Redirected from Hrair limit)Jump to: navigation, searchThis article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (April 2012)[1]"The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"[2] is one of the most highly cited papers in psychology.[3][4][5] It was published in 1956 by the cognitive psychologistGeorge A. Miller of Princeton University's Department of Psychology in Psychological Review. It supposedly[clarification needed] argues that the number of objects an average human can hold in working memory is 7 ± 2. This is frequently referred to as Miller's Law.Recent research has demonstrated that not only is the "law" based on a misinterpretation of Miller's paper, but that the correct number is probably around three or four.[6]Contents1 Miller's article2 The "magical number 7" and working memory capacity3 Other cognitive numeric limits4 See also5 References6 External linksMiller's articleIn his article, Miller discussed a coincidence between the limits of one-dimensional absolute judgment and the limits of short-term memory. In a one-dimensional absolute-judgment task, a person is presented with a number of stimuli that vary on one dimension (e.g., 10 different tones varying only in pitch) and responds to each stimulus with a corresponding response (learned before). Performance is nearly perfect up to 5 or 6 different stimuli but declines as the number of different stimuli is increased. The task can be described as one of information transmission: The input consists of one out of n possible stimuli, and the output consists of one out of n responses. The information contained in the input can be determined by the number of binary decisions that need to be made to arrive at the selected stimulus, and the same holds for the response. Therefore, people's maximum performance on one-dimensional absolute judgement can be characterized as an information channel capacity with approximately 2 to 3 bits of information, which corresponds to the ability to distinguish between 4 and 8 alternatives.The second cognitive limitation Miller discusses is memory span. Memory span refers to the longest list of items (e.g., digits, letters, words) that a person can repeat back immediately after presentation in correct order on 50% of trials. Miller observed that memory span of young adults is approximately 7 items. He noticed that memory span is approximately the same for stimuli with vastly different amount of information - for instance, binary digits have 1 bit each; decimal digits have 3.32 bits each; words have about 10 bits each. Miller concluded that memory span is not limited in terms of bits but rather in terms of chunks. A chunk is the largest meaningful unit in the presented material that the person recognizes - thus, it depends on the knowledge of the person what counts as a chunk. For instance, a word is a single chunk for a speaker of the language but breaks down into as many chunks as the word has letters for someone who is totally unfamiliar with the language.Miller recognized that the correspondence between the limits of one-dimensional absolute judgment and of short-term memory span was only a coincidence, because only the first limit, not the second, can be characterized in information-theoretic terms (i.e., as a roughly constant number of bits). Therefore, there is nothing "magical" about the number 7, and Miller used the expression only rhetorically. Nevertheless, the idea of a "magical number 7" inspired much theorizing, rigorous and less rigorous, about the capacity limits of human cognition.The "magical number 7" and working memory capacitySee also: Working memory capacityLater research on short-term memory and working memory revealed that memory span is not a constant even when measured in a number of chunks. The number of chunks a human can recall immediately after presentation depends on the category of chunks used (e.g., span is around seven for digits, around six for letters, and around five for words), and even on features of the chunks within a category. Chunking is used by the brain’s short-term memory as a method for keeping groups of information accessible for easy recall. It functions and works best as labels that one is already familiar with – the incorporation of new information into a label that is already well rehearsed into one’s long-term memory. These chunks must store the information in such a way that they can be disassembled into the necessary data.[7] The storage capacity is dependent on the information being stored. For instance, span is lower for long words than it is for short words. In general, memory span for verbal contents (digits, letters, words, etc.) strongly depends on the time it takes to speak the contents aloud. Some researchers have therefore proposed that the limited capacity of short-term memory for verbal material is not a "magic number" but rather a "magic spell".[8] Baddeley used this finding to postulate that one component of his model of working memory, the phonological loop, is capable of holding around 2 seconds of sound.[9][10] However, the limit of short-term memory cannot easily be characterized as a constant "magic spell" either, because memory span depends also on other factors besides speaking duration. For instance, span depends on the lexical status of the contents (i.e., whether the contents are words known to the person or not).[11] Several other factors also affect a person's measured span, and therefore it is difficult to pin down the capacity of short-term or working memory to a number of chunks. Nonetheless, Cowan (2001)[12] has proposed that working memory has a capacity of about four chunks in young adults (and less in children and older adults).[citation needed]Tarnow (2010) finds that in a classic experiment typically argued as supporting a 4 item buffer by Murdock (1962),[citation needed] there is in fact no evidence for such and thus the "magical number", at least in the Murdock experiment, is 1.[citation needed]Other cognitive numeric limitsCowan also noted a number of other limits of cognition that point to a "magical number four",[12] and different from Miller, he argued that this correspondence is no coincidence. One other process that seems to be limited at about four elements is subitizing, the rapid enumeration of small numbers of objects. When a number of objects is flashed briefly, their number can be determined very quickly, at a glance, when the number does not exceed the subitizing limit, which is about four objects. Larger numbers of objects must be counted, which is a slower process. The film Rain Man portrayed an autistic savant, who was able to rapidly determine the number of toothpicks from an entire box spilled on the floor, apparently subitizing a much larger number than four objects. A similar feat was informally observed by neuropsychologistOliver Sacks and reported in his book The Man Who Mistook His Wife for a Hat. (Autistic expert Daniel Tammet has suggested that the children Sacks observed may have pre-counted the matches in the box.) Therefore one might suppose that this limit is an arbitrary limit imposed by our cognition rather than necessarily being a physical limit. There is also evidence that even four chunks is a high estimate: Gobet and Clarkson conducted an experiment and found that over half of the memory recall conditions yielded only about two chunks. Research also shows that the size, rather than the number, of chunks that are stored in short-term memory is what allows for enhanced memory in individuals. [13][original research?]See also7 (number)Baddeley's model of working memoryChunking (psychology)Free recallFitts's lawHick's lawSubitizingWorking memory
- Yo-yo problem From Wikipedia, the free encyclopediaJump to: navigation, searchThis article does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (July 2009) In computer science, the yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.Most practices of object-oriented programming recommend keeping the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once.More generally, the yo-yo problem can also refer to any situation where a person must keep flipping between different sources of information in order to understand a concept. See Design Patterns, Chapter 1 summary, for additional information.Object-oriented design techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.See alsoComplexity What it means for a system (of any sort) to be complexHrair limit The suggestion that humans can entertain at most approximately seven concepts at onceImplementation inheritanceInheritance semanticsVirtual Inheritance (object-oriented programming)The Magical Number Seven, Plus or Minus Two From Wikipedia, the free encyclopedia (Redirected from Hrair limit)Jump to: navigation, searchThis article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (April 2012)[1]"The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"[2] is one of the most highly cited papers in psychology.[3][4][5] It was published in 1956 by the cognitive psychologistGeorge A. Miller of Princeton University's Department of Psychology in Psychological Review. It supposedly[clarification needed] argues that the number of objects an average human can hold in working memory is 7 ± 2. This is frequently referred to as Miller's Law.Recent research has demonstrated that not only is the "law" based on a misinterpretation of Miller's paper, but that the correct number is probably around three or four.[6]Contents1 Miller's article2 The "magical number 7" and working memory capacity3 Other cognitive numeric limits4 See also5 References6 External linksMiller's articleIn his article, Miller discussed a coincidence between the limits of one-dimensional absolute judgment and the limits of short-term memory. In a one-dimensional absolute-judgment task, a person is presented with a number of stimuli that vary on one dimension (e.g., 10 different tones varying only in pitch) and responds to each stimulus with a corresponding response (learned before). Performance is nearly perfect up to 5 or 6 different stimuli but declines as the number of different stimuli is increased. The task can be described as one of information transmission: The input consists of one out of n possible stimuli, and the output consists of one out of n responses. The information contained in the input can be determined by the number of binary decisions that need to be made to arrive at the selected stimulus, and the same holds for the response. Therefore, people's maximum performance on one-dimensional absolute judgement can be characterized as an information channel capacity with approximately 2 to 3 bits of information, which corresponds to the ability to distinguish between 4 and 8 alternatives.The second cognitive limitation Miller discusses is memory span. Memory span refers to the longest list of items (e.g., digits, letters, words) that a person can repeat back immediately after presentation in correct order on 50% of trials. Miller observed that memory span of young adults is approximately 7 items. He noticed that memory span is approximately the same for stimuli with vastly different amount of information - for instance, binary digits have 1 bit each; decimal digits have 3.32 bits each; words have about 10 bits each. Miller concluded that memory span is not limited in terms of bits but rather in terms of chunks. A chunk is the largest meaningful unit in the presented material that the person recognizes - thus, it depends on the knowledge of the person what counts as a chunk. For instance, a word is a single chunk for a speaker of the language but breaks down into as many chunks as the word has letters for someone who is totally unfamiliar with the language.Miller recognized that the correspondence between the limits of one-dimensional absolute judgment and of short-term memory span was only a coincidence, because only the first limit, not the second, can be characterized in information-theoretic terms (i.e., as a roughly constant number of bits). Therefore, there is nothing "magical" about the number 7, and Miller used the expression only rhetorically. Nevertheless, the idea of a "magical number 7" inspired much theorizing, rigorous and less rigorous, about the capacity limits of human cognition.The "magical number 7" and working memory capacitySee also: Working memory capacityLater research on short-term memory and working memory revealed that memory span is not a constant even when measured in a number of chunks. The number of chunks a human can recall immediately after presentation depends on the category of chunks used (e.g., span is around seven for digits, around six for letters, and around five for words), and even on features of the chunks within a category. Chunking is used by the brain’s short-term memory as a method for keeping groups of information accessible for easy recall. It functions and works best as labels that one is already familiar with – the incorporation of new information into a label that is already well rehearsed into one’s long-term memory. These chunks must store the information in such a way that they can be disassembled into the necessary data.[7] The storage capacity is dependent on the information being stored. For instance, span is lower for long words than it is for short words. In general, memory span for verbal contents (digits, letters, words, etc.) strongly depends on the time it takes to speak the contents aloud. Some researchers have therefore proposed that the limited capacity of short-term memory for verbal material is not a "magic number" but rather a "magic spell".[8] Baddeley used this finding to postulate that one component of his model of working memory, the phonological loop, is capable of holding around 2 seconds of sound.[9][10] However, the limit of short-term memory cannot easily be characterized as a constant "magic spell" either, because memory span depends also on other factors besides speaking duration. For instance, span depends on the lexical status of the contents (i.e., whether the contents are words known to the person or not).[11] Several other factors also affect a person's measured span, and therefore it is difficult to pin down the capacity of short-term or working memory to a number of chunks. Nonetheless, Cowan (2001)[12] has proposed that working memory has a capacity of about four chunks in young adults (and less in children and older adults).[citation needed]Tarnow (2010) finds that in a classic experiment typically argued as supporting a 4 item buffer by Murdock (1962),[citation needed] there is in fact no evidence for such and thus the "magical number", at least in the Murdock experiment, is 1.[citation needed]Other cognitive numeric limitsCowan also noted a number of other limits of cognition that point to a "magical number four",[12] and different from Miller, he argued that this correspondence is no coincidence. One other process that seems to be limited at about four elements is subitizing, the rapid enumeration of small numbers of objects. When a number of objects is flashed briefly, their number can be determined very quickly, at a glance, when the number does not exceed the subitizing limit, which is about four objects. Larger numbers of objects must be counted, which is a slower process. The film Rain Man portrayed an autistic savant, who was able to rapidly determine the number of toothpicks from an entire box spilled on the floor, apparently subitizing a much larger number than four objects. A similar feat was informally observed by neuropsychologistOliver Sacks and reported in his book The Man Who Mistook His Wife for a Hat. (Autistic expert Daniel Tammet has suggested that the children Sacks observed may have pre-counted the matches in the box.) Therefore one might suppose that this limit is an arbitrary limit imposed by our cognition rather than necessarily being a physical limit. There is also evidence that even four chunks is a high estimate: Gobet and Clarkson conducted an experiment and found that over half of the memory recall conditions yielded only about two chunks. Research also shows that the size, rather than the number, of chunks that are stored in short-term memory is what allows for enhanced memory in individuals. [13][original research?]See also7 (number)Baddeley's model of working memoryChunking (psychology)Free recallFitts's lawHick's lawSubitizingWorking memory