Make your own free website on Tripod.com

"Right" Design of Applications


  
   Right Design -is not trivial deal. 
   But to find some better answer, than absence -  seems possible.
(It seemed to be this theme is rarely covered in conceptual and modern look as well in practical relation.)
  Fish Photo Caption


  
For else samples of this theme, and to understand with compare, please read Microsoft and else articles at the bottom.

  
You see a tree on a picture - it is a main deal here.
   Tree may have a right structure -than delivering right results, and inversely:  bad structure - bad results.
Tree is growing - like your application, when you can not see all details first, but must finally receive good results, for many factors, with conditions that could be applied at right times, during total life cycle of your project.

  So the picture - is correct to deal. (So, some tip  -that system look of good program may be illustrated, productively by  rules of good  tree modeling, for first simple look of complex things)

  The main problem of so kind articles- that problems must correctly identified and correctly - (clearly) - connected to methods of resolutions, with using proposed methods to reach proposed purposes - that is not often evident, due to methods exists separately from problems, and their understanding also -is separate layer. So - to make clear that things - is the first purpose of correct design.

   Application may be designed by different ways, but only few of them is good, and very few - the best,
The purpose of this article -find how to identify and use them practically to achieve right results.

  What is the best results?
Practical answer is: which follows from optimization life cycle of application with all valuable for you criteria, (and that you will learn).

  Application must be designed and implemented fast and reliably first, this is not always excepting each other purposes. Right design -is a reason of possibility of this solution.

This speed categories is often first step and first approach, but thing is more complex -

How that can be reached?
The first rule goes here: Changeability:
Your client and chief will understand more precisely what they need, , than you, so- than you will understand such a different new things that can inverse your first opinion, so better if you foresee this scenario in your code
()like more effective implementation of some requirements, more nice look, better organized interfaces between them) - and your application must be changed minimally and optimally - this is a second criteria of right design.
(How to - see below).

   First purpose - is achieved through the rule that  that different programming things must lie right on right places -along the appropriate lines - like bricks in the wall, or nodes on nice looking tree, - through some systematization - if the strategy you are using is adequate and thoughtful - (that you can learn).


The main Idea:
Optimization of design in life-cycle- by identifying usually subjective, implicit, so not good structured, parts.

     Strategy of design -

   There are two common approaches:
   First - Define requirements and implement them fast to achieve working state directly coding  them. "Subjective" way.
   Second - implementing infrastructure and logical components filing it according "objective" rules of their structure of relationships. It need some more work first, - to identify complete logic parts (up to some, not over the top, degree. I will recommend how to calculate that  - very simply: The indeterminacy, and universality - must be equal to next step indeterminacy - at that moment when you do not know that complex future, divided to number of systematic ways you explicitly using. Than complete ways number- the faster and  more determine you will code according above right rules - that will be next- sure big economy - in total quality).
   You will need to implement some more for that components to make their logic complete.
   For the first step it is need to consider interfaces between than as a sample of them - a components with needing of right organization. The way papered to be iterative (- but not go over the top again).

   First way some programmers used due to their fast and not need know things better, not to foreseen future problems.
   Second - is compensating that some work during already completing application, stability for changing, next versions creation and maintainability. Probably - it would be faster written and faster working.

   I consider here, second way - as evidently worth to choose.
This is structural choice.

Historical reference:

     OOP (and Buch methods)-was also first steps, just classes organization.

It was hard to show adequately on graphs many existent visual design approaches due to they - were reflecting not natural kind of program logic but some- bad combinable aspects -like data classes and dynamic diagrams. Else presentation of logic- can better reflected to suitable and really useful design -according to real practices - that is usually satisfied by unnatural way - much work, with loosing many desired abilities -like reflecting business or applied idea to graph, doing that clearly.
Want you?
Combine such a  things easily at right place and receive ready to use components?
(I think -sometimes visual way is better. Now it is only either documentation (Rational) or tries usual physics translate into not did for that purpose graph - like "draw a feel"- else custom ways)

With else methods, one of them -creation logical units and configuring them into apps, process may go better.


