Trying to understand the basic practical purposes of OOP Classes

  • (2 Pages)
  • +
  • 1
  • 2

18 Replies - 1753 Views - Last Post: 28 December 2011 - 04:40 PM

#1 webwired  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 33
  • View blog
  • Posts: 339
  • Joined: 26-August 07

Trying to understand the basic practical purposes of OOP Classes

Posted 23 December 2011 - 06:56 PM

Hello everyone... So, anyone who knows me by my posts, knows that I'm no where near an expert programmer. With that being said, I do strive to self teach with a serious purpose, but the one thing that I just can't seem to wrap my mind around is Classes.

I have read more tutorials, forum posts, blogs, and watched endless videos on the subject of Classes, in relation to .NET OOP. I certainly understand the need for Functions, I mean it only makes sense to write your code one time and re-use it, that part I get.

Everything I have learned thus far about Classes shows how you can create a Class that will allow you create a blueprint of just about anything you can imagine, and then instantiate it with all of it's fields and/or properties... The part that I don't get is, WHY? What good does it do me to instantiate a new Class Object? I'll try to explain my question further in an example...

So let's say that I'm creating an inventory application... Typically I would create a database with all of the fields that I need, then I would create a page to insert new inventory items and edit existing inventory items. I would also create a page where the end user would be able to search for and pull up a list of their inventory, by different search criteria... When the user selects one of the inventory items in particular, it would bring up all the details of said inventory item... The user could also delete said inventory items... That's it...

Now from my understanding of Classes, I should create a Base Class, say called "Item", then I could create more specialized Inheriting Classes from that one... Ok, great, now that I've done that and I can create a new Item Object ---> Now here's the real question that I'm getting at: What do I do with it? I mean what was the whole purpose of creating that class, just so I could pass that Object to my code that inserts it into my database? Because if that was the reason, wasn't that more work than just procedurally passing the inventory item fields to the code that inserts it into the database?

Anyway, I look forward to your replies...

Is This A Good Question/Topic? 1
  • +

Replies To: Trying to understand the basic practical purposes of OOP Classes

#2 tlhIn`toq  Icon User is offline

  • Please show what you have already tried when asking a question.
  • member icon

Reputation: 5526
  • View blog
  • Posts: 11,835
  • Joined: 02-June 10

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 23 December 2011 - 08:25 PM

One example: A form. A form is a class object. If you want 3 forms, you make three instances of that class.
Another example: A D-n-D game. The player is a class. If you have 3 players then you make 3 instances. Same with their weapons and so on.

These 2 tutorials out of resources below do a pretty good job of putting the concept into practice which should help you see *why*.
Bulding an application - Part 1
Building an application - Part 2




Resources, references and suggestions for new programmers. - Updated Nov 2011
Spoiler

Was This Post Helpful? 1
  • +
  • -

#3 Oler1s  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1395
  • View blog
  • Posts: 3,884
  • Joined: 04-June 09

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 23 December 2011 - 10:24 PM

> Now from my understanding of Classes, I should create a Base Class, say called "Item",

No.

> then I could create more specialized Inheriting Classes from that one...

No.

Because you can do something doesn't mean you should. I could create a class called Atom and Molecule and things like that. Doesn't mean I should. The classes you create arise from the design and architecture of your system. That is, they are a solution to a design problem. If you don't have a problem, you can't propose a solution.

Here's my recommendation. Ignore OOP. Completely.

Because when you need OO, you'll have that insight and realize it.
Was This Post Helpful? 1
  • +
  • -

#4 baavgai  Icon User is offline

  • Dreaming Coder
  • member icon

Reputation: 5832
  • View blog
  • Posts: 12,684
  • Joined: 16-October 07

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 24 December 2011 - 06:31 AM

Understand that OO solves a number of problems presented by large, complex, programs. If you've never worked on anything like that, then it's value can be unclear. Even then, OO isn't the only game in town and some programmers would argue they do just fine without it. It is a tool. You use it if it helps you in some way. If it's not apparent how it helps you, you may not need it.

