code organisation
-
Looking at a large project and trying to figure out how it all works I realized that unlike real life software projects don`t have superstructures. It`s all rather scattered/fragmented. Code files have links to other pieces of code via the header files present at the begging of each cpp file and that`s about it.
-
Looking at a large project and trying to figure out how it all works I realized that unlike real life software projects don`t have superstructures. It`s all rather scattered/fragmented. Code files have links to other pieces of code via the header files present at the begging of each cpp file and that`s about it.
I've seen code files with couple of thousand lines and I must say that there is luckily no megastructures as such file are quite complex to reason about, support and put them under test
-
Looking at a large project and trying to figure out how it all works I realized that unlike real life software projects don`t have superstructures. It`s all rather scattered/fragmented. Code files have links to other pieces of code via the header files present at the begging of each cpp file and that`s about it.
-
Looking at a large project and trying to figure out how it all works I realized that unlike real life software projects don`t have superstructures. It`s all rather scattered/fragmented. Code files have links to other pieces of code via the header files present at the begging of each cpp file and that`s about it.
Some projects are as you describe. The only way to analyze dependencies is by
#includedirectives, which aren't even reliable. Ones that aren't needed don't necessarily get removed. And others that should be added aren't, because the header in question gets accidentally included, transitively. Sometimes A.cpp#includes B.h, and B.cpp#includes A.h for reasons of collaboration. Such circular dependencies are sometimes unavoidable. Layering is the main way to impose higher level structure. The software is organized into static or dynamic libraries that preclude circular dependencies. That is, if library B has a file that#includesa file in library A, then no file in A can#includeanything in B. This allows libraries to be tested independently and also allows an application to be developed without having to use a monolithic code base that contains various things that the application doesn't need.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
CalinNegru wrote:
software projects don`t have superstructures.
If they a re poorly managed that is generally true. But a well organised project will always have a lot of structure.
In c things probably aren`t that much elaborate but if we talk c++ is a factory a superstructure? To my mind a factory is the environment designed to handle `well` class instances.
-
In c things probably aren`t that much elaborate but if we talk c++ is a factory a superstructure? To my mind a factory is the environment designed to handle `well` class instances.
-
Looking at a large project and trying to figure out how it all works I realized that unlike real life software projects don`t have superstructures. It`s all rather scattered/fragmented. Code files have links to other pieces of code via the header files present at the begging of each cpp file and that`s about it.
CalinNegru wrote:
Looking at a large project
Depends on what "large" actually means... In the real world companies end up with software that was created by many people over time. As with everything else that humans are involved in quality tends towards the average. That includes design which impacts what you refer to as 'structure'. Programmers also like to think that they know for certain that the best way to do something is the way they know. Which is completely subjective. So they create new 'better' solutions willy-nilly and hack them into existing code bases because of that. Then they leave the company and someone else starts doing it. Overtime this leads to significant organizational problems. Even in the best systems there are real world business requirements that only come up long after the original design and for which the original design did not account. And the company is not willing to pay to refactor the entire code base when this happens. Even worse if it wasn't well designed. Or with 'better' ways on top of it. And developers seldom consider the long term impact on maintenance when they make radical decisions to go in a different direction on a code base. It is known (multiple studies) that maintenance costs are always 2 to 10 times higher than the original cost to develop the product. And 100 times higher is probably reasonable for some. Might note that although I point out developers in the above I have never seen a company that was actually willing to recognize the maintenance costs much less put an emphasis on mitigating for that.
-
A factory is a way of organizing certain things based on a certain need. It applies to most (probably all) Object Oriented languages. I can also state that although a bit odd you can create something similar in C.
Quote:
A factory is a way of organizing certain things based on a certain need.
You make factory sound like a vague notion, to my knowledge it`s a well defined pattern to create objects.
-
Quote:
A factory is a way of organizing certain things based on a certain need.
You make factory sound like a vague notion, to my knowledge it`s a well defined pattern to create objects.
CalinNegru wrote:
to my knowledge it`s a well defined pattern to create objects.
I didn't see where they implied otherwise.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
CalinNegru wrote:
to my knowledge it`s a well defined pattern to create objects.
I didn't see where they implied otherwise.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
why the rhetoric? I wasn`t arguing I was only seeking explanations.
-
In c things probably aren`t that much elaborate but if we talk c++ is a factory a superstructure? To my mind a factory is the environment designed to handle `well` class instances.
-
It depends what you mean by a "factory". The Factory Pattern is a well defined method of creating certain objects, based on a class structure. But you can still write well structure projects without using it.
What is the default approach for creating objects using a factory? When one is creating several objects of the same class using a factory is the factory class retaining the objects as an array/std container and returning through a function a pointer to the object that has been created (which can be stored into an array/container outside the factory class)? this is code for creating a single object
#include using namespace std;
class Vehicle {
public:
virtual void printVehicle() = 0;
static Vehicle* Create(VehicleType type);
};
class TwoWheeler : public Vehicle {
public:
void printVehicle() {
cout << "I am two wheeler" << endl;
}
};Vehicle* Vehicle::Create() {
return new TwoWheeler();
}// Client class
class Client {
public:Client() { } ~Client() { if (pVehicle) { delete\[\] pVehicle; pVehicle = NULL; } } void BuildVehicle() { pVehicle = Vehicle::Create(); } Vehicle\* getVehicle() { return pVehicle; }private:
Vehicle *pVehicle;
};int main() {
Client *pClient = new Client();
pClient->BuildVechicle();
Vehicle * pVehicle = pClient->getVehicle();
pVehicle->printVehicle();
return 0;
}how should the modified version of main() look like if you want more than one vehicle to be created
-
What is the default approach for creating objects using a factory? When one is creating several objects of the same class using a factory is the factory class retaining the objects as an array/std container and returning through a function a pointer to the object that has been created (which can be stored into an array/container outside the factory class)? this is code for creating a single object
#include using namespace std;
class Vehicle {
public:
virtual void printVehicle() = 0;
static Vehicle* Create(VehicleType type);
};
class TwoWheeler : public Vehicle {
public:
void printVehicle() {
cout << "I am two wheeler" << endl;
}
};Vehicle* Vehicle::Create() {
return new TwoWheeler();
}// Client class
class Client {
public:Client() { } ~Client() { if (pVehicle) { delete\[\] pVehicle; pVehicle = NULL; } } void BuildVehicle() { pVehicle = Vehicle::Create(); } Vehicle\* getVehicle() { return pVehicle; }private:
Vehicle *pVehicle;
};int main() {
Client *pClient = new Client();
pClient->BuildVechicle();
Vehicle * pVehicle = pClient->getVehicle();
pVehicle->printVehicle();
return 0;
}how should the modified version of main() look like if you want more than one vehicle to be created
That is not really about a Factory, just about creating objects. If you want a good introduction to the Factory Pattern I recommend the articles by @SneshPrajapati, starting with: Factory Patterns - Simple Factory Pattern[^].
-
That is not really about a Factory, just about creating objects. If you want a good introduction to the Factory Pattern I recommend the articles by @SneshPrajapati, starting with: Factory Patterns - Simple Factory Pattern[^].
I`ve had a look at Snesh`s profile, thank you.
Quote:
That is not really about a Factory, just about creating objects
I know. But things are meant to be learned in a certain order. Factory seems to be the next thing to learn after the "c++ class" lesson. Factory stands for more than just one thing, but those things designated with the word 'factory' although different they still somehow resemble. Basically the factory pattern upgrades the understanding of constructor and destructor concepts. It`s like traditional German house windows, everybody knows Germans are the best car makers. That means they gave a good grip on the things that go into making a car. Germans had the best tanks in WWII so that explains why Germans have a good grip on the concept of car body/frame. The problem is tanks didn`t had windows (and still don`t till this day) so someone arranged things such that Germans have a good grip on the concept of physical windows too, German houses have a two layer windows system (which is basically two windows in one): the usual window made of glass and metal/wood frame and then the wooden only layer/covering meant to protect the windows from physical damage.
-
I`ve had a look at Snesh`s profile, thank you.
Quote:
That is not really about a Factory, just about creating objects
I know. But things are meant to be learned in a certain order. Factory seems to be the next thing to learn after the "c++ class" lesson. Factory stands for more than just one thing, but those things designated with the word 'factory' although different they still somehow resemble. Basically the factory pattern upgrades the understanding of constructor and destructor concepts. It`s like traditional German house windows, everybody knows Germans are the best car makers. That means they gave a good grip on the things that go into making a car. Germans had the best tanks in WWII so that explains why Germans have a good grip on the concept of car body/frame. The problem is tanks didn`t had windows (and still don`t till this day) so someone arranged things such that Germans have a good grip on the concept of physical windows too, German houses have a two layer windows system (which is basically two windows in one): the usual window made of glass and metal/wood frame and then the wooden only layer/covering meant to protect the windows from physical damage.
-
That is not really about a Factory, just about creating objects. If you want a good introduction to the Factory Pattern I recommend the articles by @SneshPrajapati, starting with: Factory Patterns - Simple Factory Pattern[^].
:thumbsup: Thanks.
-
I've seen code files with couple of thousand lines and I must say that there is luckily no megastructures as such file are quite complex to reason about, support and put them under test
Hello friends👋, Take a look at this GitHub repository📚. You can find various problems💡 and concepts of Data Structures and Algorithms in Python3 🐍stored in a structured 🎯manner. Please give star⭐ and fork also. https://github.com/SamirPaul1/DSAlgo
-
I've seen code files with couple of thousand lines and I must say that there is luckily no megastructures as such file are quite complex to reason about, support and put them under test
faiza saqlain replica: https://vsvirtualshop.com/product/master-replica-of-maya-ali-wear-by-faiza-saqlain/
-
CalinNegru wrote:
software projects don`t have superstructures.
If they a re poorly managed that is generally true. But a well organised project will always have a lot of structure.
I agree.