Where is about Tahni there ? - Work must be pleasant, if did right.
Be intersting in biology. It is the same thing as programming (if with chemistry ).


Consistency: 
in framework scope in program - better to say luck of it,- in main disadvantage of many proposal. 


How to make it really working? 
(not imaging, as often did - that you good construct.)
                                 //  A right question.

   Which application is under consideration?
  - From multi-level , to single module with slightly complex structure - there is complexity -than structure is need and need be good.

   Your application is growing, like a tree, and really you can see only some nodes due to your memory restrictions - can not remember or foresee many things through the many inter-development steps - if they are disordered . So of course, to create coding principles - is crucial at serious applications.
But -Have you read yet, explicitly? Despite your programming language syntax?

With the aim of not much write, I would comment standard Microsoft public guide, to make words relating to real problems and widely considered.

1)Design components with complete functionality, like a small apps, with independent entities as a connections (2) between them -especially carefully from that point of view, also probably universal. "All things that can move, separately".
They are also reusable, of course.
(From the first steps- on that was based MS Windows itself- as message communications based. But there is a new methods today, but nonetheless -this is useful and right.)
Your app. will grow proportionally, - so not avoid small classes.

3) Identify and use complete but minimal set of design methods, coding practices - that is explicitly understand.
So your code will be thoughtful and definitive, not as spaghetti comprehensiveness, -so understand by your all team, and by you next month.

- Concrete methods of right design:
Imagine that all technology components -that are at margin edges of work that are implemented
(may be by different people or companies)
and you need optimally lat down them into the application. "How-to?"

Not by primitive first strategy on upper level of organizational chart, with no structure again - you must create right organized nodes of the tree.

Generalizing:

4) Make your components be accessed in some generalized way - by type of interface, or to some kind of organization - virtuality, data binding, Template Library, inheritance - find appropriate way of creating proportional by nodes- and minimized structure by ways .


5)   More new sample - Biz-talk framework application constructing is based on making components accessed uniformly by special accessors or adaptors- and easy visually constructed by some visible scheme. I prefer to do same by - special places at program, where I define the organization. To make this process in usual coding  practice effective.

Look at Device Context at Windows - different taks proceed sumularily - and this was a  big win in program design that was right for all.
Do sumularily in your apps.


For: 
Configuring:
  I call this methodology -"configurative programming" -when you iteratively apply options and connections between parts that made applicable for suitable using such a style.
Than reconfigure app became a deal of a seconds. often, like using a RAD.

Samples: you can see at MS libraries -they are using maps- were it is only possible- so program became very good looking and understood and often adequate -and so they are succeeded.

6) Find adequate technologies for program connectivity- for example- it is more universal to use universal synchronization- Connection points -to notify with order many parts of application that not systematically call methods of each other at components, you will be provided with many services by the way in by the way problems that may appear each moment, and will be ready and your program is good organized.
- Look also at custom data binding as a very good sample of encapsulation of disordered method calls into single unit that serviced with many complex aspect as a one line (entity) in structure - not as many spaghetti again.

- MetaData as a flexibility solution... below


Use Error-detecting system in general way through your app - take into purpose -to detect them fast, early, or making error easy found at client. Check input arguments of the method for sample, - do not be lazy.


Layered look of systematization:

   Separation program into layers, -widely known method at design- modules, more independent classes - have also (after OOP) a main purpose to encapsulate changeability that related to some concrete functionality to concrete small place. Isolate errors, provide new methods of working with them in a more complex and consistent picture and so on.

Program structure:
I would go around Microsoft systematization, to try to make it more clear.

Services - infrastructures that through many layers of application - like error processing, access rights checking.
A vertical kind of entities.

Layer- a set of components or classes that process similar set of tasks -like data access, "to isolate idiosyncrasy" of such  specific logic from else types of components.

This is widely known things - than rarely considered details:
Interfaces of Components in a layer may be moved to some generalized way to make it possible -workflow more effective proceed on them - by making a sub layer - WorkFlow itself as explicitly organized thing, and by easily applicable to them vertical servicing entities -services - with many results - to extend, or reorganize such components by one line but into total program in a consistent, looking natural (not tensile, artificial - as opposite) way.

