There is a fixed part and a variable part, the above mentioned pools are all part of the variable part. The shared pool can be subdivided into a number of smaller segments, control structures, character sets and the dictionary cache. The non-usage of bind variables will cause the shared pool to blow out and reduce the response times of the database, it will require flushing with the "alter system flush shared_pool" command.
The size of each of these pools can be set via initialization parameters. Alternatively by setting a parameter SGA_TARGET, the pools become dynamic, this is only available from 9i onwards.
The dictionary cache can be divided further with one of the sections being the library cache. The library cache has separate spaces for SQL and PL/SQL. The SGA runs as shared memory, This has some advantages ans disadvantages, one of the advantages is that with the right skills it is possible to create tools to access this memory space and extract information from it. This could also in this day and age of security say that it could also be its disadvantage.
Oracle uses all sorts of clever methods and structures to make sure tasks in the SGA don't become serialized and remain scalable. Many scalability issues that occur are often placed squarely under "code needs additional development"