Of course, in some languages OO is unavoidable. However, you can still stick to basic practices without fear. The wisdom of all OO practices will become clearer in time. Or not. There's no right answer. Some folks will present OO as wonderous UML diagram where all the objects fit together in a clean and orderly way. This is a facade. Real programs aren't usually that orderly, but we do try.

As a programmer, you don't usually start at the abstraction; you write code to do work. As you work, you find places that might be refactored to use more general functions. If you organize your code in a class, you might find another class wants some of the same code, but differs in intent. You might make a base class for those two classes. You might make a helper class.

You can actually use classes and methods and not use OO design principals. A good example of this would be the C++ STL.
Was This Post Helpful? 1
  • +
  • -

#5 webwired  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 33
  • View blog
  • Posts: 339
  • Joined: 26-August 07

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 24 December 2011 - 09:43 AM

View PosttlhIn`toq, on 23 December 2011 - 09:25 PM, said:

One example: A form. A form is a class object. If you want 3 forms, you make three instances of that class.
Another example: A D-n-D game. The player is a class. If you have 3 players then you make 3 instances. Same with their weapons and so on.

These 2 tutorials out of resources below do a pretty good job of putting the concept into practice which should help you see *why*.
Bulding an application - Part 1
Building an application - Part 2


Thank you for your reply. I really liked your tutorial/example/walk-through ... I guess what I picked up from it is goes to reinforce my previous way of thinking, Classes work and are more practical for a different type of application base than I am used to programming... What I mean by that is, Every application that I build is some sort of database driven/purposed application that is meant to serve as a repository of information, e.g., I've built a custom application for a company that keeps track of their inventory, assets/asset locations, personnel/personnel certifications, projects, etc... I've also built an application for massage therapists that keep track of their income/expenses for not only themselves but for other massage therapists that they have working for them, consumables, advertising expenses, etc... and for myself, a trouble ticketing system with prepaid hours and purchasable hours, etc... The point I'm trying to make is, you can see all of the things these types of programs have in common, they're not applications that do an instance of a task and then shut down... They're all webforms with database fields ready to CRUD... I think that is where I was having the most difficulty understanding, for the most part, Classes for the purpose of instantiating new Objects, never really aligned itself very well with the types of procedures that I am/was needing for my applications...

I will however continually look for ways in which I may incorporate the use of custom Class instantiated Objects in my future programming design...

View PostOler1s, on 23 December 2011 - 11:24 PM, said:

Here's my recommendation. Ignore OOP. Completely.

Because when you need OO, you'll have that insight and realize it.


I like that, it's very Zen... Thank you

View Postbaavgai, on 24 December 2011 - 07:31 AM, said:

Understand that OO solves a number of problems presented by large, complex, programs. If you've never worked on anything like that, then it's value can be unclear. Even then, OO isn't the only game in town and some programmers would argue they do just fine without it. It is a tool. You use it if it helps you in some way. If it's not apparent how it helps you, you may not need it.

Of course, in some languages OO is unavoidable. However, you can still stick to basic practices without fear. The wisdom of all OO practices will become clearer in time. Or not. There's no right answer. Some folks will present OO as wonderous UML diagram where all the objects fit together in a clean and orderly way. This is a facade. Real programs aren't usually that orderly, but we do try.

As a programmer, you don't usually start at the abstraction; you write code to do work. As you work, you find places that might be refactored to use more general functions. If you organize your code in a class, you might find another class wants some of the same code, but differs in intent. You might make a base class for those two classes. You might make a helper class.

You can actually use classes and methods and not use OO design principals. A good example of this would be the C++ STL.


Thank you for your reply, I have read a lot of similar posts from long seasoned programmers ... They even coined a phrase, POOP, Procedural Object Oriented Programming, which is a bit of an oxymoron, but it really does seem to fit very well...

Oh come on now guys, you know "Is This A Good Question/Topic?" is definitely a Yes, give me a click, build my reputation a little :)
Was This Post Helpful? 0
  • +
  • -

#6 lordofduct  Icon User is online

  • I'm a cheeseburger
  • member icon


Reputation: 2533
  • View blog
  • Posts: 4,633
  • Joined: 24-September 10

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 25 December 2011 - 11:48 AM

If you want to see the practicality of classes... just look at the .Net framework in general.

The entire framework is filled with classes. Collections, Connections, Forms, Controls, etc etc etc... a good deal of the objects you use in code every day are classes. And they're reusable and useful for all sorts of things.

Your 'Page' is technically a class of object, the objects you use to connect to your SQL database are created from classes as well. You probably won't need to create but 1 or 2 classes for your example project (the classes that will be the 'pages' in which you display stuff... say maybe the WinForms if this is a WinForm project), but you'll be using the classes already created in the existing framework.

Once you start recognizing the usefulness of existing classes, and how they're organized and made available to you. You may start to think of your own classes to use along side them, or inherit from them. Say for instance creating your own DataBindingSource to bind data from your SQL server to a DataGrid on screen.
Was This Post Helpful? 1
  • +
  • -

#7 blackcompe  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1155
  • View blog
  • Posts: 2,533
  • Joined: 05-May 05

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 25 December 2011 - 01:49 PM

Quote

I have read more tutorials, forum posts, blogs, and watched endless videos on the subject of Classes, in relation to .NET OOP. I certainly understand the need for Functions, I mean it only makes sense to write your code one time and re-use it, that part I get.

Everything I have learned thus far about Classes shows how you can create a Class that will allow you create a blueprint of just about anything you can imagine, and then instantiate it with all of it's fields and/or properties... The part that I don't get is, WHY? What good does it do me to instantiate a new Class Object? I'll try to explain my question further in an example...


Classes support object-oriented design. They allow architects to create real world models to design their systems. It's an abstraction, where each class is responsible for taking care of itself. It doesn't matter to me how it's done, only that it's done right. I expect a BankAccount object to deposit and withdrawal my funds. I don't need to know about the intricacies involved.

If you were brain-storming, you'd say: "What kinds of real-world entities are involved in what we're modeling?" A bank has-an address, a manager, employees, customers, and accounts. An address has-a street, city, zip, etc. A manager is-an employee. An employee has-an address. A customer has-an account. An account has-an address. These are all UML concepts that are used to sketch class diagrams to help visualize the system for other architects, programmers, or whoever needs that information. UML teaches you how to model has-a relationships and is-a relationships.

Posted Image

You really can't think about systems that way in terms of functions alone. You can do something similar with C structs and functions, but your using structs which are what classes evolved from. That's a light version of OO programming. Once the architecture is complete, architects delegate the implementation to programmers, along with a specification. This is all in theory of course. The great thing now is that I can assume all the classes will be implemented and I can code my business logic.

public class Test {
    public static void main(String[] args) {
        //get balance for custId = 32032
        Bank b = new Bank();
        for(Branch br: (List<Branch>)b.getBranches())
            for(Account acct: (List<Account>)br.getAccnts())
                if(acct.getCustId() == 32032)
                    System.out.println(acct.getBalance())
    }
}



So from beginning to end, I simply brainstormed a real-world object model, and ended up with a working system. The UML tools actually generated most of the code for each class. To me that's the power of OO programming. I barely wrote any code. In C that would take a lot longer and probably had more bugs.

There are other advantages of the OO paradigm over the procedural paradigm. Greater cohesion and less coupling. Coupling is really hard to get past in C. Every time you want to operate on a data structure you have to pass a pointer to it. If I change something internal to that data structure, that the function depends on, the code will break. That's a form of moderate coupling. In OO, as a client, I have the data structure operate on itself by invoking a public method. If the internals of the data structure change, any methods that break are fixed immediately just to get it to compile. It's responsible for itself.

And of course there are more advantages: polymorphism (which can be done in procedural programming BTW), coding to interfaces, and most importantly: inheritance. If all else fails, inheritance alone makes OO programming worth it. It makes extending systems so dam easy.

This post has been edited by blackcompe: 26 December 2011 - 12:02 PM

Was This Post Helpful? 3
  • +
  • -

#8 webwired  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 33
  • View blog
  • Posts: 339
  • Joined: 26-August 07

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 25 December 2011 - 03:57 PM

View Postlordofduct, on 25 December 2011 - 12:48 PM, said:

If you want to see the practicality of classes... just look at the .Net framework in general.

The entire framework is filled with classes. Collections, Connections, Forms, Controls, etc etc etc... a good deal of the objects you use in code every day are classes. And they're reusable and useful for all sorts of things.

Your 'Page' is technically a class of object, the objects you use to connect to your SQL database are created from classes as well. You probably won't need to create but 1 or 2 classes for your example project (the classes that will be the 'pages' in which you display stuff... say maybe the WinForms if this is a WinForm project), but you'll be using the classes already created in the existing framework.

Once you start recognizing the usefulness of existing classes, and how they're organized and made available to you. You may start to think of your own classes to use along side them, or inherit from them. Say for instance creating your own DataBindingSource to bind data from your SQL server to a DataGrid on screen.


Yeah, no, I realize that the entire .NET framework is built upon Classes, I was just meaning going forwards with an OOP mindset and how that relates to the types of applications that I build... I do see what you mean though, I think I have to side with those people who say, "don't worry about it, it'll come to you, don't spend more time trying to figure out how to use a class than you would procedurally building it..."

I was actually in the midst of creating this app when I thought to myself, why isn't there a class that has a label, a search box and a submit button... I mean I use those so much and are definitely reusable... So, guess what, I found that the .NET 4 framework has QueryExtender, LOL... Unfortunately it doesn't work with SQLDataSource, but I could definitely see the need for one...
Was This Post Helpful? 0
  • +
  • -

#9 webwired  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 33
  • View blog
  • Posts: 339
  • Joined: 26-August 07

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 25 December 2011 - 04:07 PM

View Postblackcompe, on 25 December 2011 - 02:49 PM, said:

Classes support object-oriented design. They allow architects to create real world models to design their systems. It's an abstraction, where each class is responsible for taking care of itself. It doesn't matter to me how it's done, only that it's done right. I expect a BankAccount object to deposit and withdrawal my funds. I don't need to know about the intricacies involved.

If you were brain-storming, you'd say: "What kinds of real-world entities are involved in what we're modeling?" A bank has-an address, a manager, employees, customers, and accounts. An address has-a street, city, zip, etc. A manager is-an employee. An employee has-an address. A customer has-an account. An account has-an address. These are all UML concepts that are used to sketch class diagrams to help visualize the system for other architects, programmers, or whoever needs that information. UML teaches you how to model has-a relationships and is-a relationships.

Posted Image

You really can't think that way in terms of functions alone. You can do something similar with C structs and functions, but your using structs which are what classes evolved from. That's a light version of OO programming. Once the architecture is complete, architects delegate the implementation to programmers, along with a specification. This is all in theory of course. The great thing now is that I can assume all the classes will be implemented and I can code my business logic.

public class Test {
    public static void main(String[] args) {
        //get balance for custId = 32032
        Bank b = new Bank();
        for(Branch br: (List<Branch>)b.getBranches())
            for(Account acct: (List<Account>)br.getAccnts())
                if(acct.getCustId() == 32032)
                    System.out.println(acct.getBalance())
    }
}



So from beginning to end, I simply brainstormed a real-world object model, and ended up with a working system. The UML tools actually generated most of the code for each class. To me that's the power of OO programming. I barely wrote any code. In C that would take a lot longer and probably had more bugs.

There are other advantages of the OO paradigm over the procedural paradigm. Greater cohesion and less coupling. Coupling is really hard to get past in C. Every time you want to operate on a data structure you have to pass a pointer to it. If I change something internal to that data structure, that the function depends on, the code will break. That's a form of moderate coupling. In OO, as a client, I have the data structure operate on itself by invoking a public method. If the internals of the data structure change, any methods that break are fixed immediately just to get it to compile. It's responsible for itself.

And of course there are more advantages: polymorphism (which can be done in procedural programming BTW), coding to interfaces, and most importantly: inheritance. If all else fails, inheritance alone makes OO programming worth it. It makes extending systems so dam easy.


Thank you for the great reply, it does give me some insight on the overall view of a larger project, or even one that one may see getting larger, later... Perhaps some UML learning and practice and I'll see the benefits of your example in use. Especially once I get my Systems Analysis class complete... I had started it once but had to withdraw from it to go to work, LOL... You'd be amazed at the places that'll hire you before you're even through with college...

Overall, I think that UML/new Classes/hardcore OOP, are utilized the most and best in larger, more Enterprise/Corporate settings, with very large chunked applications...
Was This Post Helpful? 0
  • +
  • -

#10 wordswords  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 76
  • View blog
  • Posts: 272
  • Joined: 17-December 11

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 26 December 2011 - 11:06 AM

Up until a few years ago, I didn't really 'get' OOP either, it seemed like too much work and not enough gain. I will try and explain it here.

OOP is a neat way of organising your code and data into managable segments that you can finish and treat as object that just 'do' what they are meant to.

Imagine you are creating a 'Zoo' application that keeps track of the animals in a particular zoo. You can combine the names and code for a Zebra animal into a Zebra object. So it is like creating a custom data structure with all the information you need for the Zebra, along with any code that the Zebra object will need to do its job.
Was This Post Helpful? 1
  • +
  • -

#11 AdamSpeight2008  Icon User is offline

  • MrCupOfT
  • member icon


Reputation: 2263
  • View blog
  • Posts: 9,467
  • Joined: 29-May 08

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 26 December 2011 - 11:44 AM

Another example is bank accounts.

public base Account_Base
{ private _Info : AccountInfo
  private _Balance : Decimal        = 0
  private _OverdraftLimit : Decimal = 0
  private _Transactions : list[Decimal]
 
  friend new(   Account : AccountInfo,
                Opening : Decimal = 0,
              Overdraft : Decimal = 0
            )
  { _Overdraft = Overdraft
         _Info = Account
    Credit( New TransactionTypes.Opening(_Info.OpeningDate, Opening ) )
  }
 
  public readonly Balance() : Decimal
  { get:
    { lock ( me )
      { return  _Balance
      }
    } 
  }

  public Credit( t : transaction_base) : trans_result
  { lock( t, me )
    { if( t.amount>0 ) 
      { _Transactions += t
        _Balance += t.amount
        return New Succesful()
      }
      else
      { return New NegativeTransaction(t)
      }
    }
  }
  public Debit( t : transaction_base) : trans_result
  { lock( t, me )
    { if( t.amount>0 ) 
      { if( t.amount <= _Balance )
        { _Transactions += t
          _Balance -= t.amount
          return New Succesful()
        }
        elseif( t.amount <= (_Balance + _overdraft_limit))
        { _Transactions += t
          _Balance -= t.amount
          return New Succesful()
        } 
        else
        { return New InsufficientFund(t)
        }
      }
      else
      { return New NegativeTransaction(t)
      }
    }
   } 
 /* etc ect */
 }
}


All the difficult locking code is encapsulated into a base class.

Now you can have different types of accounts
 Checking : Account_Base
  Savings : Account_Base
   Shares : Account_Base




For example you can write a class that produces a bank statement for any type of account. Accounts objects only know account stuff, not printing stuff.

This post has been edited by AdamSpeight2008: 26 December 2011 - 11:49 AM

Was This Post Helpful? 1
  • +
  • -

#12 webwired  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 33
  • View blog
  • Posts: 339
  • Joined: 26-August 07

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 26 December 2011 - 01:28 PM

View PostAdamSpeight2008, on 26 December 2011 - 12:44 PM, said:

Another example is bank accounts.

public base Account_Base
{ private _Info : AccountInfo
  private _Balance : Decimal        = 0
  private _OverdraftLimit : Decimal = 0
  private _Transactions : list[Decimal]
 
  friend new(   Account : AccountInfo,
                Opening : Decimal = 0,
              Overdraft : Decimal = 0
            )
  { _Overdraft = Overdraft
         _Info = Account
    Credit( New TransactionTypes.Opening(_Info.OpeningDate, Opening ) )
  }
 
  public readonly Balance() : Decimal
  { get:
    { lock ( me )
      { return  _Balance
      }
    } 
  }

  public Credit( t : transaction_base) : trans_result
  { lock( t, me )
    { if( t.amount>0 ) 
      { _Transactions += t
        _Balance += t.amount
        return New Succesful()
      }
      else
      { return New NegativeTransaction(t)
      }
    }
  }
  public Debit( t : transaction_base) : trans_result
  { lock( t, me )
    { if( t.amount>0 ) 
      { if( t.amount <= _Balance )
        { _Transactions += t
          _Balance -= t.amount
          return New Succesful()
        }
        elseif( t.amount <= (_Balance + _overdraft_limit))
        { _Transactions += t
          _Balance -= t.amount
          return New Succesful()
        } 
        else
        { return New InsufficientFund(t)
        }
      }
      else
      { return New NegativeTransaction(t)
      }
    }
   } 
 /* etc ect */
 }
}


All the difficult locking code is encapsulated into a base class.

Now you can have different types of accounts
 Checking : Account_Base
  Savings : Account_Base
   Shares : Account_Base




For example you can write a class that produces a bank statement for any type of account. Accounts objects only know account stuff, not printing stuff.


I have to say, looking at your code really reminds me of just how much I have to learn... That's some crazy awesome coding! In addition, perhaps not the idea you were portraying, but none-the-less, it would seem, among other things, that a Class can also be used for holding all of the user input validation as well as querying, cross-validation, functions, procedures, etc... More or less, this then makes it more portable, kind of like a module... For instance one of the projects I'm working on for practice is an Asset Management C# ASP.NET app... My idea was to create this and other apps, such as inventory, employees, projects, etc... I could create each one as a module that could be added...

I guess what I'm trying to say is that it'll separate out the code from each other, give it a level of independence, to where the procedural code only interacts on the front side, whereas each Class works independently unless of course it's dependent or inherits of another...
Was This Post Helpful? 0
  • +
  • -

#13 AdamSpeight2008  Icon User is offline

  • MrCupOfT
  • member icon


Reputation: 2263
  • View blog
  • Posts: 9,467
  • Joined: 29-May 08

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 26 December 2011 - 02:03 PM

Just note: I didn't use a real language, it just the style I use when riffing code.

Also look at using Interfaces, which can also Inheritance.
It help me to think of Interface as contract plugs.

Finally look at extension method and generics, Classes,Interfaces, Methods.
And Lambda Functions

Good example to study of which is LINQ. A simply elegant beast.
Was This Post Helpful? 1
  • +
  • -

#14 webwired  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 33
  • View blog
  • Posts: 339
  • Joined: 26-August 07

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 26 December 2011 - 02:10 PM

View PostAdamSpeight2008, on 26 December 2011 - 03:03 PM, said:

Just note: I didn't use a real language, it just the style I use when riffing code.

Also look at using Interfaces, which can also Inheritance.
It help me to think of Interface as contract plugs.

Finally look at extension method and generics, Classes,Interfaces, Methods.
And Lambda Functions

Good example to study of which is LINQ. A simply elegant beast.


Obviously it's not feasible, but would be really, not only be awesome, but extremely helpful... would be to see 2 projects, side by side, one written procedurally, much like mine are and one where a professional programmer with an OOP mindset, recreated the same project their way... What it would be worth to see them side by side, to compare and learn from, would be priceless...

EDIT: BTW, I'm going to look into those things that you mentioned... Thank you

This post has been edited by webwired: 26 December 2011 - 02:11 PM

Was This Post Helpful? 0
  • +
  • -

#15 AdamSpeight2008  Icon User is offline

  • MrCupOfT
  • member icon


Reputation: 2263
  • View blog
  • Posts: 9,467
  • Joined: 29-May 08

Re: Trying to understand the basic practical purposes of OOP Classes

Posted 27 December 2011 - 11:42 AM

View Postwebwired, on 26 December 2011 - 10:10 PM, said:

What it would be worth to see them side by side, to compare and learn from, would be priceless...


Though it's not a side-by-side comparison, have a look at the Cards Project at by GitHub (see sig.) It is based on the abstract notion of a card, not restricted to Playing Cards, eg Tarot Cards.
Was This Post Helpful? 0
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2