FRINK Linked Data Fragments server

Matches in SemOpenAlex for { <https://semopenalex.org/work/W2024954653> ?p ?o ?g. }

• W2024954653 endingPage "9" @default.
• W2024954653 startingPage "9" @default.
• W2024954653 abstract "ion The design technique of abstraction can be used to increase the amount of reuse within a set of classes by describing abstract classes that embody some of their shared state and/or behavior. One uses abstraction to construct a hierarchy relating several concrete classes to common abstract classes for better reuse of state and behavior. This emphasizes sharing of both state and behavior; abstract classes often implement algorithms in terms of methods that are overridden by concrete subclasses. The result of abstraction is a more horizontal hierarchy or a new protocol family. A typical abstraction example is building model graphical objects for an object-oriented drawing package. The first pass includes several concrete classes (for the different types of displayable objects). The later passes will use abstraction to reimplement these classes as a hierarchy with significant sharing among abstract and concrete classes. One would start by prototyping a wide and shallow hierarchy of DisplayItems from a collection of classes with little reuse. The first pass implements DisplayRectangle, DisplayCircle, and DisplayTriangle with common protocol but no inheritance among them and no state or behavior sharing. The second pass adds abstract class DisplayItem with position, size, and orientation instance variables and protocol for manipulation and display; concrete subclasses now inherit all their state and reuse shared protocol specification and implementations of most algorithms. The third pass refines this, adding another level of abstract modeling for line-segmentand arc-based DisplayItems; and easy extensibility is achieved. Further passes might identify Square as a special case of Rectangle and Circle as a special case of EllipticalArc. Figures 7 and 8 show three of the possible class hierarchies for DisplayItems. There are many approaches to the architecture of a framework for algorithmic composition or an algorithmic music description language. We illustrate the design as a multistep process that starts with the construction of an abstract class named EventGenerator as a subclass of EventList. Subclasses of EventGenerator should implement the message generateEvents, so we define it in the abstract class as subclassResponsibility (i.e., it is expected that subclasses will override it). The first-pass design's concrete classes are Chord (which might hold its root and its inversion), Roll (which has a single Event and can repeat it), Trill (repeat an EventList), Arpeggio (play with internote skew), Ostinato (repeat as a process), SelectorCloud (select from given pitch, amplitude, and voice sets), and PodCloud (select from given ranges). They share little state except what EventGenerator inherits by being a subclass of EventList. Several of them add instance variables to deal with their particular representations; and each implements its own generateEvents method. Shared state and behavior among EventGenerators is often not apparent until after the first implementation; and in the implementation of further subclasses, we use some of the first-pass classes as abstract intermediate classes. We try to push as much of the method implementation as possible into the abstract class EventGenerator; protocol and method implementations such as creation, accessing, and user interface can then be shared. Increased abstraction inserts abstract classes Cluster (a more general notion for chords), and Cloud (an abstract stochastic EventGenerator), and makes Trill a subclass of Roll (that repeats a collection of notes rather than just one). In Fig. 9 one can see the first-pass class diagram for EventGenerators and one of the possible abstraction-based refinements of this design. There are several trade-offs in using abstractionbased techniques. The DisplayItem and EventGenerator examples could each be used to demonstrate extremes of factorization or abstraction. Examining the construction of classes for the generation of many types of Chords, for example, one might implement a prototype that includes a class called Chord with many different methods for generating EventLists according to given rules and root" @default.
• W2024954653 created "2016-06-24" @default.
• W2024954653 creator A5080202385 @default.
• W2024954653 date "1989-01-01" @default.
• W2024954653 modified "2023-10-18" @default.
• W2024954653 title "Machine Tongues XI: Object-Oriented Software Design" @default.
• W2024954653 cites W1479691276 @default.
• W2024954653 cites W1503889120 @default.
• W2024954653 cites W1504300023 @default.
• W2024954653 cites W1513481933 @default.
• W2024954653 cites W1532944695 @default.
• W2024954653 cites W1587166076 @default.
• W2024954653 cites W1597459313 @default.
• W2024954653 cites W1717525145 @default.
• W2024954653 cites W1770006921 @default.
• W2024954653 cites W1966605479 @default.
• W2024954653 cites W1981635406 @default.
• W2024954653 cites W2001078813 @default.
• W2024954653 cites W2026310133 @default.
• W2024954653 cites W2027657506 @default.
• W2024954653 cites W2059827361 @default.
• W2024954653 cites W2070502162 @default.
• W2024954653 cites W2138387375 @default.
• W2024954653 cites W2161825580 @default.
• W2024954653 cites W2163832616 @default.
• W2024954653 cites W2401311672 @default.
• W2024954653 cites W41699526 @default.
• W2024954653 cites W54774700 @default.
• W2024954653 doi "https://doi.org/10.2307/3680037" @default.
• W2024954653 hasPublicationYear "1989" @default.
• W2024954653 type Work @default.
• W2024954653 sameAs 2024954653 @default.
• W2024954653 citedByCount "7" @default.
• W2024954653 crossrefType "journal-article" @default.
• W2024954653 hasAuthorship W2024954653A5080202385 @default.
• W2024954653 hasConcept C199360897 @default.
• W2024954653 hasConcept C2777904410 @default.
• W2024954653 hasConcept C41008148 @default.
• W2024954653 hasConcept C53073257 @default.
• W2024954653 hasConceptScore W2024954653C199360897 @default.
• W2024954653 hasConceptScore W2024954653C2777904410 @default.
• W2024954653 hasConceptScore W2024954653C41008148 @default.
• W2024954653 hasConceptScore W2024954653C53073257 @default.
• W2024954653 hasIssue "2" @default.
• W2024954653 hasLocation W20249546531 @default.
• W2024954653 hasOpenAccess W2024954653 @default.
• W2024954653 hasPrimaryLocation W20249546531 @default.
• W2024954653 hasRelatedWork W1527862632 @default.
• W2024954653 hasRelatedWork W2109507516 @default.
• W2024954653 hasRelatedWork W2112962394 @default.
• W2024954653 hasRelatedWork W2118300983 @default.
• W2024954653 hasRelatedWork W2166247150 @default.
• W2024954653 hasRelatedWork W2382501300 @default.
• W2024954653 hasRelatedWork W2740990710 @default.
• W2024954653 hasRelatedWork W3137189469 @default.
• W2024954653 hasRelatedWork W4235530921 @default.
• W2024954653 hasRelatedWork W4243252198 @default.
• W2024954653 hasVolume "13" @default.
• W2024954653 isParatext "false" @default.
• W2024954653 isRetracted "false" @default.
• W2024954653 magId "2024954653" @default.
• W2024954653 workType "article" @default.