Question confirmation: Move half-half records to 2 diff. files.
Precondition: You must be knowing how to read record.
1. Read file from top.
2. Move each record in alternative file.
Function oriented design is dividing a bigger problem set
to small functional units and then
structure/organize/sequence these functional units to
design the solution.
OOD is identifying objects (entities) involved in the
system and designing solution based on their relationships
FOD approach is mainly used for computation sensitive
application, whereas OOD approach is mainly used for
evolving system which mimicks a business process or
A design pattern is a general reusable solution to a
commonly occurring problem in software design. A design
pattern is not a finished design that can be transformed
directly into code. It is a description or template for how
to solve a problem that can be used in many different
situations. Object-oriented design patterns typically show
relationships and interactions between classes or objects,
without specifying the final application classes or objects
that are involved.
Design patterns reside in the domain of modules and
interconnections. At a higher level there are Architectural
patterns that are larger in scope, usually describing an
overall pattern followed by an entire system.
GoF DESIGN PATTERN
The Gang of Four were the first publishing a book about
design patterns. The patterns are rather basic in nature and
can be applied to almost any object oriented system.
J2EE DESIGN PATTERN
J2EE patterns are much more specialized, obviously. Many are
in fact specialized versions of GoF patterns, applied to
problems specific to J2EE development.
Architecture: Defines multi-layer design to implement a complex business solution and shows how each layer interact with each other efficiently. Depicts the different layers involved in the application. Addresses gray areas such as performance issues, high availability of the critical applications.
Design Models: Talks more about the individual components that build the complex application. It shows the relationship between these objects and how they are logically separated.
Comparing Adapter Pattern with other Patterns:
1. Adapter converts one interface to another, Decorator doesn't alter interface but adds responsibility. Facade makes an interface simpler.
Decorator is thus more transparent to the application than an adapter is. As a consequence, Decorator supports recursive composition, which isn't possible with pure Adapters.
2. Adapters allows client to make use of libraries and subsets without changing any code. Decorators allow new behaviour to be added to the classes with out altering the existing code.
3. Adapter make things work after they're designed, Bridge makes them work before they are.
4. Bridge is designed up-front to let the abstraction and the implementation vary independently. Adapter is retrofitted to make unrelated classes work together.
5. Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced interface.
6. Facade defines a new interface, whereas Adapter reuses an old interface. Remember that Adapter makes two existing interfaces work together as opposed to defining an entirely new one.
Asynchronous architectures decouple senders and receivers.
This brings about performance advantages for both the sender
and the receiver. The sender is able to even out his
communication traffic over the course of a day. This is
helpful in cases where sender and receiver communicate over
low-bandwidth lengths. The receiver can even out its
processing load by processing the sender's message as time
An application design is comprised of legacy components,
vendor products, and developmental software.
The publish/subscribe model is an approach to distributed
system communication in which publishers publish information
to a subject address and subscribers subscribe to
information at a subject address. The publish/subscribe
model has the benefit of making publishers independent of
location. This enables subscribers to subscribe to
information without having to know the location of a publisher.
Abstract parent class,
constant data manager,
chain of responsibility,
Explicit Object release
Common attribute registry
consistent lock order,
•Poor requirements - if the requirements are not clear,
unfinished, too common, and not testable, then there will
•Unrealistic schedule - if too much work is given in too
little time, problems are inevitable.
•Inadequate testing - no one will know whether or not the
program is any good until the customer complain or systems
•Futurities - requests to pile on new features after
development is underway; extremely common.
•Miscommunication - if developers do not know what's needed
or customer's have wrong expectations, problems are assured.
•Solid requirements - clear, complete, detailed, cohesive,
attainable, testable requirements that are agreed to by all
players. Use prototypes to help nail down requirements.
In 'agile'-type environments, continuous close coordination
with customers/end-users is necessary.
•Realistic schedules - allow adequate time for planning,
design, testing, bug fixing, re-testing, changes, and
documentation; personnel should be able to complete the
project without burning out.
•Adequate testing - start testing early on, re-test after
fixes or changes, plan for adequate time for testing and
bug-fixing. 'Early' testing ideally includes unit testing
by developers and built-in testing and diagnostic
•Stick to initial requirements as much as possible - be
prepared to defend against excessive changes and additions
once development has begun, and be prepared to explain
consequences. If changes are necessary, they should be
adequately reflected in related schedule changes. If
possible, work closely with customers/end-users to manage
expectations. This will provide them a higher comfort level
with their requirements decisions and minimize excessive
changes later on.
•Communication - require walkthroughs and inspections when
appropriate; make extensive use of group communication
tools - groupware, bug-tracking tools and change management
tools, intranet capabilities, etc.; insure that
information/documentation is available and up-to-date -
preferably electronic, not paper; promote teamwork and
cooperation; use prototypes and/or continuous communication
with end-users if possible to clarify expectations.
These few characteristics are signal of good design and
1.Extensibility without drastic modification.
2.Good code is easy to read and maintain, and well
3.Expose clear interfaces to avoid bad coding and increase
4.Easy to test.
5.Easy to debug.
6.No duplication (no redundancy).
7.Good code gets re-used.
Whether all functionalities are working as per expected?
Whether customer is delighted with the solution?
Whether actual functionalities can be scalable and
extensibility is there?
WYSIWYG stands for What You See Is What You Get. The WYSIWYG
web design tools available are Microsoft Silverlight,
Microsoft Expression Blend, Adobe Dreamweaver etc.
In such editors you edit not directly the source code of your
documents, but its presentation as it will appear in the final
Manufacturing in the quality of the design. design pattern