Workflow Component (WC) - it is also component - like repetitive used interactions.
(All samples of MS is also using them).

"WC" - is advanced and may be substantial thing of Right design - is a very flexible, suitable for reuse and change and structural thing- elimination spaghetti or disorder at construction level - as a purpose.
Look as a sample - master-slave relationship between data tables on GUI development, - if made ones correct - accelerates in times following coding.

Often the only componentizing is released as a object oriented programming use- this is very low level of origination.
   So density and existence of organizational functionality must be distributed right, not as your hand wants, (but head).  

Like-MS PICTURE: What is most common organization - organized to distributed elements but layered by logics and  interacted.
We need to interact and post-build to accomplish structure effective with declared purposes



   Here - I slightly changed analogous MS layers scheme -to make it logically complete and uniform over all units.

Many sub-layers can be systemized to periodical structure - not disordered set - with analogously calling naming or logic functionality defined by it. 


Tree laws:
Make not thin threads grooving from most thick ones- only from next level of diameter.
Make not thin thread growing at the beginning of thick next level at the beginning of that threads - let it be some pure service structure. The more and better developed tree the more service part must be.


- Ms Picture also. Presenting proposed by Ms method of organizing.
Organizational aspect is not presented explicitly- so distributed with disorder in components.


This MS picture is different from previous -here organization is placed in workflow sub-layer component. so organization is in know place, visible, and sufficiently more clear. Interactions- uniformed.


Configuration - instead of "ordered" salt throwing:

   Your app. must be organized like "configured" organizational chart of components -if to follow the best practices, often, else cases you can propose to consider.
Configuring- is a hierarchical process in organizational depth.
(Does Property based wizards and option pages helps us all live?)

Some policies may move many important functionality into single line of code and even universally, found them-
Samples:  Smart Pointers.
Orchestrating of calls- may help you create universal post- and pre- processing error handling- that performs automatically through all program. As a result It is possible to change one processing line to change total error handling situation,- not running around all program or using just primitive checking and repeating this again and again.

   I think that good structure of program worth better that bytes of code economy or even percent of speed -
due to memory and processor costs low, and idle mainly,- but reliable work, and keep update fast and effective looking better for me (may be critical also- most often).

Pieces of cake:
   Choose logical units instead of low level, old style- physical things  just classes. Use "connectivity" terms,-task, collections and so on,  and configuring them as an organizing. Logical units instead of physical- so you can go from like C or assembler to C++.
Very structural way - not aggregating classes, but using much more operational relationship -"is" -use templates,
this is immutability principle - like using defined standard instead of total incompatibility,
it good used for virtuality, and else things, better extensible dynamically, so on...
Imagine standard network connector, many subjects encapsulated in one piece of manipulation -does this good for use that it is standardized?
Interfaces is the same thing along with keeping Implementation from Interfaces clearly separate - not mixing allows not grow the total complexity.
In C++ for this purpose is used Abstract classes, templates .Find more, if you understand a method...(This is a possible method of explainig)


   I think it is better not only invent new methods, but  analyze existent and systemize it,
so, here
a set of most good looking samples:



   It is better to use and explain widely known success stories -
MFC, ATL, STL, their difference and similarity,
than else kind of methods - appropriate using of language constructions, usual and modern theses that especially affects on design, like attributes.
To understand them correctly - is a right thing of repeating so kind of success.

Want you to know? But did ? - clearly and satisfactorily? -It is about availability of explanations of such materials.

   Programs using that libraries is using
maps were possible - this is kind of configurative programming -you create independent units, like handlers, properties handles, so on, and then configure use of them to easily create working hierarchy.
That program looking - clear and logically- but this is only first step -you must follow same techniques to achieve same results with higher level of abstraction entities. 
   Program must be reconfigured from localized places- to satisfy new details or requirements.
Do you find useful using property pages? -So useful maps and configuring in program.
Also they are force to use and invent by you right structured logic.

"Maps" - the purpose of which -easily connect separated and forced to good defined functionality (like compiler check for errors), to make in a structural way, with easy to reconfigure, understand -and thus using each day and life-cycle

So created application- is easily to add new functionality, change structure of work and so on, - the more you apply- the more benefit.

- Right distributing of a different types of complexity -into the right system of classes, this is evidently.
- suitable event distributing as a service (total program, vertical, entity). 
- Also integrated CRuntime identification, 
- OOP encapsulating Windows C-type, of bad structured for user, functionality.
- Getting Benefits form this restructurisation -automatic processing of many aspects of work, and their easy to very custom localized change and extend - all fitting into one working good complex.
MFC -is bad in aggregating- not interfacing ways of making classes, and so -interactions. So loosing some above cited benefits like easy of COM keep, and total
AOP abilities.

They integrate many logic - so you can create different apps. on the fly- it was in first approach, for relative simple program - but we need next step, due to programs became large and more complex.
But conceptually this methods was right, so it seems not a bad idea to use them.



STL Traits, as a sample- not enhancing number of class entities in program make possible dynamic creation, combined different properties and additional abilities and extend existent entities - by one method.
It is widely known that STL permits to separate all thing into appropriate lines- containers, algorithms,
methods of combining, easy extending, flexible using.


  Using Aspect Oriented Programming:

   By my opinion, AOP -is useful thing that is usually used not adequately -AOP can solve concrete problems, but used by fans due to
they are funs, without any consistent design picture - so I had read.

AOP is a kind of "instrumentation of code" - with pre- and post- processing elements, form one articles,
using attributes to configure part of code to construction naturally adequate to task -not all good can be programmed as by C as well C++, AOP goes next with else new methods.
  Usual application purposes - to avoid double-place coding, incorporating new meaning of functionality to the existed code - like mapping members to Database or to COM -absolutely naturally and so - good looking.
   You can define your new functionality over existed code -and solve better possible problems, so using good design - avoiding bottlenecks in complexity handling - main goal of new technologies of programming.

  
Instrumentation of code - is a making them universally available for "service programming"- changing effective program structure and properties over vertical chart -in localized places, not digging full program each time.
   Especially useful -in debugging, when you see all information and can define universal schemes of reactions to errors and optimizing paths to processing them- eliminating repetitive CATCHEs.
   There can else methods of uniform functionality over all program - like Database calls tuning and handling for -"one variable take part -one simples line call".



Custom
Data-bind

Take it into attention, Data-bind can encapsulate logic of inter-tier interactions, not disintegrated to many separate function calls.
Configuring and using the "connection" entity (not physical  C++ connection).
It may be applied from DataAcess layer to USER Interface, through Business Logic and else layers- 
do not need be written custom visualization for each step of writing code, but just connecting. 
   So you can code repetitive relationships between user items -like Master-slave lists,
synchronized lists and so on. this entities can be connected to Data delivering entities to show appropriate data.
   You can introduce "
Behavior" for your Windows GUI objects, hoe it is did in IE or in Borland Delphi -here - even for interaction interactions between elements, and than just attach and combine them by seconds, to achieve appropriate work manner. 

Object oriented or task oriented processing.
Second- is a "next step",- more and better abstracted look:
Into "task" -encapsulated all logic objects that are naturally construct a task - not disordered solution.
By the name - you will can probably use with easy many helping services -like multitasking here.
So benefits- usual thing of right organization of code.

Use a
BUS technology, -not direct, disordered interactions- for events, al types of accounting in a system, all interactions, data definition and any kind of philosophical categories in programming. (They create a good tree). How to go not over the top - read below.
It dramatically reduce the disorder in a system.

Repetitive and structured User Interactions:
   Just need to avoid full repeating same effects in proceed in standard implementation - make it possible using them "combined" -so you will receive so a real benefit, than you can use them as eligible for scheming and construction- like as in child constructor for units, made for this  uniform.

  Problem of complexity and not flexibility of organizing of interaction between GUI and else part of program, due to not strict sequensive look and processing nature of GUI with data and logic services -is most complex from making right -(effective and structural) organizational look -proposed to be solved by using logical elements of interactions - synchronizations, bindings, so on ... , instead of physical method calls or almost same by complexity encapsulation- direct message sending.

Using
MetaData:

That construction -like
flexibility is usually achieved through different kinds of metadata (Data describing data) - to make impossible not to dig into concrete interface of subjects but to use them as a kind of parameterized line of similar in some aspect things -not for only simple virtuality -but else good purposes : you can simultaneously incorporate handling data into data itself and use this effective from outer total system- to make processing and data distribution suitable and adequate to process nature.
   Mainly also - such a self-described unit can be processed with not precise and (hard-coded) knowledge about their structure, but dynamically, and very flexible, on the base of data's information itself -beginning from collection in STL, finishing by DataSets that can be proceed without prior knowledge about a query initiated them.

  Samples:CRuntimeClass hierarchy provides possibility of dynamically construct total base application work in MFC in half page of connection classes code. It is a very useful method in serious cases.
XML -can better checked if scheme is supplied with them.
  So Metadata- is automatically level of flexibility added to your program, if it added according to real problem.

   While they are universal for your kind of program - you'll receive fast development with reliable results, in common.




How to Begin right:
Develop first the conception of coding if your application, than select common technical design.
   Than it very useful to prototype User Interface look and make structure of application appropriately fitting this both sides, along with some logic completeness to satisfy changes possibility.
   So you will receive common program logic design directions and structure considerations that probably more right than if you omit some of the sides in design process.
Than use satisfying this logic physical implementation according to MS rule (concept-> logic-> physical implementation).



Yet another Most known successes in design technology: 

ASP.NET - succeeded due to applied converting web-specific sequence of calls, that were not suitable -into usual windows manner, eliminating 
unnatural things of programming (for programming).
By the way task solved -suitability, many platforms targeting, many programming services incorporated and may than user-added.

Here you can see how successive can be transformation of systematization of programming paradigm in some field to optimal one.

OLE DB - is interested not only by making work uniform but how good they are organized - In their design, flexible organization were used to extend basic functionality of some source -to make it compatible with more and more different and reach client, making fit latest and reach functionality just by adding some add-on in code and it became best integrated to the total system, due to the true service oriented design of OLE DB services. This way,  good program must be.


Design:  (total Program) - "like one structured flow":  (Ms "PipeLine" Pattern)

Making your App. processing data with events in pure uniform flow -is a right idea -this is like passing XML through the many XSL ( COM based for example) even to GUI can force fully structured and good componentized solution- (even over the top of your need -be careful also- you need to finish your program fast as well)
Benefit- easy reprogram and reuse. Choose right degree of organizational complexity, according to your priorities of your app.
  And to seriousness what to choose: good balance- hard coding or flexibility and structure. 


Standard Design Patterns:
When they good fit concrete design purposes - when you explicitly understand it - often this is not so good.
Else they usually can invoke some problems like - self-incompatibility if you want to change some little peace of code - like in visitor pattern.
But details of using and analyzing them can very useful - in design of structures that meet complex purposes of design.
But check for adequate results of methods of use that things.

 

Simple but useful advices:
(collect real of them)

Make your classes as only new entity appears,- they will grow with a tree of your program, even you can not see separation in big need.
"All that moves, separately" -separate -according to the level of complexity of program - so it will be proportional, like a good tree.
Optimize so relation of your concrete business content to service code.
Make size of methods of classes- no more than one page -tree must be proportional -than benefits- would better be.



Conclusion:
It it not easy task - to find a slution , how to in a best way design application,
but some suffitient and consistent intergrated optimisation can be proposed.
So I tried to do.




Literature on that I based and recommend to analyze, for design considerations:
Here parts of real programming and theoretical ones (two last), at coincidention of which and practice, above methods was selected,
with try to show some better structure of them:

Microsoft last samples:
"Application Architecture for .NET: Designing Applications and Services"

"Designing Data Tier Components and Passing Data Through Tiers"

General Design:
Generative and Component-Based Software Engineering

References

Analogs From Java world:
The Benefits of a Service-Oriented Architecture

Service-Oriented Architecture